There were two main time modifiers in my guesstimate of the time involved in doing things back in the Dozer post: Simplicity and Tedium.
Tedium is doing the same thing over and over, or making a lot of little, simple changes that are annoying because they have a high volume-to-feature ration. For instance, implementing a state manager to switch from title screen to gameplay to pause and back is simple, but tedius as it involves making a lot of changes to your game code, since you typically started coding right from the gameplay.
Differing levels of complexity exist in every job, from selling tickets at a movie theater to writing advanced artificial intelligence. Tedium also exists in every job — just ask any veteran who has seen combat: their service wasn’t all exciting. So I’m not complaining about complexity or tedium. May as well complain about oxygen. (Though Genesis hints that in Heaven, while still having complexity, we will get rid of tedium. Our at least the tediousness of tedium.)
The reason I note these things is because time is a factor. We need to get money to make a living. I need to start making a living soon, and with regard to the others, if we put it off forever there’s not much point to having a company in the first place. Therefore, we need to balance two things in order for our company to work:
We need to maximize Awesomeness.
We need to minimize Time.
Our Viability as a company is based on whether we make a minimum level of profit, and Profit = (Awesomeness ÷ Time) • Exposure. Also times peoples’ moods, but we can’t do anything about that.
Time = Complexity • Tedium.
This is tricky, because our non-programmers (and often as not, programmers) don’t have a good idea of what is complicated and what is not. Greg once suggested a game where you just run by alternating the triggers on the game pad, and various super-hero battles take place around you and you can affect how they play out by how you run. The gameplay is simple. But the demands of the scripting engine necessary to make an interesting story line and to fit it into the space needed to justify the $1 price tag (the only price anyone would pay for that game) are extremely complex, and the scripts themselves would be moderately complex and extremely tedious. We’d be spending a couple of years on a very “simple” game. And that may have worked for Limbo, but Limbo is a good game, with a distinct and memorable art style, backed by creators who thought it was better and more distinct than it was. It was carried to completion on hubris, and managed to be almost as good as its creators thought, and good enough to justify their expenditure.
We are n00bs. We can’t count on getting it right the first time, or the thirty-first. So we need to take every idea and gut it, cutting out everything that increases Time without increasing Awesome, and cutting out everything that Increases Time without a good Awesome increase ratio, and cutting out everything that increases Time by a certain amount whether or not it increase Awesome.
Now, let’s define some Complexity and Tedium variables so we can analyze this mathematically.
Complexity is an exponential scale. Each increase in complexity in one thing also increases the potential complexity of everything that one thing touches. This is a hypothesis, and may prove to be wrong, but pessimism prepares one for the best as well as the worst. So, levels:
- Simple: Something that can be added with a small function or a couple lines of code. Example: Hitpoints. Camera Offset. Moving a character a constant amount based on whether a button is pushed. Time Factor 1.
- Normal: Something on the level of normal object movements. Moving a character based on Velocity = (Velocity + Acceleration) – (Velocity • Drag). Testing whether something collides with a pre-defined grid. Time Factor 2.
- Moderate: Testing collisions between dynamic objects (characters on characters). Having multiple movement modes. Building non-gridded levels. Basic Particle Systems. AI that can seek, flee, and aim. Time Factor 4.
- Rough: Simple Scripts. Particle Systems that do more than just fire particles in a straight line. AI that can take its surroundings into account. Time Factor 8.
- Hard: AI that can pathfind and can’t see a hiding player. Scripts that do anything worthwhile. Time factor 16.
And so forth.
Tedium can be measured by a straight count of all the things you have to modify to make it work.
I would then add 1.5 times the total for random bugs.
So, let’s analyze ‘Dozer2 thus far:
- Moving the character: Time Factor 2, Tedium Level 1. Running total: 2.
- Rockets: Simple Particles (3), Normal movement (2), and respawning (1). Time Factor 7, Tedium Level 1. Running total: 9.
- Targets: Fancy movement (2), respawning (1), staying in bounds (2), collision with rockets (3), Hit Points (1). Time factor 10, Tedium Level 2 (applies to missiles and target), Running total: 29.
- Explosions: Simple particles. Time Factor 4, Tedium Level 2. Running total: 37.
- Camera Controls: Time Factor 1, Tedium 1. Running total 38.
- Funky Rendering: Time Factor 2, Tedium (target, player, missile, explosion of missile, explosion of target, explosion of fragment) 6. Running total 50.
Murphy’s multiplier: 50 • 1.5 = 75. 75 took me 20 hours, so that gives us roughly 15 minutes per time point.
Now add the fact that the first couple of times I do something, I usually fail. So anything new gets a multiplier of • 3 stacked into it.
Coming up: An analysis of the Mech Game in various forms.