Entity Systems are the future of MMOG development – Part 1

A few years ago, entity systems (or component systems) were a hot topic. In particular, Scott Bilas gave a great GDC talk (http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf – updated link thanks to @junkdogAP) on using them in the development of Dungeon Siege. The main advantages to entity systems were:

  • No programmer required for designers to modify game logic
  • Circumvents the “impossible” problem of hard-coding all entity relationships at start of project
  • Allows for easy implementation of game-design ideas that cross-cut traditional OOP objects
  • Much faster compile/test/debug cycles
  • Much more agile way to develop code

I first started using entity systems in anger back in 2001-2003, when I was working on MMOG server middleware. We were targetting the few most painful problems in MMOG development, one of which was the difficulty of constantly changing your game logic after launch, which led us to entity systems. I learnt then that entity systems were an almost perfect solution to massively speeding up the development time for most MMOG’s, and for also allowing almost unrestrained re-writing of fundamental game features post-launch with very little effort.

That last issue is critical to the success of an MMOG: once an MMOG is launched successfully, its long term success or failure depends more upon the ability of the dev team to evolve that game into a better game month after month than upon anything else.

I learned a lot from that first run-in with them, more about the things that go wrong and what makes developing with entity systems particularly hard than about the things that went right. We also discovered that performance could easily become a major issue – although they are very flexible and dynamic, the lack of pre-compiled lookups and optimizations can make runtime performance disappointingly (unacceptably) poor. Why? Mainly because of the amount of indirection and checks needed to run even a single method call (but I’ll go into detail on that problem, and how to fix it, a bit later).

I moved on, and didn’t think about them again, until last year. In 2006 I joined the Operation Flashpoint 2 team as the lead network programmer, where we trying to make an MMO-FPS on an unprecedented scale, and I discovered that the programming team was considering an entity-system to drive the whole game. The attractions for the OFP2 team were different – mainly around the improvements to memory management they could get from it, and the stream-oriented coding (which is essential for PS3 development) – but it turned out to be something of a silver bullet for the “MM” and “O” parts of the MMOFPS. As the network programmer, discovering that an entity system was going to be the interconnect for all other subsystems was a huge relief: the entity system meant I could implement the complex latency hiding and prediction techniques with minimal interference with the coding of all the rest of the game systems. When you’ve got 20+ programmers on a team, you really don’t want to be placing yourself in a position where you’re going to have to redesign code for all of them just to make it “network friendly”.

whilst I was working on OFP2, I got in touch with Scott, and exchanged ideas on what the future might hold for entity systems, including additional uses for them, and on how to share this knowledge more widely. He encouraged me to start a blog (and, actually, a year later that was one of the main reasons I even started this blog, T=Machine), so I figured now was a good time to start (finally) writing about those entities :).

And to blame Scott for the existence of this blog…

Since then, I’ve been thinking a lot off and on about entity systems and their appropriateness for use in MMOG development (again!). Only this time around – thanks to OFP2 and some of the issues it threw up – I had a much better idea how to use them to increase performance rather than reduce it, and had come across some other major problems that they conveniently solve. Most obviously, they work wonders for PS3 development. Knowing how PS3’s fundamental architecture works, I can’t immediately see how you’d want to use anything other than a full entity system for game development. There’s so much horsepower in that beast that you can certainly write games many different ways, but it’s particularly well-suited to this approach.

As it stands, I’m beginning to think that next-generation MMOG’s are going to be practically impossible to develop unless based heavily around a core entity-system. “practically” being the key word – unless you’re willing to spend $100 million for your development…

“Anything is possible”, of course, so there’ll be many exceptions to that – but I think any team that doesn’t go this route is going to suffer a lot because of it.

I think most people would agree. But … recent discussions on game-industry mailing lists – and the experiences I had within games companies with programmers who were much better at programming than I was – made me realise that there’s a lot of ignorance over these systems, and many people aren’t getting anywhere near the full potential of them. So, if you’re interested, read on…

