So what's a modern, 2013 way of doing it?
There's two ways to parse that:
What's popular or considered 'best practice' in the games industry at the moment?Component systems are all the rage and with good reason. There's quite a bit of variety in how they're
being implemented but the basic idea of having one type of 'entity' that can have multiple components
which define how it behaves. A rough analogy is that the programmer makes lego blocks and the designer
builds entities from them.
At the high-performance and AAA end of the industry you have 'double buffered' entities (a read-only public
version and a writeable, private version) to help get the most out of multi-core and the graphics hardware.
These designs are heavily concerned with performance issues and Data-Oriented Programming is a major buzzword.
At the MMO end of the industry component systems have been influenced by the need to interface with
Relational Databases (which are quite naturally 'component' based in a lot of ways).
At the indie/mobile end, Unity is component based (but not super strict about it) and is making a very
big impact.
It's worth noting that this isn't new at all. The first devs that actually publicised they were using a
component based system were probably Gas Powered Games who used it on Dungeon Siege (released 2002).
The company I worked for at the time had been experimenting with them around 2000 and quite a few
other companies had done it for a few years before that.
It's also not a panacea, I worked at a well known game studio that decided to use a component system
and they made a total hash of it. They had 100s of different types of components and singleton
manager objects for everything.
I'm leaving out a lot of details for brevity but the web is full of component system articles,
libraries, talks and slides. Some of them are just as dogmatic as the OOP guys used to be though.
What does this grumpy 'get off my OO lawn' programmer called naughty think is the modern way?Component systems done well are a lot better in many ways than the inheritance hierarchy of entities
that was common in the 90s. For a small game it could be overkill though.
However you can arrive at roughly the same ideas from several angles. More emphasis on being data-driven
leads you to something like components. Performance concerns on modern hardware lead you to components.
Wariness or fear of inheritance leads you to components. Understanding all those OOP slogans and applying
them leads you to components.