Printable View
Games are getting increasingly complex. I'm wondering if anyone uses any OO design patterns, and what advantages they offer in a game dev environment. Im finding that my latest game (My rally one) is getting more and more complex, 200 classees and counting so far, and things are starting to get sticky.. so I am wondering if there is a better way... and who has it :D
200 classes is alot imo. - not sure if that is standard but at least I would consider a layout or design of the technology/engine in future for such a project then.
Maybe you have a lot of mini classes and some of them are only used once or twice in other classes? - because if it is only used once you might rethink of its reason why it exists as a class and not just as a sub- function in or more bigger class.
For example I am working atm. on a fairly complex 3d engine with asset management, mesh, tile, sprite support and lots of other things and I have only 7 classes so far- but I am not sure at all how that is comparable to your engine.
this is a good read:
http://www.gamasutra.com/features/20...eimeier_01.htm
I find that I can never stick to a pattern or need one for games, I seem to do things a little different for every project. But I do encourage the use of events. Try to create your game without any static instance variables, without any reference to "parents", "containers"... embrace the custom event approach. I find now that using events is so much more neater and less of a headache because I don't need to worry about what functions I need to call outside of the running class or when I need to call them. I simply dispatch an event when something has happened and something else deals with it. Of course, in saying that, I don't do it for intensive calculations. I'm still very weary about the EventDispatcher and its performance and doubt that its any good for hardcore stuff. Things like GameEvent.GAME_OVER, GameEvent.LIFE_LOST, PlayerEvent.SPECIAL_MOVE are great. Much better (imo) than: Main.instance.gameOver(), UI.instance.subLife(), Enemies.instance.damageAll().
If its a case of designing an ui/nav, then I highly recommend developing a generic pattern which has some fundamental functionality USING INTERFACES! If you create your pattern which solely relies on interfaces you'll have a stress free process (second time around ;)). Of course, still create some base classes which provide functionality, but make sure all classes are type cast with their Interface rather than their Class, that way you can easily create different functionality and not break the program.
I dont use OO nor any patterns.
I use Composition ( I had to look that up 'cause I can never remember. Totally badly o/t when I was looking for the term I found this:
"certain button-style interactions with objects from any class that inherits from Sprite will trigger an automatic post-event screen update ( Exactly as though the programmer had invoked updateAfterEvent()"
Essentail Actionscript 3.0, pg 600
Explains why buttons seem to really slow things down. Sorry, back to the topic ).
So yeah composition. I only rarely use inheritance and then usually I'll have a Baddie superclass and then just extend that with the specific types.
I try and arrange things ( In my head ) in a tree style structure working it's way down.
So right at the top ( The fairy if you like ) is the main document class, which is a singleton. That's the only class which has any sort of interaction with the root / stage.
"Beneath" that I have an Init class which creates instances of all the major classes beneath it, and then triggers the whole thing off.
The major classes are on the same "level" of importance, so usually that would be the SoundHandler, the Attact stuff ( Front-end ), and the GameController ( If needed any loader classes go here too ).
SoundHandler for example will be used by both Attract and GameController so for me it makes sense to have the pointer to it in the Init class.
Attract and GameController are on the same level as they don't interact much. When ones' doing it's thing, the other isn't. The only time they interact is at the start of a game ( ie the player has pressed the play button on the title screen, so the attract needs to remove all it's assets and call GameController.startGame, and when it's game over the Attract needs to be called to display that ).
Attract never usually has many sub-classes to it ( By that I don't mean via inheritance, but via composition ) as there's not a great deal for it to do.
GameController on the other hand has tons of stuff created in it, eg
Player
MainLoop
BaddieHandler
HUD
LevelHandler
etc.
The GC class itself is pretty short, it just creates instances of each class, allows for getters for each instance ( So the Player class can talk to the BaddieHandler class via the GC. I know I should use Events but I'm set in my ways, plus I've always had problems when trying to trigger Events between classes in as3 ) and has methods like startGame(), continueGame(), LevelComplete() etc.
Hopefully that's vaguely clear. I do use a lot of classes ( The Arkanoid game I'm working on has around 50 from memory, although it's got a level editor in it which has caused a load more classes to be needed ) but 200 seems an insane amount mate.
My simple rule of thumb is that if something is more than a couple of methods then I give it a class to itself. For your Rally game I'd have something like:
Main
Init
- Loader
- Attract
- GameController
- SoundHandler
And GameController would have
BaddieHandler
- Baddie ( ie npc car )
MainLoop
Player
HUD
LevelHandler
LevelPlotter ( If the pre-game plot routines are a bit big, if not then it'll go into LevelHandler )
( I hope that doesn't read as too patronising, I know I've missed out a lot of stuff that's gone into the game ).
Squize.
"Much better (imo) than: Main.instance.gameOver(), UI.instance.subLife(), Enemies.instance.damageAll()"
Oops, mis-read that first time. Ha, that's pretty much how I do it :)
Squize.
Forget about classes and patterns and just do it!
Those things can be usefull sometimes...BUT only if you dont go like 'oh my god i want my code to be beautifull so i will shove it all the design pattersn i can' <-- that is evil, but anyway, as things became more complex some are necessary...but will be good only if you understand the problems they were created to solve, so you can break the rules and dont use or adapt to use it in your own way...
Anyway, its also interesting the way some ppl say that as3 strictiviness will turn you into a better programmer( i know i know this is NOT another as3 discussion the point is other thing) AND, they say THAT, and dont say what the hell is a better programmer, i supose its the same with design patterns, knowing them is supose to turn you a better programmer, im a bit skeptical about that because knowing whats this guy's solution to a problem is not the same thing as knowing what he had to think to find his solution, neither why this is suposed to be better in all times, all circunstances over other things and whatever
I use mostly start my OO State Machine (as an iState Interface) and create Singletons for things like SoundManger, and enemyManager. I then set up a whole bunch of standard events before-hand that all of the individual singletons can listen for: Level start, player die, etc.
That's the extent of my planning with patterns. I then procrastinate and have to jumble the whole thing up with hacky code needed to stitch the features together, and try to meet the last minute needs of the producer or designer (sometimes those people are me, so I only have myself to blame)
Word for word.Quote:
Originally Posted by 8bitjeff
I start with one class and factor out as I go along. My aim is to end up with something like a facade or mediator pattern, but if I don't have enough time it usually just becomes a god-object
I take the same approach as I do with cooking, I never follow recipes, I just make sure I have all the right ingredients and make the rest up as I go along.
I only use really 2 design patterns when working with games in flash the Singleton and Model View Controller patterns. You should look into the Gang Of Four - Design Patterns, I remember reading a book by Colin Mook (cant remember what its called) about design patterns in flash some time ago. All in AS2.0 but would be the same. I think they help you stay in structure but sometimes can make it hard to do really what you want because you have to stick to the patterns rules.
I have read about many patterns and while I don't make any deliberate effort to shoehorn them into every piece of code I touch, I like to take a step back and think of the options that are available and the consequences of each one.
I use a lot of Composition (had to look it up too :p), which I find to be quite useful.
I really agree with the whole using Custom events! If you are using AS3, you should really check them out, I really like them a lot. Provides a lot of functionality and keeps things modularized/separate.Quote:
Originally Posted by mr_malee
One question I have is this: How do you handle hittests in your design pattern? (I believe this was brought up before and I think Squize linked to an article that talks about it, does anyone have that?)
For example, if I have an EnemyController class and a PlayerBulletController class, where does the hittesting occurs? I normally just take one to be the "boss" eventually, that loops through the others information, but it seems they are really both equal and should be handled by another piece of code.
One way you could solve it is pass an iterator for both the EnemyController and PlayerBulletController class to a HittestManager class, that will do the hittesting for you. Then you just overload the function depending on what the two arguments(ie what two things are hitting) you have to get specific behaviour.
Does AS3 support function overloading now, or in F10? I remember hearing about it but haven't tested it.
I agree on using custom events for sure. I do a LOOOOOT of that. Also I have a base Entity class that most objects will extend.
At the first load of my program I will have a settings class which loads all of the numerical and text data from an XML settings file.
Then any time I need an object created I use a singleton factory class which hands me the object I need.
There is a lot more to it but thats the jist of it atleast.
Here is a pic of my UML from earlier in development...it's gotten much bigger now...
http://www.cheezeworld.com/files/spa...MunsterUML.png
My project has gotten HUGE but so far it's pretty easy to find things and make changes so I feel good about the design of it all.