Tuesday 8 March 2016

It is time!

The beginning of the year has been very special for us! After consulting my colleague (he's more of a friend than colleague), we decided that it's time to get to work on the official development of the official version of the official game. This means that we'll be scrapping the prototype that took us 4 years to build up! This may seem drastic, but it is absolutely necessary if we want the game to represent our vision, and we really want it to! No half-measures.


So what does this mean?

Well, it's a bit like building a house, minus the bit where you need physical strength. Imagine that you had a vision to build a house a few years ago. Imagine that you decided to teach yourself to build a house and built it on the fly, adding whatever little features you could think of. I'm sure that by the end, you'd have a pretty good idea of how you'd like it to look, but the foundations holding the house together would probably be a total shambles. Still, little things that you hadn't considered would be thrown in, like accounting for the 20ft x 10ft swimming pool you forgot to mention in the planning stages. You're essentially left with this terribly built house, but you know that you're onto something, and you can then build a house based on this design.

It's the same for the game. The prototyping stage was absolutely necessary to decide whether the game idea was even fun. After all, games are about having fun, which seems to be a little bit lost in today's generation of hyper-realism and expansive worlds. It also gave us a goldmine of knowledge and experience to draw from. Most of all, however, we simply learned that there were always more elegant solutions and better ways of designing our hierarchies and systems. Most of the time, we'd think that we'd created the best class hierarchy for weapons ever. The base class would handle all the animation, drawing, bullet creation, etc. Oh wait, what about sticky bombs? These need to be detonated by the player who placed them, so each bomb needs access to that player's input manager. Fixed! It's perfect! Oh wait, what about deflector shields? Vehicles? Grappling hooks? Teleporters? What about THIS? What about THAT? ARRGHGHGHOJJJLHGGDFKGHOHGODHELPME!!!! The whole thing got so convoluted and disgusting that it was enough to make any good software engineer cry. On top of that, the whole idea of inheritance was to save time in the long run, but we spent so much time going through it that it became a hindrance.

This puts us back at the engine stage. The game's all blocks and debug screens. It's not very pretty to look at now, but the prototype acts as a kind of investment. It took years of tweaking, and now the final version can be worked on like crazy without the huge iron walls of apathy. There's probably no such thing as a "perfect" design, and no matter how meticulous you are, you WILL overlook something. Because of this, we have capped a certain amount of weapons with enough variation to provide agency and fun for the player. Once this set of weapons have been created, every future addition can draw from their design.



This puts us in a situation where our game LOOKS worse to the outside observer, but to a programmer, it's a lush and green environment to work in. A huge feature of this new build is the debugging system. While it was a bit of a pain to build, the time we have already saved on debugging is phenomenal! We can see which hash buckets are checking for collisions, grab objects, pause time, toggle gravity, see stats above entities, and more. This stops us having to flick between game and code and helps us develop hypotheses about bugs much faster, ultimately saving us precious development time.

Just trust us! This is a good idea!


New solution with barely any features

No comments:

Post a Comment