Sunday, January 22, 2006

Game Logic

I've been thinking about making a game engine more data driven for some time now, and only recently (while working on this ten weeks of hell project) have i come up with a solcution that i think will truly work.

The idea is simpler than i ever thought it could be. I'll keep on it for a while before i announce anything, just cos i need to run it through the sanity filter known as my workmates.

The development process

I've worked on many developments, long, short, conversion, diversion, pet, work, community. One project stands out from all of them, and its only really just started.

I've always been one for diving in, getting things done, but with plan of action. I'd spend quite a bit of time figuring out how long things take to do, then add them up and report back to whoever wanted to know. Most of the time it fell on deaf ears, when it didn't they weren't pleased with the reports (probably because they sounded so pessimistic). Even when we did get any kind of go ahead, all we did was lookat the schedule and attempt each milsetone in turn, going from definition to final code in one difficult step.

Because this latest project is extremely short original title (10 weeks from start to SONY submission), but reasonably well funded (we can afford four full time coders plus a PS2 graphics programmer for 4 weeks), it made us all panic a bit. Okay, so obviously this isn't the next GTA, but it has to be completed to the point where SONY will accept it, and that means that its gotta be bugless, behave completely as expected, and be reasonably good within the limitations of the timeframe.

So, for the first time ever, we designed the game technically. Now, when a lot of people hear that they might assume that we'd never done a technical design doc before, they'd be wrong. A technical design document for us though had always been a document about what we were going to do, and what technology we were going to use to do it. This has been the kind of document requested from Sony for some time now, and its the limit of what we had previously produced. This time, we didn't stop. We went deeper with the game logic, peeled away when and where the data was used, how the in game entities interract, right down to the actual pseudo code for an entities' reaction to a collision from a player. We then stepped out and had a look around at the code, added more work on the initialisation of levels, and just kept adding.

The design doc is by far the largest one to date, it is the same size as a design doc written for a project of about 5 times the budget, and is still growing. During the work, we found at least 3 bugs, 2 integration issues, figured out that we'd need to ask about 5 different big questions of the publisher, fixed 1 stupid coder error (an optimisation that would not have been optimal), and even figured in the designers considerations for tweakability and ease of level creation without him having finished the game play design document.

So, what do i think of the design first, code later aproach? Unbeatable. And we haven't even dropped a line of code yet.

Followup in roughly ten weeks :D

Tuesday, January 17, 2006

Managing projects that never end

I'm not talking about ongoing projects that have multiple versions (e.g. Photoshop, Windows, GCC), I'm talking about projects that have terribly underfunded development. The projects that i am talking about are the pet projects that are too big, and in house projects that are unsigned by publishers so they only get a few man months per year. You know the thing, a project that would have normally take a reasonable amount of time, but due to unforseen (or possibly forseen but ignored) circumstances, has to be put on hold "for a while". This kind of project can dishearten people more than any other, as code begins to rot before the project has finished, or other people bring out new software that is very similar to what you were going to do, or worse, you lose heart, leave the project so long that you forget all the good ideas you had when you first started the project.
So, how do you stop these long projects from crumbling under the weight of time? How can you set a process by which the project can be dropped and continued? What is the essence of a pausable project?
I've worked on quite a few never ending projects, and of them all, only two have been pausable. Both of these projects are connected to each other, which in some sense makes the number of projects just one, but i think of them as two projects, as one is dependent on the other, but not the other way around.

The differences:
The differences between the pausable pair and all other projects I've worked on seems to boil down to coding style. Not coding style from the point of view of braces and how to name your functions, but more of a "don't hack" attitude. This is an important thing, especially in a project that does not have a design document (another victim of the never ending project's underfunding). I've found that in the pausable projects, there is a distinct truth to most things, there are no lies in function names, classes do what they sound like they do, they all have similar construction, and all have similar style of implementation. There is consistency of implementation, even if there is a shift in thought. There is also a bold line struck between modules of code reducing the coupling to the minimum. This means that the code is easier to search, easier to modify, maintain, and remove if it was never necessary.

