

7 Game developing things I've learned so far - MaurizioPz
http://www.mauriziopz.eu/from0togame/index.php/7-game-developing-things-i-learned-so-far/

======
lawn
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.

------
benologist
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.

~~~
dpcan
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.

~~~
benologist
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.

------
michaels0620
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.

~~~
chipsy
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.

------
rlm
Google copy:
[http://webcache.googleusercontent.com/search?q=cache:www.mau...](http://webcache.googleusercontent.com/search?q=cache:www.mauriziopz.eu/from0togame/index.php/7-game-
developing-things-i-learned-so-far/)

