Please note that all screen shots displayed in this blog are works in progress and in no way represent the appearance of the final game. Check out the main site here.

Be sure to follow us everywhere with these links!



Sunday, February 26, 2012

Advice for New Programmers

It's funny, really. As a long-time (12+ years) programmer, I still don't think of myself as a long-time programmer. I'm constantly learning and trying new things - so much so that I always kind of think of myself as a n00b when it comes to games programming.

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!
Follow those two rules and your game will be much better for it!

4 comments:

  1. This blog post is very helpful!
    I'm currently working on making a roguelike game right now, and I have barely any coding experience so I'm sure my code is an absolute mess. I'm making it in Python, and I only just learned how to code Python about half a year ago.
    I'm probably going to need to rewrite most of it eventually.

    ReplyDelete
    Replies
    1. Never be afraid to! I've tutored a few people in programming before, and I always do the same thing. I get them to write their first game, then tell them to scrap the entire thing and write it again from scratch. Then, once it's been made again, I tell them to scrap it again and make it a third time. They absolutely HATE me by the end of it, but they also have a VERY thorough understanding of the code and the language!

      Delete
  2. I've been following this for some time now as it's always interesting seeing other developers progress through their work. I've also had some terrain ideas from watching this go by on the TGC forums.
    Always good to know that there are people out there who don't give up or get too distracted from their programming. 12 years is a long time and it shows in your work. Keep it up. I've been at it for 30 years and feel like I haven't made half the progress that you have in completing something big.
    -> WLGfx (wlgfx.co.cc)

    ReplyDelete
    Replies
    1. Thanks for the kind words, WLGfx! While a big part of our enthusiasm for the work comes from dedication and pride, a HUGE chunk of it has come from the amazing public response to the game! It really drives us on! I only hope that it sticks around when it comes to people buying it! :-P

      Delete