The goals object is in line with my desire to have autonomous NPCs. (Or in the case of an elevator, NPEs (non-player entities)? NPTS (non-player things)?) These would not just be stock objects that sit in a room and wait for the player to interact with them, but would be entities that "have a mind of their own." They might be in line with the goals of the game, or they could be used just to add color and variety.
My first piece of code along these lines was an ActiveObjects module (for lack of a better name), which was just an object that managed a list of objects and a turn script, and on each turn it called an "update" method on each of the objects in its list. In looking around, I know that at least one other game-creation system (no names dropped) has a built in notion of this, though they called the method invoked something to do with "idle", which isn't quite the name I'd choose, but it was the right idea. My own elevator code uses it to drive the elevator, and I anticipate having further "active objects" in my game as well. I didn't include it in the sample since *that* was definitely needless complication.
So... the goals object. My vision is that there could be entities in a game that have their own agenda. Despite what we all may believe, the (game) world does not necessarily revolve around us!
An example:
Perhaps you're making a (name deleted) game with a boy at a wizarding academy, and you wish to drop in friendly ghosts who wander the halls and cause mischief (one of whom may or may not look like John Cleese). Rather then having such "color" being room-based (where when the player enters the room, the code decides, say, whether there is such an entity in there and what it's doing), you can turn it around and create an independent, autonomous entity which wanders from room to room and interacts with things, whether the player is actually there or not.
The primary goal for such an entity would be "Wander". There could also be other goals depending on what room its in, what objects are in the room, whether the player is present, etc. Things like this can make the game world more unpredicatable and diverse.
Let's take a look at the "Wander" goal.
The "update" method for a goal updates the goal's internal state. Can the goal be tried? How high a priority is the goal? Has the goal been achieved? A goal like "Wander" would be low-priority and probably not actually achievable (in that it is base behavior and should never stop happening as a default). Whether the wander goal can be tried or not depends on the state of other goals. If there is another goal to have a conversation with the player, then perhaps while that is going on, the "Wander" goal is disabled (though that could also be handled via priorities - the goal to converse with the user takes higher priority).
The "try" method attempts to achieve the goal. In this case, it just makes the entity wander from room to room. That's how it "tries" to wander.
The "achieve" method would not be used, as the goal should never be fully achieved - it is ongoing behavior, never ending. The important thing to keep in mind about the "achieve" method is that, once a goal sets "canAchieve" to true, the goal will be removed from the list after the "achieve" method is invoked. It's the "last gasp" method. Or perhaps when night falls, then wandering would be achieved, and the "achieve" method would create a new goal - "sleep".
Let's say there is also a "greet" goal. When the player is in the room where the entity is, it will greet the user. "The ghostly specter nods in your direction." or "The shimmering annoyance says, 'Top of the morning!'" Something like that.
The "update" method would look to see if the player was in the room with it. If not, then it can't even be tried. Or perhaps there is additional logic to see if it has already greeted the player in that room or in the past 20 turns or something like that (so that it doesn't keep saying "Hi" over and over).
The "try" method would actually cause the greeting to be displayed.
Whether the "achieve" method makes sense or not is determined by whether "greeting" ever stops. Perhaps after a couple of random greetings, the goal is done - has been achieved. At that time, it will be removed from the goals list.
As a final example, let's say the entity has important information to convey to the player - but only in a certain room or under certain conditions. Once it has done so, then it never will ever again. For a goal like this, the "update" method will see if the player is with it in the room and if they are both in the special room. If so, then the goal's "canAchieve" will be set to true. And when the goal is achieved, the entity will impart the information before the goal is removed and it becomes silent thereafter. There are lot of ways you could do this.
So in the beginning, you would create your entity and give it three goals: "Wander", "Greet", and "ImpartSecretInfo". Then set it loose in the world and let it do with it's going to do. It will wander around, greet the player when in the same room, and impart special knowledge when with player in a certain room. All done with priorities and world-examining and -modifying logic.
That's the idea anyway. It greatly simplified the control logic in the elevator. I was quite excited when the "goals" approach came to me on a walk, as not only did it make the elevator logic almost trivial (just two goals - "close door" and "seek floor"), it was also in line with what I outlined above.
If anyone would like to discuss this more, let me know. It may not be a typical "go from room to room and look for items to unlock other items and everything is centered on the player and reactive to what the player does" type of game... but then, who wants to write a "typical" game?
Follow us on Facebook
Follow @TextAdv on Twitter