As such, I actually get a bit shocked when I get emails from programmers who are learning about the field or just starting out asking if I have any tips or advice for them when it comes to making their first really big game. I try and answer the best that I can, but as you've probably been able to gather from earlier blog posts, I'm not overly good at explaining things :-S
So, since it's been quite a while since my last blog update (about 2 weeks... Sorry guys...) I thought I'd share with you all a bit of an insight into how things work in the behind-the-scenes part of this project. The reason you haven't heard much from us of late is because we've been dealing with some major coding issues which are only present at all due to bad coding practices. Big fault on our part, but we tried to rush things so we'd have something to show you. That was a bad move, we've learned our lesson, and now we thought we'd share that with you so that if you're new to programming you can - hopefully - learn from our mistakes!
The golden rule for us with programming is planning and documentation. Before you write a single line of code, you should have pages of notes on features, gameplay techniques, design ideas, and - if you want to be really thorough - von neumann diagrams (or some sort of flowchart) to outline the processing behind the screen. A lot of people find this to be far too boring to complete and the fact is, compared to getting stuff done in code, and making working prototypes, it IS boring. But let me tell you, if you're working on a project that is big enough, this stage will save your bacon more times that I can say.
Malevolence is broken up into 3 distinct tiers. The first tier is the subterranean exploration tier (dungeons, tombs, caves, etc) the second tier is overworld exploration (forests, canyons, etc) and the final tier is the settlement tier (towns, cities, etc) and each one is coded seperately since they all operate so differently. This is why you only saw dungeons for ages and ages. For the first tier, we did the full planning and documentation stage. We actually filled 2 and a half 300-page notebooks with our plans and charts for it, and our artists have countless concept sketches so everyone had a clear idea of the look and feel of the game.
As a result, the dungeons turned out to be beautiful. They run beautifully, the look beautiful and all-round they are a real joy to play. However, it went a bit downhill from there. People started assuming that the entire game was just dungeons (rather than reading the info) and we felt that everyone was getting the wrong impression of the game. So we decided to rush it and pump out external environments without the proper planning.
The result was mixed... Yes, we got a working prototype, but it was written so hastily and so un-planned that every time a new feature was to be added, or a change was to be made, the spaghetti code that we had written was so interlocked and co-dependant that a simple fix that should have taken 15 minutes ended up taking an entire evening (which is quite depressing to deal with).
Early on, if you'll remember, we started out with a rough 3D prototype of an infinite forest:
And yes, it worked fine, but it looked like butts and was very clunky. Not to say it was all bad though. We learned a great deal working on it, and there's still some really great code there to be recycled, but in terms of adding things to it, well, it's terrible...
We started getting a bit boned working on it, and people seemed to forget our "get it working now, make it pretty later" philosophy on this project, so we decided to play around with a pretty version, which came out looking really sexy:
But still it was just new graphics built on top of crap code. So we decided to call a mulligan on it for now. It was working, that was the important thing. So we decided to have a play around with town generation, which yielded similar results:
Yes, it worked, but it was written so sloppily that even making a change as simple as allowing different buildings to load with different texture options became a nightmare of infrastructure re-writes.
So what have we learned? If you realise you're fighting an uphill battle with code, JUST STOP. Don't keep pushing on, thinking "ahh, I'll fix it later" because it won't work. Stop, cut your losses, and re-write. If you'll remember, we did it four times with the dungeon code, and each revision got faster, cleaner and more efficient. So we're doing that now with the overworld and towns.
Malevolence is based on a roguelike system. Everything is in a 2D grid made up of ASCII characters (except we generate 3D models from those ASCII characters) so we're currently going through and making the whole overworld/town thing work in a roguelike platform first, then converting the data into 3D models. So for a while, it's going to look like this:
It may look basic for now, but it means that we can VERY clearly see any problems before they blow up into bigger ones.
You probably won't see any of this stage (unless we get a lot of comments asking us to show it haha) but we want this game to run smoothly and beautifully when you all get your hands on it at the end of the year, so we refuse to release bad code to you all.
Anyway, I hope new developers or younger coders out there got something from this. If you take anything away from this blog, remember the two main rules:
- ALWAYS plan everything out before you start
- NEVER be afraid to just start over. Even if it's just a function you're writing. If it's done badly, don't keep killing yourself with it!