Tuesday, November 23, 2010

Pitfalls of Data-Oriented (DO) development

Object oriented development is ubiquitous in the games industry and it's quite hard to remove your brain from thinking along those lines if you've been doing games for a reasonable amount of time. I just read this post and thought about the problems I faced when I started doing DO. The whole entity ID problem that finally faded away with practice and the general "no, wait, XYZ said that was bad". I thought that it was about time to point out some of the problems I have with data-oriented development after I started doing it in my day job.

Firstly, data-oriented is different. This makes it harder for seniors to look at your code and appreciate that it even works. Sometimes you might get a "what is that? why did you do it like that? can't you just wrap it up in a class to make it easier to read?" These are disheartening to hear, especially from people you should be learning from.

Secondly, there's the stress of not being able to write data oriented. You still have to work daily with object oriented code bases, so if you're a good developer, one that work well with others, then you're constantly chomping at the bit to write it better, but hampered by style guides and already in place systems that do everything in an OO style.

Thirdly, there's the solitary feeling. It's not just a feeling of being alone with the concept of DO, but also the feeling that there might be groups or gatherings of others that do it the DO way, but you're not part of them, yet. It can be draining, and you may want to shout out about it, but no-one will have time to listen to a completely alien methodology when they're all concentrating on just getting stuff done. Which admittedly is your job too, so you have to suck it up.

No comments: