No, this isn't a request for you to help write my game. I mean I'm looking for a good way to implement in-game help.
The help system needs to explain a variety of game concepts to the player, triggered by diverse situations.
Some examples:
* UI Intro help -- A series of dialogs that appear at the beginning of the game that explain the user interface. "This is your ship, to control it..." "This is your long-range radar, the blue dot..."
* First encounter help -- A dialog that appears when a previously unseen category of entity comes within X units of the player.
* New event help -- A dialog that appears when a particular event occurs for the first time,
* New UI help -- A dialog that appears when a new UI component appears on the screen.
Etc.
In my last game I implemented the help system as a collection of "triggers" each of which continuously examined the game for whatever they were interested in. So for example, a "first encounter trigger" would check the game to see if any units of a particular type were within X distance of the player's ship. The problem with this was that I ended up breaking a lot of encapsulation so that the help system could peer into any part of the game state.
Suggestions? How have other people implemented help?
My game needs "help."
You could just check the types of different objects (you should be able to do this to do object interaction anyways) and use that for your triggers... If you need to go deeper then maybe you should rethink your object system, or at least part of it.
Also make it possible to disable the help. I think that if the gameplay is so complex that you need it, then maybe the gameplay is too complex for starters. If the player can guess what something does when he first meets that something, then it's good.
Remember: easy to learn, hard to master (or whatever the phrase was).
Also make it possible to disable the help. I think that if the gameplay is so complex that you need it, then maybe the gameplay is too complex for starters. If the player can guess what something does when he first meets that something, then it's good.
Remember: easy to learn, hard to master (or whatever the phrase was).
Author
Quote:Original post by Gage64
Can you give an example of how you're breaking encapsulation?
I'll try:
First, the game is a multiplayer AS3/Flex game that connects to both a metagame server (the gateway) and a real-time socket server (which handles actual in-game interactions).
Help may be required not-only "in game" (encounters with enemies, drops, ship controls, etc.) but also at the metagame/gateway level (navigating to zones, receiving missions, etc). Using the same trigger model as my previous game, the help would need to be able to look inside the game at all the entities and events to see if any trigger had been met. Without this trigger requirement, the "game" object would not need to expose any of that information-- the metagame doesn't care about what's going on "in game." So to solve my help problem I'm making a lot of information "public" that otherwise wouldn't need to be.
That's just one example. Basically any object that can trigger a help dialog would need to be made public. One thing I discovered about help is that it is very difficult to predict in advance what parts of the game will need help.
Im no OO guru but perhaps if you reversed it and had each entity notify the help system the first time it appeared....
Or rather, notify the world generally, and then the help system would read and use events just like anything else. You could probably use this system for other things too.
Yep, sounds to me like a case for a messaging system.
When one of these events happens, fire an message with all relevant details. The help system should watch for these messages and react accordingly. Events send a message that says "I Happened!" and the help system is responsible for determining what to do with the information -- eg, "has this even been shown help for already?" This is a nice way to say that, for example, a certain type of help is displayed per-user, per-game, always, or whatever is appropriate.
Since the messaging object is offering up all the necessary details, and the help system (presumably) can't take any action that would modify the object (don't pass pointers/references if it can be avoided), encapsulation is not violated.
When one of these events happens, fire an message with all relevant details. The help system should watch for these messages and react accordingly. Events send a message that says "I Happened!" and the help system is responsible for determining what to do with the information -- eg, "has this even been shown help for already?" This is a nice way to say that, for example, a certain type of help is displayed per-user, per-game, always, or whatever is appropriate.
Since the messaging object is offering up all the necessary details, and the help system (presumably) can't take any action that would modify the object (don't pass pointers/references if it can be avoided), encapsulation is not violated.
Author
Thanks for the suggestions.
I seriously considered reversing it and having the thing that the help is about call the help system. Intuitively, it makes sense but there are a number of problems:
Let's say one help scenario is "first time a player comes within 2000 units of an enemy, the help system will explain the basics of combat."
That's not a well defined "event" unless every entity is constantly broadcasting distance to player as an event.
Also, this game is written in AS3 and already pushes the performance of the engine, so I'd like to avoid any solution that requires extra processing if the help system is "off."
I seriously considered reversing it and having the thing that the help is about call the help system. Intuitively, it makes sense but there are a number of problems:
Let's say one help scenario is "first time a player comes within 2000 units of an enemy, the help system will explain the basics of combat."
That's not a well defined "event" unless every entity is constantly broadcasting distance to player as an event.
Also, this game is written in AS3 and already pushes the performance of the engine, so I'd like to avoid any solution that requires extra processing if the help system is "off."
Not so. The enemies only need to send the message when they are within the desired range -- They must check when the situation changes, but only message when the event condition is true.
For situations like this, you should really use some kind of spatial partitioning anyhow, and furthermore, the check only need be made when either the enemy moves (only moved enemies need check) or when the player moves (all enemies -- within active spacial partitions -- need check). Basically, the non-enemy character messages his position each step he takes, and enemies within the active spacial partitions are watching for those messages (which carry the player's new position), upon recieving said message, they perform the simple distance formula, and if it says they're in range, they fire the help message.
UI elements would probably just fire the message upon first being drawn.
General events are typically triggered by scripts or something, and can fire the message on invocation.
For situations like this, you should really use some kind of spatial partitioning anyhow, and furthermore, the check only need be made when either the enemy moves (only moved enemies need check) or when the player moves (all enemies -- within active spacial partitions -- need check). Basically, the non-enemy character messages his position each step he takes, and enemies within the active spacial partitions are watching for those messages (which carry the player's new position), upon recieving said message, they perform the simple distance formula, and if it says they're in range, they fire the help message.
UI elements would probably just fire the message upon first being drawn.
General events are typically triggered by scripts or something, and can fire the message on invocation.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
