Archive for November, 2011


Version Control

In my early programming projects, I didn’t have version control. Or a bug database. Or scheduling software. A single programmer can get away without these things.

Instead of version control, I would make a daily backup and archive a stable version every month. Instead of a bug database I had sheets of A4 paper. Instead of following a shedule I just did stuff.

Now, the only one of the above I really don’t want to work without is version control. It’s more than a backup. It’s a detective tool for tracking down bugs. It’s a log of every change that was ever made to a program. A way to share work-in-progress across multiple machines. A way to branch and merge different releases. It allows a multitude of programmers to work together without stepping on each other’s toes. (Ok, they still do. But can usually sort it out again.)

I sometimes wonder why more non-programmers don’t use version control. Most of the the benefits above would apply to writers, designers, artists and others. I think the technical aspects could be a barrier. I use Perforce because it’s fast, powerful and reliable, but even I would be put off if I didn’t already know how to use it. Subversion is easier to understand, so that’s the one I would recommend.

I am currently on revision 10. My bug sheet is empty.

 

Advertisements

Mazes

As a way to get started without messing about with game design or any of that nonsense, I decided to make a maze generator. It lets me get something interesting on the screen, and I should be able to use it later.

A bit of research showed that there are many maze generation algorithms, of varying degrees of cleverness. I picked a stupid one – recursive backtracking – because it’s easy to write and makes quite twisty mazes.

I realised while thinking about this that mazes with thick walls (Dungeon Master) and thin walls (Bard’s Tale) are actually logically the same, it’s just that the passages between cells are stretched out for the thick version. Great, I don’t have to make that decision yet.

You are in a maze of twisty little passages, all alike.

I eventually want to write a small 2D game, something easy to get into and fun to play, with some strategy and RPG elements. But that’s not the goal right now. For the moment the point is to have fun programming, and in the process to find a good working environment.

To this end, I’ve looked into various systems:

  • XNA, which uses C#, a nice language, and allows code to run on the XBox and windows phones. But it’s not portable to any other system, and carries a lot of baggage which I might end up fighting.
  • iPhone, but that requires a Mac and learning Objective C – expensive and not fun. I do like the iPhone as a system though.
  • Python – quick for development but code runs slowly. I shouldn’t even have to think about CPU cycles on this project but in Python I might.
  • Curses, as used in Roguelikes. From a coder’s point of view, I like the purity of having no graphics. But I think even programmer graphics improve visual recognition and therefore gameplay.

So I decided in the end on straight C++ and SDL. And spent two days getting the basics up and running. This is what I hate about C++. (Well, among other things). But it’s done and I can start having fun now.

This is why we need artists.

Decisions

Programming is full of decisions. Apart from the simplest or most familiar tasks, you don’t work on autopilot.

There are many ways to get a program to work. But some ways are better than others; they cause fewer headaches along the way, make the code easier to maintain, lead to fewer bugs in the end. To find those ways, you have to make decisions, constantly, correctly and quickly.

There are big decisions at the start of a project. Which system to develop for (or should it be cross-platform?), which language to use, which API. These choices can seriously affect the progress and outcome and should be considered carefully.

Then there are lesser, but still far-reaching decisions. What kind of coding standards to follow. Which paradigms to embrace or reject. What sub-systems to create.

Every line is a decision. What algorithms to use. How to organise the code and data. What comments to write. What checks to put in.

There are a few types of decision that can paralyse progress and for these I have some general guidelines that I follow:

  1. Should you trade coding speed for accuracy and maintainability? Maybe – it depends whether you are writing production code or not.
  2. How much planning should you do in advance of coding? As little as necessary. Coding drives thinking and you will find out more as you go.
  3. Should you write top-down or bottom-up? Write interfaces top-down. Put yourself in the place of the user. Write the implementation bottom-up. Add as little as you need in each step in order to test it.

 

Most importantly, keep the code simple and clear. You (or someone else) will need to be able to read it in six months time and understand what decisions were made and why.

Above all else ... clarity.