I’ll do this in a series of posts (it’s going to take some time to write it all up!), but it’ll go something approximately like this:


EDIT, December 2007 – You may also want to take a look at Mick West’s introduction to entity systems for game development, it’s a shorter read than my posts, but narrower in scope.

NB: as I post the other parts, I’ll update the list above to link to them.

Did this post help you?

Support me on Patreon, writing about Entity Systems and sharing tech demos and code examples

78 thoughts on “Entity Systems are the future of MMOG development – Part 1

  1. Pingback: Entity-Component game programming using JRuby and libGDX – part 1 | I have a black belt in geek.

  2. Pingback: Juicy Breakout in LÖVE | Jim Fingal's Homepage

  3. Pingback: Parsec Patrol Diaries: Entity Component Systems – blog.lmorchard.com

  4. Pingback: Haskell meets Entity Systems – Part 1: Introduction | Functional Gaming

  5. Pingback: Pucaj Update - Major changes, Entity-component system | begedin's devblog begedin's devblog

  6. Pingback: Brute – Entity Component System Library for Clojure | Compound Theory

  7. Pingback: What Are Some Programming Design Patterns That Are Useful In Game Development? | Click & Find Answer !

  8. Pingback: Why I hate Unity3D popularity | NamekDev

  9. Pingback: Tearing it down | John McDonald Programming and Stuff

  10. Pingback: Rivoltare il server come un calzino.. si può fare! « Zenith of Magic

  11. Pingback: An entity/component system’s attempt using Box2D | Aymeric Lamboley

  12. Pingback: Doubly linked list and object pooling | Aymeric Lamboley

  13. Pingback: hxE2 + Entity Systems | PDeveloper Blog

  14. Pingback: Component Systems – And then it clicked | MoJaWorks

  15. Pingback: Project Aleron | BrutalHack

  16. Pingback: Project Aleron | BrutalHack

  17. Pingback: Component-based Entity Systems: Project Setup - Coding with Style in Unity3D

  18. Pingback: The truth behind Inversion of Control – Part III – Entity Component Systems | Seba's Lab

  19. Pingback: Kickstarting Entity Systems in Unity3d – What to include? | T-machine.org

  20. Pingback: Component System | Pocketgames

  21. Pingback: Tactics RPG Stats | The Liquid Fire

  22. Pingback: Entity systems – a first talk | Matheus Vieira Portela

  23. Pingback: unity – How does the Unity3D entity system work? | Asking

  24. Pingback: Sistema Entidade/Componente – Emerson MX

  25. Pingback: OOP vs ECS – Kata learns to code

  26. Pingback: Refactoring the Sprite – Rebecca Fernandez – Games Programmer

  27. CMaxo

    In case people wonder what he meant when he wrote “No Programmer Needed”, it’s not that no programmer are needed at all, but more like adding content into the game doesn’t always requires a programmer to back it up the system already includes the required codes.

    Let’s put it in another way. Back before Entity Systems were a common thing in video game development, a game was developed mostly around its rendering and coordinates system. Entity Systems are acting a bit like a “Overall Management System” which copy things from a data bank (be it scripts, models, textures, etc.) and place it into the rendering pipeline and/or memory pipeline.

    One of the most known example of an Entity System is the Elderscrolls games (especially since Elderscrolls 3 : Morrowind). Their modding tools are the perfect example of an Entity System. Do you need to be a programmer to be able to add a new armor in Morrowind, Oblivion, Skyrim or any of the Fall Out since Fall Out 3? No. That’s because the games cores were build with a Entity System from the start. That’s a prime example of what an Entity System is about.

    Another example is the promotional video from Ubisoft’s the Division game where they display how they can build a city with their assets and modify it easily through a WYSIWYG menu (What-You-See-Is-What-You-Get) as they can move building walls and all its content adapts automatically from, under it, a Entity System that generate the windows, bricks, roofs, details, damages, etc.

Leave a Reply

Your email address will not be published. Required fields are marked *