How should a game fit together?
Author
Can anybody offer me some advice? I have started designing and writing computer games (hobby). I have a long background in IT however not in software design. I have done a design document of a game and have started coding. I’m not sure on how to fit the elements of the game together. Every class ends up linking to most of the other classes. I then spend a lot of time moving functions and var’s around to decuple things. I have looked at doing some UML documents but have no experience in how the game should fit together to start with. Can anybody recommend some good diagrams that show how other games have been done?
If it helps the game is turn-based done in AS3. A recent version can be seen at www.hexattack.com (Hex Knights).
Any help would be appreciated.
I think this is something everyone constantly struggles on, there isn't any perfect way.
Recently though I have tried putting all the api related and window creation code in main.cpp, and functions that the game would access such as iskeyup, getdeltatime, drawsphere, playsound etc in main.h
I then had a game.h which contains init, run, uninit functions that main.h includes so they can be run in the appropriate places from main.cpp
game.cpp then includes main.h so it can access all those game related functions, and it also implements the init,run and uninit.
Its working ok so far for me, the main plus is the api is decoupled from the game code and that the code in main.cpp doesn't have to reach out to anything.
Though the annoying thing is the main.cpp has alot of code in it, especially direct sound which annoying takes a few pages just to load a wave.
Recently though I have tried putting all the api related and window creation code in main.cpp, and functions that the game would access such as iskeyup, getdeltatime, drawsphere, playsound etc in main.h
I then had a game.h which contains init, run, uninit functions that main.h includes so they can be run in the appropriate places from main.cpp
game.cpp then includes main.h so it can access all those game related functions, and it also implements the init,run and uninit.
Its working ok so far for me, the main plus is the api is decoupled from the game code and that the code in main.cpp doesn't have to reach out to anything.
Though the annoying thing is the main.cpp has alot of code in it, especially direct sound which annoying takes a few pages just to load a wave.
well this is really were designing comes in, and for the most part is very unique to every game.
also it'd be alot easier with a little mor info on what the elements are your talking about.
but as for framework, i split mine up as so.
main.cpp and main.h, simply all this has is window creation code, and 3 function from my game code. when the window is first inizialized it calls my game_init() function, when proccess are idle it calls my game_update() function, and when the window is being closed, it calls my game_end() function
game.cpp and game.h, this is were things tend to get messy, these are really just an inbetween link to my window code and my game code. it' also tends to be were i keep my graphiocs, input and sound code, all of wich is completely independent of my game code.
unless i use the update() function in the game.cpp as my sort of state manager, ill usually write one that fits the needs of the game. as simple one that takes in pointers to tasks, the return a simple int, that tells the manager if it can run the task below it, or if it needs to delete the current task, usually suffices.
then everything in the game, is split into, different classes derived from my task class. I try not to make them too small, so something like the map manager would be one, or the main menu would be one. the tricky part comes when you need these classess to pop annother class onto the stack that it doesnt know about.
if your looking for a good uml designer, and id highly suggest getting one, it really makes designing easier to visualize. make a google search for "staruml".
also it'd be alot easier with a little mor info on what the elements are your talking about.
but as for framework, i split mine up as so.
main.cpp and main.h, simply all this has is window creation code, and 3 function from my game code. when the window is first inizialized it calls my game_init() function, when proccess are idle it calls my game_update() function, and when the window is being closed, it calls my game_end() function
game.cpp and game.h, this is were things tend to get messy, these are really just an inbetween link to my window code and my game code. it' also tends to be were i keep my graphiocs, input and sound code, all of wich is completely independent of my game code.
unless i use the update() function in the game.cpp as my sort of state manager, ill usually write one that fits the needs of the game. as simple one that takes in pointers to tasks, the return a simple int, that tells the manager if it can run the task below it, or if it needs to delete the current task, usually suffices.
then everything in the game, is split into, different classes derived from my task class. I try not to make them too small, so something like the map manager would be one, or the main menu would be one. the tricky part comes when you need these classess to pop annother class onto the stack that it doesnt know about.
if your looking for a good uml designer, and id highly suggest getting one, it really makes designing easier to visualize. make a google search for "staruml".
I've also just started designing a game, but I've decided to make a sort of engine that wraps SDL and Lua up for me. Im making a source file for each sort of class I'll use, so
- sound.cpp
- gfx.cpp
- system.cpp
- script.cpp
- etc
each of theose contains classes that make loading stuff and using a bit easier than it already is, and then I have engine.cpp that makes the classes I already made into one even simpler class. It is a bit of extra work having to make each func twice, but it means I can re-use the classes without them having to rely on code from something else if I want.
- sound.cpp
- gfx.cpp
- system.cpp
- script.cpp
- etc
each of theose contains classes that make loading stuff and using a bit easier than it already is, and then I have engine.cpp that makes the classes I already made into one even simpler class. It is a bit of extra work having to make each func twice, but it means I can re-use the classes without them having to rely on code from something else if I want.
Author
Thx for the info.
The main elements are…
-The UI, which is mainly a board made up of hex tiles.
-3 different game phases. War Room with levels to be unlocked, Unit Deployment and Battle floor.
The Battle floor consists of turn phases. Pick a unit, move unit, attack and face a direction.
Most of the code is in objects, other than a few controlling classes. I think part of my problem is I have states been controlled in static functions in object classes and not using a central state manager class. Join that with trying to use the same board object across each game phase/screen is not helping. Can anybody point me in the direction of any diagrams showing good use of state managers?
thx speedie, listing the elements and thinking about state managers has pointed me in the right direction on where im going wrong.
The main elements are…
-The UI, which is mainly a board made up of hex tiles.
-3 different game phases. War Room with levels to be unlocked, Unit Deployment and Battle floor.
The Battle floor consists of turn phases. Pick a unit, move unit, attack and face a direction.
Most of the code is in objects, other than a few controlling classes. I think part of my problem is I have states been controlled in static functions in object classes and not using a central state manager class. Join that with trying to use the same board object across each game phase/screen is not helping. Can anybody point me in the direction of any diagrams showing good use of state managers?
thx speedie, listing the elements and thinking about state managers has pointed me in the right direction on where im going wrong.
Quote:Original post by ConorH
I've also just started designing a game, but I've decided to make a sort of engine that wraps SDL and Lua up for me. Im making a source file for each sort of class I'll use, so
- sound.cpp
- gfx.cpp
- system.cpp
- script.cpp
- etc
each of theose contains classes that make loading stuff and using a bit easier than it already is, and then I have engine.cpp that makes the classes I already made into one even simpler class. It is a bit of extra work having to make each func twice, but it means I can re-use the classes without them having to rely on code from something else if I want.
I'm curious, as I havn't started my scripting part of my framework yet, and was wondering. Do you couple you script into your other classess? Does it know about your graphics and sound classess, and therefore capable of calling function from it? So far with mine, everything is seperate, the graphics class, the input class, the sound class. except a few dependencies, or helper classes i designed to make certain functionality easier that realy on one or two of the main classess.
But in a game i'm currently thinking of while i optimize my graphics core, i kind of wanted to make a sripting engine that could call all the function of the above classess, so the game logic could be softcoded.
Looks like a similar mechanism to one of my games. Effectively a hexagonal "Lights Out"...
http://www.playdeez.com/Honeycomb.asp
For a small game like the one you are making, don't over-engineer it.
Also, since you are using flash, you don't have to do a rendering engine, which is very nice. For Honeycomb, I simply made my game objects as classes that derive from MovieClip, and for the amount of stuff that the game does, there is surprisingly little code.
http://www.playdeez.com/Honeycomb.asp
For a small game like the one you are making, don't over-engineer it.
Also, since you are using flash, you don't have to do a rendering engine, which is very nice. For Honeycomb, I simply made my game objects as classes that derive from MovieClip, and for the amount of stuff that the game does, there is surprisingly little code.
Author
TANSTAAFL,
I think you only looked at flipit, try scrolling down.
Sorry the web site will be redone when/if I finish hex Knights.
PS. I like honeycomb
I think you only looked at flipit, try scrolling down.
Sorry the web site will be redone when/if I finish hex Knights.
PS. I like honeycomb
@Speedie
Your desgn is probably exactly the same as mine from the sounds of it. What I do with regards to scripting is keep it as a seperate system just like all the others, but allow the programmer to use the script class to supply information to the others, for instance:
Prog starts
>>>
Engine object initialised, but all the others arent
>>>
Script is read
>>>
Lua returns the program information on things like grpahics depth, resolution, sound devices and bit rate and initilises all the other subsystems
>>>
Program begins
Although this design is a little messy, your classes are still independent of each other. It definitely seems easier to integrate the script reading into the classes, but at the end of the day, you will lose flexibility if you decide to change any fundamental features of your game. If the game is only simple, like TANSTAAFL's honeycomb, then you could probably get away with building into your other classes, and it makes your coding easier to I'd think.
Just out of interest, what are you making and what you making it in?
Your desgn is probably exactly the same as mine from the sounds of it. What I do with regards to scripting is keep it as a seperate system just like all the others, but allow the programmer to use the script class to supply information to the others, for instance:
Prog starts
>>>
Engine object initialised, but all the others arent
>>>
Script is read
>>>
Lua returns the program information on things like grpahics depth, resolution, sound devices and bit rate and initilises all the other subsystems
>>>
Program begins
Although this design is a little messy, your classes are still independent of each other. It definitely seems easier to integrate the script reading into the classes, but at the end of the day, you will lose flexibility if you decide to change any fundamental features of your game. If the game is only simple, like TANSTAAFL's honeycomb, then you could probably get away with building into your other classes, and it makes your coding easier to I'd think.
Just out of interest, what are you making and what you making it in?
Quote:Original post by wwwHexAttackCom
Can anybody offer me some advice? I have started designing and writing computer games (hobby). I have a long background in IT however not in software design. I have done a design document of a game and have started coding. I’m not sure on how to fit the elements of the game together. Every class ends up linking to most of the other classes. I then spend a lot of time moving functions and var’s around to decuple things. I have looked at doing some UML documents but have no experience in how the game should fit together to start with. Can anybody recommend some good diagrams that show how other games have been done?
If it helps the game is turn-based done in AS3. A recent version can be seen at www.hexattack.com (Hex Knights).
Any help would be appreciated.
My first advice would be to start as simple as you can. If you jump in too deep on a complex project then you will most likely get lost and give up.
There are two approaches you could take to this. The first one is to try and leverage AS3's class based approach to design and develop an 'engine' that you can re-use to make further games. The second approach is to forget that and just sit down and code a game from beginning to end without re-use in mind.
UML is okay and design is great but keep it in mind that as you begin to fit the pieces together it is most likely that you will find that you need to change a lot and that means an iterative approach to design - expect change.
Where I usually start is a simple main entry point like this:
package{ import flash.display.MovieClip; import flash.events.Event; public class Main extends MovieClip { public function Main() { addEventListener(Event.ENTER_FRAME,onEnterFrame); } private function onEnterFrame(event:Event):void { } }}I then start bolting on the bits I need in order to get the game up and running. I tend to code each element of the game as a seperate class with as little interaction with the other classes as possible so if one changes it doesn't break all the rest.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
