The #1 thing I've learnt making casual games is making them is 10% fun and 90% boring. There must be millions of unfinished prototypes out there that were dropped just after the fun ended and the developer had a 'better' idea... I know I have a few dozen.
It's when the job gets hard and boring that I forge forward because I KNOW that's the point when most developers stop and the competition will be less after launch.
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.
Yep. It's exactly the same in the Flash industry, prototypes get done and dropped in days, never to be touched again. Those last weeks of work are boring as but unfinished games are worth exactly $0.
I find point 3 (OOP Rules) an interesting conclusion. It seems like there is a greater push towards data driven game development and component based entity systems that have a more functional or procedural feel than OOP.
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.
OOP(in the hierarchical sense) is heavily blunted by the need for global mutable state in games. The game design often turns out to need to access anything, anywhere, at any time, so the natural move is towards a model more reminiscent of a relational database, with lots of indexing and denormalization. Subsequently the job of implementing game design is reduced to a lot of query statements; most of them are collision or "is-a" categorizations.
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.
Interesting. Earlier I've made a few small game prototypes, nothing that can compare to a real, full blown game, but it's where I'd like to go someday and I can totally agree with most of the points.
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.
