Rapid Iteration
With multiple releases a week ( or even a day ) web developers have really been able to run with the deploy, measure, iterate, mind set. Put that in context with game development teams who create monolithic C++ monsters that require days to change even the most basic features, for example front-end menus that require a full-time C++ programmer to implement any changes that the designers require.
High level languages
To the metal C/C++ coding is going to be around for along to time to come yet in the games industry and rightly so. However, look to the web developers and their complete frameworks built in high level languages like Ruby and Python. Why is the gameplay written in a language that excels at talking talking the hardware. Why can't the designers have their own framework in Lua, or Python or Ruby, which allows them to create complete levels without any intervention from a coder?
Openness
Search Google for a blog on coding techniques for web development and then try the same with game development techniques. My quick google search reckons the numbers are about half, but to be honest, I doubt the relevance of many of the game development results. Where are the blogs from senior developers in big name game devs? I'd love to see coding techniques from Uncharted or the way the cover system was implemented by the Gears of War team. I'm not sure whether this is shyness on the part of the developers or it's the publishers keeping them locked up. Either way, I think it is a shame and only holds back the industry.
Disclaimer
I know that high level languages are making in-roads into game engines, but there use is usually very limited. And I know that a lot of teams are trying very hard to get rapid iteration working with in their team, but this is the exception rather than the norm.
So there you go web devs, it's not all bad, I think coders in the games industry could learn a lot from you guys.
4 comments:
Great answer to my article. Exactly what I wanted to see from the "other side" :) I'm very much agree that it would be great to connection both worlds a lot more so they could share their own wisdom and help out where needed.
In fact, I'd love to start whenever I get the chance to. If you know any good get togethers or companies / conferences that would be interested in learning from the web development world, please point them to http://paulbakaus.com/book-me/ :)
Cheers!
Paul
The requirement for rapid iteration is very high automated tests coverage, say, 100% code coverage (each line covered by a test) or better (more then one path for a single line).
I always wonder how relevant that is for game development and how many companies are actually doing it already. The lack of openness makes it hard to find out (a quick search for "game development automated testing" doesn't produce interesting results).
Do you have any insight for that?
Jörn: Game development suffers from the same problems that automated tests for UIs have only a million times worse. Add to that the fact that you are running multi-threaded on custom hardware. Quite frankly I'd be amazed if anyone out there has a game engine with anywhere close to 100% coverage.
That said I know some teams do automated tests at a more macro level. For example, render out a reference scene and binary compare the images. Or run through a level automatically an ensure the AI behaves as expected.
The problem is that setting up and maintaining these tests is a lot of work, and unless you get it right, it is fruitless.
My thoughts about rapid iteration are that it is more for during development or beta testing. Designers must be able to prototype, test and refine game mechanics very quickly. Usually, due to the way engines are designed, with a lot of the game programming done by coders in C++ the turn around time between playing the game and applying feedback is simply too long.
Well, automated testing isn't easy, but its well worth the effort to find the testable parts and be rigorous about those.
In web development I found focusing on data validation the most effective way to test GUIs. Once you have the infrastructure in place for that, you can add tests for every new issue to come up, giving you very good regression tests.
The pattern seems to be stuff that is hard to test manually, due to tons of variations that you usually don't notice. If something is a pixel off, you can see it. If one of 354 combinations of input isn't properly validated, you won't.
You mention AI, that seems to be such an area. Another could be clipping; when considering all the trouble Valve had to get hitboxes right in Counter-Strike and people still complained for years - makes we wonder how they tested those.
Post a Comment