Most Games Programmers Dont Grok Object Orientation
Most Games Programmers Dont Grok Object OrientationGames programming is immensely complicated and expensive, and rather unfulfilling in many ways if one is (or aspires to be) an OO programmer.
If we wish to use ExtremeProgrammingForGames we must first (within a team or organization) educate people in ObjectOrientation and convince them of its value. ExtremeProgramming without ObjectOrientation sounds difficult (if not impossible).
Thus, MostGamesProgrammersDontGrokObjectOrientation is a problem which ExtremeProgrammingForGames requires a solution for.
Any suggestions as to how this problem can be solved is most welcome! Unfortunately the main problems are psychological ... Teaching OldDogsNewTricks.
A possible solution is to create your own games company and only employ people who are at least interested in OO. But this doesn't help if you wish to move an existing project, in an existing company, towards XP. The first step is moving the existing project towards OO. Actually, many games programmers don't even grok structure or correctness, and I (harshly) view these people as lost causes. Such people show no interest in OO, or say things like "OO makes programs harder to understand".
-- EddieEdwards
Game programming is upside down. It has to make a lot of compromises for the sake of memory and speed that normal applications just don't care about. Simplicity and user functionality isn't so important in games. That's what makes them cool. But, still, some questions for you:
I think language has a lot to do with it. I wonder if we would be asking the same questions if SmallTalk was the language for games development? And, although C++ is perfectly capable of facilitating ObjectGrok?, I have found that the component parts of most games - graphics, AI, physics simulation, hardware API's - are researched, implemented and taught by people who couldn't care less about objects. It's hard to keep your mind focused on objects when you're mapping some hairy, spaghetti-making C algorithm onto a butt-ugly API like DirectX. -- JimArnold
Submitted for your consideration: MostProgrammersDontGrokObjects
Games programmers are optimization specialists. Application programmers are design specialists. Why can't application programmers write highly optimized code?
Facetiously: because they use Java. Actually, because application developers can afford to blow cycles and memory, optimization isn't much of a concern. Hence, the promulgation of virtual machine hoopla lately because it's "fast enough." Or, as Mr. Bunny says, "Java is high performance. By high performance we mean adequate. By adequate we mean slow."
But we already know that WellFactoredCodeLeadsToBetterOptimizations, so this argument is pretty weak. Spaghetti code is slow.
You have obviously never squeezed the last bus cycle out of a DSP. I mean the kind where you can put two instructions in the delay of a delayed branch, and do speculative execution down both branch paths. I also mean the kind of code where instruction addresses aren't integers, but bit-strings. Or maybe code where addresses have side effects, or barely even exist. Those times are rare, but I hope you're not ignoring them. I prefer nice inheritance rules, design patterns, and all the rest when I have the luxury. I don't always have it.
When your application (1) uses a relational database (2) across a network and (3) displays the results in a GUI, then choice of hashing or linear search through an in-memory table of employee type codes will impact performance about 0.00001%. Sensible application developers should focus their efforts where most needed: long term maintainability.
Unmaintainable programs are slow, because you can't safely change them to optimize their performance.
Games programmers are ostensibly optimization experts (the poor ones don't even know how to do that) and application programmers are ostensibly design experts (I'm sure the same qualifier applies).
Myself, I try to be both. I believe the LeadProgrammer? on a games project must be both - at least to make up for the lack of these talents in the junior staff ("junior staff" in a games company can mean someone like CanisLupus, who is an excellent coder and thinks about his skills on multiple levels, or someone like XXX, who is a hacker and has written some simple 3D stuff and got hired on that basis - no knowledge or interest in OO, design or optimization!)
I came into games by curious route, though - I began life as a software engineer - so I started out by hacking and learning optimization, and then I learned design as a professional necessity.
[Random side-note: is much known/published about OptimizationPatterns? This strikes me as a potentially useful basis for games programmers - as useful as DesignPatterns for general programming.]
-- EddieEdwards
JeffGrigg wrote games for a while, and have friends who still do it. It's my impression that game developers tend to be PrematureOptimization specialists and "short timers" -- not at all concerned about the "long-term maintainability" of their software products. "Get it done and kick it out the door (and get paid)" are the rules of the day.
I would suggest that is because in the modern commercial game market, the vast majority of games have a shelf-life of 6 months at most. There are exceptions of course. -- DavidCorbin
Seems like OO would help such projects, as games are simulations. And while incremental releases can't be delivered to the game playing public, I'm sure they'd help in play testing, and any project can use the reduction in risk. -- JeffGrigg
"Huh? I've done some 3D graphics programming before I started using XP. I don't see why testing it would be extraordinarily hard."
I'm not sure which bit of the pipeline Eddie (if it was you that wrote that, Ed) was referring to, but, simply put, much of it is not stuff for which you can easily devise tests. OK, your vector / matrix math (if you're not passing that stuff off to lower-level entities anyway) stuff can be tested, but testing to make sure that (to take a recently-observed example) a change to the lighting system isn't going to "look wrong" (by the game-artist who set up the lights's definition, not a physics-correct one) when modified?
Sure, in a trivial case, you could render some lights, get some values, and save them. Then, the test would simply compare the rendered results with the saved ones, so you can at least say "this code is functionally the same as the old code, even if the old code was wrong" but it all falls apart if, say, you decide to trade some accuracy for speed and it "looks fine" but gives different values.
Then you start getting into unit tests with epsilon values and that's just... um... is it me or is it cold in here? *brrr*
Also, large chunks may get taken out of your hands. Your code is responsible for setting up a number of structures which are then handed off to a set of drivers which are outside of your control (and very frequently, contain many bugs of their own) -- and you typically have to support, let's say, 6 -8 different sets of drivers, from different and competing manufacturers.
"Why do you think games aren't object oriented? I have seen games written with objects before."
Games are object orientated. That's why OO is so great for games -- the problem domain frequently maps very nicely indeed to object domain. A typical object, in a game, will be... an object! Less obtusely, a typical class will refer to a simulated real-world object such as a spaceship.
And because of this, many games are written with at least some OO principles involved. However, all-too-frequently, what you will see is C structs with a bunch of pointers, if you're lucky (I wasn't...) some kind of virtual-method-table kludge, but often not even that (you just have to "know" what function to call for a given class, frequently leading to large, mangled switch...case statements), and no inheritance, just a tangled, dangerous form of composition handled by pointer-to-struct inside the superstruct ... oh it all quickly becomes a nightmare.
And Jeff, you're absolutely right :}
Why do you think application programmers grok OO better than game programmers? Most application programmers don't get objects either.
The title isn't "Games programmers grok OO worse than app programmers", it's just MostGamesProgrammersDontGrokObjectOrientation and I think for the most part, that's true.
As for the "ship it, get paid" factor: This is actually very valid. I mean, I'm an OO freak, but sometimes, perfection must take a back-seat... we've all seen a lot of games shelved because they've just dragged on, and on. Of course, the counter-argument (and one I use often myself) is that the cleaner the underlying code, the easier it will be to ship on time, because it'll be easier to debug, test, refactor, optimize and add new features when you have a robust, clean foundation on which to build. But it doesn't seem that way to the non-OO-grokking folk who (with some justification) care more about making the game fun than whether this member function should be const or not.
The trick is to strike a balance. My belief in a nutshell: The cleaner the codebase, the quicker the development, the more time you have to add Fun Stuff to make a great game.
-- CanisLupus
Nice one, Canis, I couldn't have put it better myself ;) -- EddieEdwards
Do application developers run their unit tests on the live database, or on a mock one that they whip up? I still assert that anything can be tested. For a given light that you build, in a given location, you know EXACTLY how lit the pixels in its cone are going to be and you SHOULD be testing that the lighting algorithm is lighting pixels as you expect. Next challenge. :) On handing data off to drivers, there are two points: 1) You expect that the driver works. 2) When you find a bug, you write a test that demonstrates it, submit to vendor, and then test that your code cannot trigger it. -- TomPlunket (who's still trying to figure out how to unit test 3DS plugins)
Some folks who fit into this space do completely grok OO. Of course, these same folks might not believe in XP. Of course, this is a company that is interested only in building correct systems and not in than pushing something rapidly out the door. See http://www.dalilab.com/ as an example. They are using BON + full software specification for their work which is in Java, C++, and Eiffel. - JosephKiniry They haven't made a very fun game though. The only fun part is that when you kill it, it says "You are quitting. Do you want to save the world?", and I suspect that's an accident. And am I the only one who thinks that a fish screensaver shouldn't need a network connection? -- AnAspirant
Interesting about not 'believing in XP'. In my last game programming job (1995-1998) I worked at a small company that I think--in retrospect--would have benefitted greatly from XP. At the time, though, I was myself a proponent of the 'correctness at all costs / BigDesignUpFront / get it right you Bastards don't you know how damaging and atavistic this whole "hacking" approach is / you're only hurting yourselves!!!' ideology. But, of course, XP isn't about hacking. And in our case, requirements were constantly changing (the off-site "producers" had a lot of control)... Anyway, I think XP: Embrace Change would have been an awesome model for us: PairProgramming alone would have been greatly beneficial; but a team-wide adoption of DTSTTCPW, OAOO, YAGNI, RefactorMercilessly, test-first programming, and XP-as-a-whole... I think would have seriously brought us together as a kick-ass team. But I can only speculate. So, ultimately, what I'm wondering is what you mean when you say you don't 'believe in XP'? Are there specific practices or tenets of XP you find unreasonable? -- BillKelly
I have found that it is the principals who have a problem changing style. They often wrote the original engine and some prototype stuff, then get put in charge of the development. Needless to say they don't appreciate requests to make their engine friendly to modification. Given the number of games that fail due to time overruns I think this will change. Your average programmer will do whatever he is asked to do or go work somewhere else. Its not like OO is particularly difficult. My 2p. RichardHenderson.
Interesting this because I think it explains why OpenGl is still popular and DirectXlibrary isn't. Whereas OpenGl is largely function pointer based, DirectXlibrary was entirely OO and I think a lot of game hackers just didn't get it (I think DirectX was well ahead of it time). I think things are now changing and more games are using DirectX. Also games these days tend to have two clear layers - the graphics kernel (for all the bits not handle by the API) and the game simulation layer. I think it is the latter layer that benefits more from OO, e.g. characters, maps, AI, etc. -- RussFreeman
Not sure I buy this. DirectX is *much* more popular than OpenGL, and has been for quite some time. The first 3 or so iterations of Direct3D were just lousy. While it (D3D) is still not as clean an API as OpenGL, there are many advantages to using it on win32, as the system it is part of (DirectX) is of much larger scope than OpenGL (or Direct3D) which makes your life easier. I wouldn't say that OO had much to do with acceptance or non-acceptance. OpenGL was compellingly better in the early days of D3D. These days, it can be a pain to use because of vendor extensions.
$.02 - the core OpenGL interface is a thing of simple beauty, a design so elegant it should be in an art gallery. DirectX may be more powerful, flexible and up to date - but it's one ugly **************. DirectX code scares the hell out of me. -- JayBell
Be afraid. Be very afraid.
Is there a DirectXversusOpenGl page that this ReligiousWar could be moved to before the big guns come out?
Interestingly, I've had a number of conversations with games companies lately. I've been interviewing. All of them have basically said "yeah, we're interested in hiring people from outside the industry who can come in and give us the experience we're lacking; projects keep going wrong, doing the work seems so hard.. so we're after people with a wide skill range like yourself... you want **HOW MUCH**?!?!?!?!"
And they decide to go with the 19-year-old uni drop-out after all.
As for not knowing OO, I've found there's a brilliantly sneery attitude to things like that in a lot of the games industry. It's the same tone they used about C++, five years after everyone else moved to it. The same tone they used about C, five years after everyone else moved to it... While things like the graphics technology is ahead of everyone else, the project management technology and the development technologies are years behind. They'll end up picking up design patterns as a way of speeding up development in about 2006, after everyone else has moved on to something else.
I almost sense it's machismo. Programming is hard. Games programming is **HARD** and it's going to stay that way. And anyone who says that if you're a bit more organised you can have enough spare time in the day to eat healthy and go home to sleep clearly is a wimp.
That's why, still, in the 21st century, the games developer boards are full of people trying to write self-modifying x86 code that drives mode 0x13 directly...
There's a couple of interesting points here. First up is the salary thing... In the UK, salaries for programmers are much lower in the games industry than other areas. I think employers would like us to believe that demand for jobs is high, hence the lower salaries. However, everyone I've spoken to in recruitment complains about how hard it is to get (and retain) good staff. So why don't they wan't to pay good money for the good staff? I dunno...
As for OO... I think CeePlusPlus is quite widespread in the industry now. Many of my colleagues are experienced in C++, and for every low level assembler bit hacker, there's a design pattern guru to match. Thing is, the console hardware that we are targeting remains fixed (at least until the next iteration comes out...). As time goes on, and we try and squeeze more and more performance out of the hardware, C++ morphs into 'to the metal' C and assembler. For example, your average PC profile wouldn't even notice a virtual function calls, the but the Playstation 2 has a tiny I-cache/D-cache and stuff like this can be relatively costly.
Finally, I don't think games programming is hard. In fact, I'd say its easy - and fun. There's a certain challenge in implementing, say, stencilled shadow volumes, but a basic understanding of vector maths will get you through most things. The hard stuff - the REAL hard stuff - I guess is just like any other industry - team building, keeping a clean code base, managing the design, feature creep, lousy management, etc etc etc.....
-- JayBell
Game programming is my dream job. And it is also my nightmare from the seventh tier of Hell.
I do enjoy being a member of that elite group that is "leading the herd towards software engineering greatness", "heralding the evolution", etc. Seriously though, it's not really that elite. I agree with Jay. While there are plenty of H4X0R D-luxes, there are also actually plenty of software engineers that understand OO and other stuff very well, and make life better for everyone.
My current project is like that. We basically have all OO gurus on this one (except for one open-minded noobee), and it is indeed quite nice. Now if only our management were as enlightened.... But I digress.
The people you see proliferating on the games developer boards appear to be primarily the on-the-side hobbyists. I very seldom catch whiff of any actual, experienced game developers. I believe the real game programmers are too busy making games and keep their skills honed and polished, to participate in web threads about x86 hacks!
-- GraysonTheRaisin?
This subject is a bit overstated. You'll find lots of game developers that fully understand and use OO methods.
On the other hand, one of the real tricks of the game development fieldis that tightly specifying gameplay is very tough to do. Something that sounds wonderfully fun may turn out to be laborious and misguided. Projects constantly get turned around and redirected. It sounds like XP makes a lot of sense here, and it does, except that OOP in C++ is a lot less lightweight to work with than in, say, Smalltalk. Refactoring is a lot tougher, too. So rather than getting bound into an object hierarchy that turns out to be completely incorrect, it is often much easier to go with something flatter and less heavy-handed. This at least keeps the impact of bad decisions localized. Now for a game written in a lightweight language this may be a different story.
Also note that the subject of this page is a bit pointed and misleading. Certainly it is not accepted in all walks of software development that "OOP = Good, Everything Else = Bad"? This page appears to have been started by someone who sees OOP as The Way, but worked at a company where the senior programmer or programmers were less zealous.
See PeopleWhoDontGetOo, OoHasMoreDials
EditText of this page
(last edited November 18, 2010)
or FindPage with title or text search