So, is the pausable project a better project in general?
Probably not. You pay the price in performance when you make your code extra readable and easily maintainable. You also pay the price in terms of time to develop, as without a thorough design, you may code many more modules than necessary. So, even though the project could be restarted at any point, is easier to maintain, can be reused and can be used to teach good style, the actual code takes more man months to develop, is slower in terms of frame rate or other performance metric, and is probably more bloaty than necessary.

So, if its not better, why do it this way?
Well, not all projects have the benefit of a straight line in development. Not all projects get done at all, and sometimes its better to work on reusable code, just so you can reuse the code on the next endless project. Some projects don't need the performance of a fully designed and tuned project, but do need the maintenance and modifiability of a pausable project (think about converters and editors).

its up to you to decide if your project needs to be pausable, but if it does, keep the following in mind:
  • The maintenance programmer is you, and you will remember none of your tricks until its too late, so document them or don't use them at all. Never do anything unexpected, no hacks, no odd code.
  • Be strict in style, if you change style, then you lose flow. Stick to the style you started with, or change the style of the entire project so it's still consistent.
  • When you make additions and deletions, show your reasoning in comments, otherwise you will forget why you did it, and might change something in error. Also keep the old code (commented out?) so you can see what you deleted and possibly reintroduce it if it was an error to delete it in the first place.

Saturday, January 14, 2006

If you can't who will, and why should they?

In the context of the previous post:

The truth is, for the most part, no-one will do anything unless there is something in it for them. In the business world there's always a cost associated with everything, no matter how small. Because everything has a cost, no-one will do anything unless there's some form of profit. If you have paid upfront, then great, but most people don't work that way in the business place. The only people who will do without being paid upfront, are those that either think that you're worth listening to, or those who have nothing better to do. I've come across some different people while working in the games industry, here's my take on some.

The inferior subordinate: not meant to be insulting in any way, I just refer to the fact that the subordinate in this case believes that you (currently) have a better idea of what you're doing than they do. To get this type of person working on the right thing, you can literally tell them to. They'll go and do it, probably get a bit stuck somewhere, probably make a few mistakes, but that's part of the learning associated with this job. If, on the other hand, you take them in hand, tell them what you want done, tell them why, give them a gist of how to do it, and then come back to them every so often (but not so often that you are interrupting them), you will save them from making mistakes, and at the same time the mentor-student bond builds (great thing for both parties in my opinion). So if you are nice about it, and you really do mentor your subordinates, you not only get better work, but you build a mutually beneficial bond, and your subordinates also learn faster, and therefore become more productive at a greater pace than the subordinate that was "told to do it".

The superior subordinate: this is a particularly difficult situation to fix. The problem is that even though you are in a position of power, you are not normally in a position of respect. This is normally a mentor-student relationship that went bad, and can normally only be fixed by putting the subordinate under a completely different lead. The new lead needs to be careful to not repeat the same mistakes the previous, but this isn't always possible. The best way to re-train the subordinate is to give them a clean slate, and assume good things until proven otherwise.
You can usually expect good things of these people, but you have to be on your toes in case things get out of step.

The inferior boss: this is actually quite a good relationship, as long as you aren't intent on making it obvious that you know more about XYZ than your boss. Sometimes it's a fine line, but most of the time private messages, or just a glance at the right time, can get enough of a message across that you have a differing opinion, and that can lead to the conversation about whatever it was. Although this situation doesn't arrive often, it can lead to a deeper friendship than even the mentor-student friendship, as you generally perceive each other as equals.

The superior boss: This is one of the worst relationships in the world. When your boss thinks that your opinion counts for nothing, or when your boss doesn't give you anything to do because they don't think they've got anything easy enough for you to do, that's when you just can't get anything done. You haven't got any respect, so you can't change anything, and you aren't trusted, so you will get blamed when the workload is killing your boss, because you did so little. It's a hateful situation, get out of it as quick as possible. I can't tell you how, it's never easy.

So, in my opinion, appear to be an inferior boss, and an inferior subordinate, and you'll probably get the most out of everyone you meet. I can't do it myself (I'm too bolshy) and it's caused me grief. 've mellowed with age; I think I'm more humble now, and that's a trait I consider to be an absolutely necessary in a coder.