next »

[RedHickory]

I've been working on a browser based RPG off and on for several months.  It's just a hobby project and I'm trying to keep the scope limited, but one issue I seem to be continually bumping my head against is how to maintain the game's state as the player progresses through the plot.  Specifically, how to control the dialogue the player sees as he interacts with NPCs.

For instance, the first "quest" the player encounters is killing rats in a basement.  There's quite of bit of rat killing in the game, just FYI.  Anyway, before a player has started the rat killing quest, I want NPCs to respond in a certain way.  Then while he's in the middle of the quest, respond a different way, then when he finishes it, respond in yet a different way.  I have a system in place that involves setting and checking a large number of flags with ridiculously long names so I can keep everything straight, but I just feel like there has to be a better way to do this.

Despite some extensive searching online, I haven't been able to find any resources specifically on this topic.  I'm looking for tutorials, books, or other resources that might make my life a little easier.  If you have any ideas please do let me know.  Thanks.

Oh, and this question seemed somewhere on the line between design and technical, so sorry if I've posted in the wrong place.

[readyplaygames]

Browsers can save cookies, if that's what you're asking about. Or you can have a server that people can log into and store data (probably much more and with greater control) there.

[RedHickory]

Not really what I was asking.  How to store the information isn't an issue.  I have a database that keeps up with logins, inventory, blah blah blah.  I'm really asking about a structure for maintaining information about the state of the game.  Maybe the way I'm doing it now is the only way to do it, but keeping a separate flag for every event that happens (i.e. started "X" quest, finished "X" quest, killed 10 rats, spoke to this guy, spoke to that guy, left town, picked up an item, etc. etc. etc.) and then checking every single one of those flags every time the player speaks to an NPC to pick the right piece of dialog seems cumbersome.  I've never written an RPG before so I just want to see if anybody else with some actual experience can enlighten me as to a better way to keep up with this.

[bdsowers]

Unfortunately, there aren't a lot of shortcuts here - managing large messes of state information (like a ton of flags) is one of the reason big branching storylines are so much of a headache.

Some thoughts:
- You don't necessarily have to keep separate flags for everything. You could have "progress trackers" (integers) that increment when you make progress on certain quests, and then test against those. Might be useful if you have 1 quest with 8 levels of progress, since you're managing one identifying name instead of 8. Or you can even piggy-back off the systems you're using to manage quest progress.
- You could consider implement a state machine of some kind in your quest/progression system, and that could cut down on the number of flags considerably. For instance: if you have a quest that requires you to talk to Bill and then Ted and then back to Bill and Ted and back and forth, a simple flag solution might require 10 flags. But if you've got a state machine that moves forward when it receives the appropriate flags, you only need 2 flags + the state machine.
- You'll save a lot of time in the long-run by writing good tools. Tools that help you visualize how the flags interact. Tools that help you easily rename a flag without breaking the game in 30 places. Debug tools that help you visualize where in the "state tree" you are.

[RedHickory]

That's all great information.  Thanks for taking the time to reply.  I've tried breaking the story down into something like "books" and "chapters" so that if you talk to an NPC at least you can eliminate a bunch of flag testing by checking what overall chunk of the story you are in.  Thanks again for the info.  I'll do some research on state machines, but it's helpful to know the process is just a headache no matter what.