Game Producer Christmas Calendar – Day 8 (Object Oriented Code Design Patterns)

I’ve been reading Head First: Design Patterns book, which is fine view on design patterns (that can be used in coding). I’ve done a little bit of research on how to handle object oriented code when it comes to games. There seems to be one tiny problem: everybody knows the RIGHT way to do things.

There’s plenty of people who are glad to help you out and they show you how they are “taking advantage of object oriented coding principles”. Some of the examples were good, some of them were bad and some of them… I’m not sure.

Is there solid choices for design patterns in games? Do you use them? Any recommendations?

7 thoughts on “Game Producer Christmas Calendar – Day 8 (Object Oriented Code Design Patterns)

  1. Sargon

    Oh, and clearly, a programmer that always think out of the box is a dissaster.
    Programming shouldn’t be a difficult task most of the time. Thinking out of the box requires allot of effort from your brain, you are reinventing the wheel in places you shouldn’t put so much effort, because there is a simple solution.
    You need to be creative only at 1% of your program’s code, and be laid back in the rest of the 99% of your program’s code.

    Reply
  2. Sargon

    tonic, although I didn’t read the affordmentioned book. The guy clearly don’t know what design patterns are for.
    I could explain what are design patterns with an example.
    Imagine you are a warrior that trains for an upcoming war. You have never fought in your life before.
    So they give you a wooden sword to practice.
    This wooden sword is very valuable, because it allows you to improove your fighting skills.
    However, in battle, the wooden sword is useless. You will want a steel sword, or even some other weapon like an axe would be good, even though you practiced on a wooden sword.
    Design patterns are this wooden sword.

    Reply
  3. hObbE

    I have made many designs both for games and other softwares. Some has relied heavily on the classic GoF design patterns others have not. In my experience heavy use of design patterns (patternitis) have a tendency to over generalize the design and make it very hard to understand and thus maintain.

    As of late I have gravitated more or less towards more specific designs using techniques as immediate mode gui and such.

    However, I do use some patterns when needed (Model-View-Controller for example), and I do stay away from some patterns (like Singleton). Also reading about and implementing patterns is a great way to learn more about oo-programming and design.

    You can also become more efficient when communicating to others if you can just name a pattern and not need to go into specifics.

    In that respect, I think you should at least have a basic knowledge about patterns.

    Reply
  4. Sargon

    Programming is a bit like swiming, you can’t learn it by only reading a book.
    Design patterns are just structures to give you basic ideas how to exploit an object oriented langauge.
    When you create a number of classes, those classes will most likely be a mixture of bits from several design patterns.
    So it helps allot to learn design pattern to get the idea of how you are suppose to solve problems.
    However, there is no single or right solution for every programming problem.
    You may solve a certain programming problem in several different ways.
    Because there is an informal part of programming, and the ability for anyone to give you a formula to use as is, is very limited.
    That is why when someone try to help you learn how to design your code well, he can only give you a general idea, concepts, atitudes. He cannot tell you “Do exactly as I say and your program will be perfect”.

    Reply
  5. Lumooja

    While game engines are sure easier to maintain and develop in OOP, for the actual game logic it’s better to use a straight forward procedural language.

    The game logic is often (or should be) based on complex macro functions, like PopulateWorld() or UpdateEnemies() or ResurrectPlayer(), which is also reflected in in-game scripting languages like LUA. OOP doesn’t make much sense here, since the game engine already does the OOP part internally, so the user kinda only tells the engine classes in human like language to do what is wanted.

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Pro-Human Quiz: