hey guys. i am writing up my own framework for building games using XNA. its going fairly well at the moment. Put simply, i have physics working, a particle engine, a finite state machine to swap between menu/ingame/pause, and my entity manager for my game objects. there is alot missing at the moment, but the main things i need to create a game are in place. I am taking a code-as-you-go sort of approach. when i need it, i'll implement it. this is to help me get a general idea of how everything is going to work together and once i am done with this game (A game similar to Asteroids) i can re-write all the messy stuff.
Right now i have the entire game of asteroids working. You can fly around, shoot asteroids, destroyed asteroids split into smaller ones, physics works fine with asteroids bumping into one another and particles are also working. The game play is, for this project anyway, 100% complete. Now i just need something to hold it all together and turn it into an actual game. I need actual menu's. A score keeping system (HUD). Lives. I need to define victory and loss conditions, that would trigger an appropriate end to the game. But i have never programmed anything like this before and i dont know what i need to achieve this.
from what i wrote above, it sounds like i am going to need atleast 2 key components. Something to manage the HUD. and a messaging system to notify everything of events. For example, notify the HUD of player death so it can display "You Loose".
Anyone have any tips to share or advice to give here?
giving the game some 'structure'
hey guys. i am writing up my own framework for building games using XNA. its going fairly well at the moment. Put simply, i have physics working, a particle engine, a finite state machine to swap between menu/ingame/pause, and my entity manager for my game objects. there is alot missing at the moment, but the main things i need to create a game are in place. I am taking a code-as-you-go sort of approach. when i need it, i'll implement it. this is to help me get a general idea of how everything is going to work together and once i am done with this game (A game similar to Asteroids) i can re-write all the messy stuff.
Right now i have the entire game of asteroids working. You can fly around, shoot asteroids, destroyed asteroids split into smaller ones, physics works fine with asteroids bumping into one another and particles are also working. The game play is, for this project anyway, 100% complete. Now i just need something to hold it all together and turn it into an actual game. I need actual menu's. A score keeping system (HUD). Lives. I need to define victory and loss conditions, that would trigger an appropriate end to the game. But i have never programmed anything like this before and i dont know what i need to achieve this.
from what i wrote above, it sounds like i am going to need atleast 2 key components. Something to manage the HUD. and a messaging system to notify everything of events. For example, notify the HUD of player death so it can display "You Loose".
Anyone have any tips to share or advice to give here?
Take my advice with a grain of salt:
3 interfaces
IEvent(base event), IEventListener(handles events) and IEventDispatcher(allows registration of listeners, handles dispatching to interested parties).
All entities implement the listener and dispatcher interfaces. I also have a simulation class which holds my object factory, entity manager, etc. which also implements these 2 interfaces.
All UI is done through my GUI class, which acts a tree of UIElements, and I've subclassed this class to create buttons, list boxes, etc. Each (again) implements the two interfaces.
The game receives input, and creates a laser fired message. if the laser beam colides with an asteroid, the Game can pass a You'veBeenHitMessage to the asteroid in question. The asteroid is destroyed, and lets the game know via DeadAsteroidMessage. The game in turn tells the Simulation, which tells the Entity manager. Now this should also give the player points, so I would subclass the UIElement Class, to make a custom ScoreElement, and in it's Handle Event method, handle the DeadAsteroidMessage by incrementing the score.
I hope you are not planning to send death messages etc. as an implementation of the framework itself. The framework provides a mechanism for sending messages (if you choose to go that way) and the game defines what and when. It is not necessarily a huge problem though to define a few messages within the engine since this is basically for you to use to help you with your games.
Also, I disagree with the principle that "Pause" should be a state. Normally you should keep 2 sets of time trackers, one for virtual and one for actual time. When paused, don't update the virtual time trackers. Then objects that are pausible (IE: using virtual timers instead of regular timers) will simply stop moving. Simple.
If you then want to add a message and darken the screen you can simply check the boolean indicating whether the game is paused or not.
L. Spiro
Also, I disagree with the principle that "Pause" should be a state. Normally you should keep 2 sets of time trackers, one for virtual and one for actual time. When paused, don't update the virtual time trackers. Then objects that are pausible (IE: using virtual timers instead of regular timers) will simply stop moving. Simple.
If you then want to add a message and darken the screen you can simply check the boolean indicating whether the game is paused or not.
L. Spiro
Author
I like that idea yogurt, and I will rework my framework so it functions that way. i was considering it too but didnt feel a need but i suppose it does give me alot more functionality that way.
also nooo, that wont be a part of the framework itself. that was just an example of what i need to do with the framework. so i suppose a messaging system is all i need then... It just sounds like this is going to get really really messy with lots of messages being listened to to get things to work. doesnt sound very elegant but ill put it to work and see how i go..
@Zahlman
i'll coonsider it..maybe..
also nooo, that wont be a part of the framework itself. that was just an example of what i need to do with the framework. so i suppose a messaging system is all i need then... It just sounds like this is going to get really really messy with lots of messages being listened to to get things to work. doesnt sound very elegant but ill put it to work and see how i go..
@Zahlman
i'll coonsider it..maybe..
If it sounds inelegant and complicated, it probably will be and there probably is a better way.
I have yet to ever really need a messaging system.
if I were working on a fairly small framework and game as you seem to be, I would use the framework to handle things that definitely must be part of the framework (loading models, handling physics, etc.) but I will not find a reason to "message"the GUI that the player has died.
Typically you would make a GUI with a tool and some other tools would let you add things to your scene and then you could add scripts etc. to control them. And it would have this elegant way to allow you to attach events to things that may commonly happen between games such as an object's health reaching 0.
I am going to assume you have none of that. No tools, no scripting language (though C# is sometimes used as a scripting language), etc.
So hook all that up and control the logical interactions between things on a per-game basis as you make each game.
If your engine is complete enough to at least say, "I have a GUI file, load it," via a single function call, then you would have no trouble just doing a:
when you make your actual game.
At some point you need to draw the line between how much your engine does and how much your game does.
Unless you can explain your big plan that steers you towards an event/messaging system that is likely to give you headaches during your game creation, you should probably just focus on making a data-driven framework and let your game handle the logic of which data to load when.
L. Spiro
I have yet to ever really need a messaging system.
if I were working on a fairly small framework and game as you seem to be, I would use the framework to handle things that definitely must be part of the framework (loading models, handling physics, etc.) but I will not find a reason to "message"the GUI that the player has died.
Typically you would make a GUI with a tool and some other tools would let you add things to your scene and then you could add scripts etc. to control them. And it would have this elegant way to allow you to attach events to things that may commonly happen between games such as an object's health reaching 0.
I am going to assume you have none of that. No tools, no scripting language (though C# is sometimes used as a scripting language), etc.
So hook all that up and control the logical interactions between things on a per-game basis as you make each game.
If your engine is complete enough to at least say, "I have a GUI file, load it," via a single function call, then you would have no trouble just doing a:
if ( pPlayer->JustDied() ) {
pgGameMan->LoadGui( "YouSuck.gui", true ); // true = remove existing GUI.
}when you make your actual game.
At some point you need to draw the line between how much your engine does and how much your game does.
Unless you can explain your big plan that steers you towards an event/messaging system that is likely to give you headaches during your game creation, you should probably just focus on making a data-driven framework and let your game handle the logic of which data to load when.
L. Spiro
Author
the big plan is just to gain experience. That is why i was planning to take that extra step which'd probably be considered over engineering for the game at hand.
reason i wanted to use a messaging system in this scenario is to remove the dependencies between objects.
in doing
the player either needs to know about the gui, or the other way around. a messaging system could solve this.
and a good example of the scripting you were talking about be Unity? sounds exactly like it
reason i wanted to use a messaging system in this scenario is to remove the dependencies between objects.
in doing
if ( pPlayer->JustDied() ) {
pgGameMan->LoadGui( "YouSuck.gui", true ); // true = remove existing GUI.
}the player either needs to know about the gui, or the other way around. a messaging system could solve this.
and a good example of the scripting you were talking about be Unity? sounds exactly like it
There is no dependency here.
This is code from the game's final "Gameplay State" class which has itself manually created a player object and is in control over what goes into the scene and which GUI should be shown.
The player class would also be part of your game and inherit from one of your engine classes (CPlayerBase maybe?) in order to allow the engine to work on the player in a generic every-game-has-these-properties-associated-with-the-player way, while allowing your game to add more data and functionality to the class specifically for your game.
And your game would have a state class that inherits from CStateBase or such. One state runs at a time, a stack of states could be used to handle system messages produced by Xbox 360, etc.
So you have one class which handles all of the logic for the gameplay part of the game you are making, one for the main menu, one for the options menu, etc.
Everything is modular.
The game state class starts by adding the objects into the world that need to be there, including the custom player class.
The game state has access to the sound manager, scene manager, etc. It is where you implement all of the logic for all parts of your game so nothing is secret from it.
Therefore there are no unusual dependencies. The player class does not know what a GUI is. You simply code the logic for showing a death scene into the game when the player dies.
Since you don't have a full suite of tools such as those in Unity 3D (yes), this is the most efficient route to take and you can avoid the tangled web an event/messaging system will create.
Those are more appropriate only when other things are in place such as scripting, because those extra things help reduce or hide the complexity of the event/messaging system.
Working with such a system directly in the middle of all the other game code you will be creating is asking for spaghetti. Which would be a good thing if it were not a bad thing.
L. Spiro
This is code from the game's final "Gameplay State" class which has itself manually created a player object and is in control over what goes into the scene and which GUI should be shown.
The player class would also be part of your game and inherit from one of your engine classes (CPlayerBase maybe?) in order to allow the engine to work on the player in a generic every-game-has-these-properties-associated-with-the-player way, while allowing your game to add more data and functionality to the class specifically for your game.
And your game would have a state class that inherits from CStateBase or such. One state runs at a time, a stack of states could be used to handle system messages produced by Xbox 360, etc.
So you have one class which handles all of the logic for the gameplay part of the game you are making, one for the main menu, one for the options menu, etc.
Everything is modular.
The game state class starts by adding the objects into the world that need to be there, including the custom player class.
The game state has access to the sound manager, scene manager, etc. It is where you implement all of the logic for all parts of your game so nothing is secret from it.
Therefore there are no unusual dependencies. The player class does not know what a GUI is. You simply code the logic for showing a death scene into the game when the player dies.
Since you don't have a full suite of tools such as those in Unity 3D (yes), this is the most efficient route to take and you can avoid the tangled web an event/messaging system will create.
Those are more appropriate only when other things are in place such as scripting, because those extra things help reduce or hide the complexity of the event/messaging system.
Working with such a system directly in the middle of all the other game code you will be creating is asking for spaghetti. Which would be a good thing if it were not a bad thing.
L. Spiro
Author
alright thanks so much for taking the time write up all this. it has helped me realize the problem with directly working with the messaging system now. there is nothing wrong with messaging systems but its not the correct solution for the problem at hand. now i just have some programming to do
Just a question. Why not use C#'s event and delegate mechanism? Is it not supported in XNA or too slow?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
