7 Game developing things I've learned so far
mauriziopz.eu
mauriziopz.eu
However "OOP rules" is a bit dual edged for me. When I started out with prototyping these games I tried really hard to do it "the correct way" with loads of abstractions and with proper encapsulation and what not. Sure parts got good but I a made a lot of bloat along the way and now I could have made it a lot simpler (and better). Maybe it's because I've been spending time with Haskell and lisp (functional lisp that is) and now I'd like to "go back" to a more functional approach. Maybe it's because it's just a personal growth as a programmer though?
I might agree with the step by step approach, although I personally think it's funner (and thus more educational) to just dive in head first and make shit happen. I don't think I've ever learned as much as when I sat down and decided that yes I would finally make a working game and just jumped in head first. Break things - it's the way we (at least how I) learn.
Which brings me to #5:
"Don’t just jump at any problem and start writing code." Well that's a little how I do things. Maybe I don't even know exactly what the problem is before a few attempts? How would you for example solve a path finding problem in a modern RTS? A bit of forethought is vital of course, but can you really think of all the subtle problems that will come up? Or even all the big ones? I think iterate early and often is the key to game making, and it's a bit similar with problemsolving.
But of course that's also what he's getting at later with "Write some basic functionality and then expand it." It's just that I think when I'm coding, not before.
Now after I wrote this I realize I agree with almost everything he said but with minor differences.
I just completed the working prototype of my next game. It's RIGHT NOW that the other developers quit because this is when it starts getting dull.
It's now time to:
- add 2 player
- create the computer player's AI
- make a working high scoring system
- create the game-options screens
- add the little features and game options
- add extra animations or "flare" that sets me apart from the typical indie dev
- create screen shots, marketing copy, the web page, the icon, the high res icon, get a TOS, etc.
But this is why there's a difference between running a mobile business and writing an app.
It seems that people are moving towards a set up where the processing is handled by globally available managers and GameObjects are instead contained across multiple Component types.
That's not to say you can't build an component based system in an OOP language of course.
At the same time, there's some pressure to serialize large parts of the game, if possible, for two reasons - save games, and editing tools. This further encourages a more formal relational-type system(leading to the entity/component distinction), since a setup based around unstructured pointers is harder to cleanly serialize.