David Mason

Total development time: 1340 minutes (22 hours, 20 minutes).

The game-in-a-week challenge has come to a close. It has been an exhausting experience, adding a half-time workload to my full-time work week, but also a lot of fun and very rewarding. I haven’t tracked the extra time spent on the write-ups, but it would have to be at least a couple of extra hours on top of it all. Since I’m completely drained, I’ll structure this wrap-up in self-interview format to keep my fatigued mind on track.

Science Crowbar

In broad terms, the game now has all the major elements I expected it to have by the end of the week, but there are some significant differences from the original picture in my head. Most of the differences are simplifications, but a few are due to a combination of rushing and contingency, and one is due to a limitation of the free version of Unity that I didn’t have time to work around.

Simplifications are mainly around visuals, movement and animation: I used only a single scientist model and didn’t use a variety of textures or scales, which would have helped them look less like clones; the scientists aren’t animated in any way when producing science, whereas given more time I would have like them to perform various science-y actions that would be visually linked to changes in the science bar using a ‘flow’ of animated particles to the science bar; enemies have restricted rotation, whereas I would prefer to allow them to rotate freely so they can be knocked over by a well-aimed strike and have to right themselves; enemies teleport to scientist heads rather than being animated climbing up and latching on, which would add the ability to carefully knock or pry the enemy off before it is fully attached, while trying not to hit the scientist; zombified scientists don’t attack their neighbours, which would add an extra dimension to the game and make things more hectic.

Rushing-related changes were mainly the environment textures. I had originally pictured a more metallic grated flooring with some embedded lights and other features, and metallic paneled walls with plenty of consoles, lights and other features, but in the late-stage rush I grabbed some of the first textures I found that looked alright. The room is also quite bare; given time I would have added features such as broken areas of flooring, exposed wiring, miscellaneous fixtures, blood smears, dripping/pooling water, and so on. Mixing up such features as well as room textures and dimensions would give more of a feeling of progressing through different areas.

The difference that I think has the biggest effect on the feel of the game environment is the lack of shadows. The free version of Unity has some significant limitations on out-of-the-box dynamic shadow support, and the limited timeframe left me no opportunity to look into alternatives. Without the time constraint I would have spent the necessary time to get something akin to the shadows in Alien Swarm.

I won’t make a direct comparison between SDL and Unity, that would be pointless since SDL is a simple wrapper around low level APIs and Unity is a fully functional game engine – it’s an apples and oranges comparison. I could compare the languages but I’d be writing all night – suffice to say that C++ is a lot easier to get wrong and a lot slower to develop.

The more relevant comparison to make is the overall experience. Working with C++ and SDL is all about building up from nothing and putting together something over which you have complete control. The control is nice, but it comes at an enormous cost in time. Unity does a lot for you, primarily with asset importing and management, and with object interaction, but also in numerous other areas too extensive to list here. This makes a huge difference to the development process: it lets me be thinking about what elements I want in my game and how I want them to interact with each other, without being dragged down into the minute detail of exactly how everything will be rendered. In short, Unity gives you the wheels so you don’t have to invent them, and throws in the chassis, engine, drive train and diff for good measure. They leave the steering, body-work and paint job up to you.

As a software developer, I’m most comfortable with the coding side of things – in a small project like this I didn’t hit anything that really challenged me in that area. Some other parts were made easy by Unity, such as getting the basic level put together, positioning elements, attaching scripts and dealing with collisions and basic physics interactions.

Scoping was also easy, which sounds a little counter-intuitive  with such limited time, scope-creep was basically impossible. There wasn’t an opportunity to incorporate any new ideas other than the most trivial tweaks and corner-cutting. Since I knew I didn’t have time to add anything, I didn’t waste any time entertaining the idea of major new features.There were also some elements that were made easier simply because I had a good excuse to cut corners. I went for simple movement in a simple environment, so there was no need to start pulling out A* or even greedy search – I’m interested to see what kind of path finding is baked into Unity or available as libraries or extensions – I’ve been directed at A* Pathfinding Project and iTween so I’ll give them a try, probably in my next project.

The major group of activities that didn’t hold up well was anything new. Typically I’ll spend a while reading up on and trying out technologies or techniques with which I am unfamiliar before I start using them in a project, but with less than 24 hours of development time I could only afford to do quick research on things as they came up.

Model manipulation and positioning gave me some strife when combined with parenting. This feels like another inexperience thing, but it gets a special mention because it looks like something with several moving parts, all of which I need to understand to use it properly.

Creating atmosphere gets an honorable mention here too, basically because there wasn’t time for it. Once I have all the major elements in place, I would ideally spend some time playing with lighting, shadows, models, textures, audio and animation to get the game feeling the way I want. I was only really ready for this as I made the last changes to this project, so it was something I just couldn’t fit in. I ended up with a much brighter and more sterile-feeling scene than I would have liked.

Has this challenge highlighted any major gaps in your knowledge?

The challenge has been an exhausting experience, but also a very fun and rewarding one. I’ll definitely look at similar challenges in future, after I’ve had some time to recuperate, and with some appropriate changes to help maintain a bit more balance.

I think next time I would prefer to allocate a little more time and a more ambitious project, e.g. Friday to Sunday spanning 2 weekends. This project was fun, and about right for my limited experience with Unity, but next time I should be a lot more on top of the fundamentals so I’ll want to aim for a more polished product with a bit more depth. I could even look at using some leave and taking on something even more ambitious, like getting Grey Out to market in 10 days.

Assuming I was taking a challenge during a work week, I would also be looking at ways to prevent the challenge distracting me too much from other aspects of my life – it isn’t the end of the world to have dishes pile up for a week, but it is something I should be able to avoid. Ideas for this include more specific time constraints during the week (e.g. hard maximum of 2h on work days), and a change to morning-only development (i.e. get it done before work).

Finally, I would encourage others to follow along with their own challenges – the same or different doesn’t really matter as long as they’re happening at about the same time. This challenge was a bit of a spur-of-the-moment thing, but with a little more foresight I’m sure there are plenty of people keen to challenge themselves.

Definitely. I’ll keep a copy of the one-week version of it, and make that available soon, but there is plenty to learn as I take the project beyond the working-prototype stage and flesh it out into a complete and polished game.

Update: play Science Crowbar online now! Big thanks to Blocky Pixel for hosting.