Jump to content

Recent Entries

Recent Comments

- - - - -


4: Adsense

My short time in the games industry - 8 months or so - has been marked by inefficiency. I now have a good idea why games take so long and why so many projects are cancelled. Setting aside human error and egos, which are a major problem on the publisher side it seems, the development side is just plain inefficient, often because problems are solved in such a way that other things become harder.


- source control systems: it keeps source backed up, it allows for revertions, and stops people trampling on each others work. All good. But it also leads to a fair bit of hassle - exclusive check-outs often make you wait for a file, shared check-outs make you waste time merging and checking automated merges. It also holds up bug fixes because a one-liner fix may now have to go through the update/merge/commit cycle.

- exotic architectures: it's often quite cool to write extensive systems that make a certain complex idea possible. eg. Call a function, and have it executed on multiple servers and clients automatically, with all passed in data members correctly serialised and reconstructed. Grrrreat idea. Now try wrestling with the lengthy code needed to create such functions and the data, and the 48-page long template errors you get at the slightest typo.

- data backed by SQL databases: these give you automatic persistence, standardised querying facilities, easy ability to locate your data on a different computer to the program doing the querying, etc. All good. Now try to write a common interface for such SQL-enabled objects, get it to work across inheritance, and guarantee that the code stays in sync with the SQL statements required to create the database. I never knew adding two integers to a C++ class could take 3 weeks before, but now I do.

- using complex template libraries like Boost: as seen in recent threads on the forums, many people swear that Boost makes their life easier - and it does - but Boost also makes your compile times longer - which it does. Longer compile times can't be shrugged off as irrelevant, as the compiler is a valuable tool in checking your code correctness at the low level, freeing you to think of the high level tasks. Faster builds also facilitate running tests, whether of an informal nature or of the Test Driven Development variety. Using complex template types inevitably means inserting them into headers, and that means bigger build times, and probably a reluctance to refactor code due to this. People talk about using the pImpl idiom to help here, but let's not kid ourselves - the pImpl idiom is a workaround to sidestep problems with the language. It's extra work, no two ways about it.

All these facilities do Great Things. There's no denying it. But you pay a price. And I fear that all we're doing is shuffling the burden around rather than eliminating it.

I think the answer to some of these problem will look something like a word that starts with 'P' and ends with 'ython', but I'll go into that another time.

Apr 19 2007 05:35 AM
Re boost: Distributed compilation helps as well (though I'd still like to see distributed linking).
Apr 19 2007 05:38 AM
Your last post makes it extremely hard to read this post cause it breaks width on my laptop 1440x900.
Apr 19 2007 07:11 AM
Yes, the scrolling is annoying. That's Gamedev's fault for making the entire layout dependent on the widest post. Not much else I can do without editing that post, which isn't going to happen.
Apr 19 2007 10:45 AM
My main gripe with my experience with source control with groups was with the programmers who liked to check broken code into the code base, causing the morning build to break horribly. Given I was the only programmer who was in at the early morning along with the artists (who all seemed to be early riser types too) it was up to me to try and fix things. Eventually it got annoying enough for the artists to start learning basic C so they could help me.
Apr 19 2007 01:04 PM
I can sympathize with Trapper Zoid. This past summer the project I was an intern on was for an embedded system; most of the code we were working on could be built with a cross-compiler and downloaded pretty quickly to the hardware. Tedious, but do-able. However we also did some work on the board firmware, testing a build of that involved this complicated flashing process where you had to arrange the jumper pins just so over a number of steps, and if you did it wrong it could be hard to fix your mistake. This lead to less testing (daily, if that much), so when it broke (and it did) it could take the better part of a day to track down the issue.
Apr 25 2007 04:42 AM
Exclusive checkout?

Why not.

I remember I used those, when I was young and innocent (more seriously, nearly all source control tools are able to merge two modified files correctly; the remaining two files that can't be merged automatically are usually not that hard to merge manually. Maybe it's time for your team to use modern tools [grin]).

Regarding long compilation time, you should give a look to IncrediBuild. It's highly efficient, and not very expensive (see here; granted, their pricing policy should be clearer. But for 330$, you can save a lot of time (ergo a lot of money). A trial version is available, so you can even test this for real).

Now, regarding SQL and complex environment... Well, all I can say is that people really LOVE complex solutions to simple problems. As Pascal said, speaking about one of his essay: "I would have made it shorter, but I was lacking time to do so". Building complex/big solutions is far easier than building simple/compact solutions.

Last but not least, a question: with all these drawbacks, how efficient is the software? [smile]
Apr 26 2007 07:56 AM
Oh, it merges things correctly, when possible to do so. But sometimes it's not, and you have to go through and give it a hand. And this usually ends up applying to quite a few files. Unfortunately the nature of the work means that at any one time, 4 or 5 people are usually editing the same class hierarchy, and the same type of functions within those classes, etc.

Plus there's the time it actually takes to perform the update, which is often a good few minutes, even across the 1GB network.

It's just an extra hurdle. Perhaps I am overly harsh on it because I am used to single-person projects. But I think it does prove the Brooks stuff about communication between developers being a source of inefficiency.

As for build times, Incredibuild might help a bit, and it's something I've thought of mentioning, but I expect they will still be significant.

Note: GameDev.net moderates comments.