Members - Reputation: 127
Posted 20 August 2012 - 10:39 AM
Untill now , all my designs are a mess.I guess I violate any OOParadigm rule that ever existed.The nightmare starts when I try to add new characteristics.
This is my biggest concern.Right now, I'm not interested in making my code re-usable for other game , rather I'd like to design the code such that adding new features wont be a pain .
I've read articles about design patterns and such , but I fail to understand them [ althought it seems I allready made use of the facade pattern.]
So , are there any good game design "patterns" out there? Could someone help me with some tips?
Maybe articles about design patterns using examples from games would really help.
Crossbones+ - Reputation: 6586
Posted 20 August 2012 - 11:30 AM
What you need to do now is buy a couple books frankly, as this is one of the area where internet tutorials mostly suck. I notice you've tagged C++, in that case, pick up Effective C++, other books worth checking out are:
Refactoring: Improving the design of existing code
Those four books, if you read and understand them, will make you a better programmer.
If you don't want to outlay for books, or find them to be a bit above your pay level for now, check out my C++ game tutorial, it is one of the few tutorials out there that actually illustrates design patterns and OO design in action, and for good reason. To cover this stuff in tutorial form takes a bloody long time... that tutorial is at 10 parts, isn't completely finished and only creates a simple Pong clone. But if you go through it, I guarantee you will learn lots, and hopefully have a few 'ahah' moments. That said, I don't pretend to be Scott Meyers and my understanding of C++ is by no means perfect, so do not expect perfection.
Members - Reputation: 128
Posted 20 August 2012 - 03:19 PM
- if you're not composing a team and you want make things clear to you, just abandon horrible design patterns (except singletons maybe:P but you can support yourself with procedural techniques), cause they will mess and mess you until you completely understand them. Then you'll discover that you need more and more lines of code that could be never seen in future. The idea is to use as much oop as you need for base for the game, the rest bases on uber-total-entity object which handles every instance of the game, then use lua/whatever to control whole stuff. I came to that point after two rewrites, my code is still for me but at least I can handle all game logic with simple scripting routines.
- if you're a team member, team creator then I would consider using some more oop concepts
- if the game type excludes point one and two then I don't know:)
Finally, summing up - after rewriting/simplifying things you'll find your own way, but it's good to know common oop patterns/paths.
PS: Agile programming - under that term I used to learn many things:)
Edited by vicx, 20 August 2012 - 03:22 PM.