Speed Programming?

This article is not (entirely) about magazines. Bear with me.

I did wonder whether paper computer magazines were going to die with the popularisation of the Internet. A lot of the magazines of the late 90s and early 00s appeared to be having problems. I certainly found them mostly a waste of money - I could find better, more up-to-date information on the Internet. But like all things they probably just needed to adapt and change. Of course computer magazines have done it a few times before already.

So what has this got to do with programming, I hear you (rightly) ask? Well, over the last couple of weeks I've finally got some time to read some retro gaming magazines. As well as stirring some good memories, give a few decent interviews of games programmers past and present, reviewing some of the systems that I wasn't overly familiar with, there were a couple of articles that caught my eye.

One, specifically in Retrogame Issue 11 (page 9), was about a Jonathan Cauldwell who (amongst other things) still produces Sinclair ZX Spectrum titles to this day.

Now the kicker: during the ORSAM show in 2004 he wrote a game in 5 hours. The games called Lunaris and you can find a screen shot and along with a short description here: http://members.fortunecity.com/jonathan6/egghead/id7.html. It's basically a thrust style game with 6 screens.

I find this quite remarkable. He mentions that he has quite a bit of pre-written source code for producing sprites of various types, different type of multiplication, high scores, etc. But even taking this into account, it's still remarkable.


BEHIND THE SCENES

Perhaps, of course, we've recently become conditioned to expect long times - with complicated system interfaces, poor languages and so on?

I do remember that I could create a playable simple defender clone as a kid in about 2 hours in Sinclair BASIC. So what's happened? Is it that we are tackling much, much bigger projects or are we using the wrong tools for the job?

It's certainly the case that the projects are bigger - in size and scope. The whole 3D thing, for instance, adds a whole other dimension to the problem (sorry). We expect big maps. We want (or are required to have) flexible monster/NPC/creature control. Data files need to flexible (and changeable) for the 'content providers'. At every turn we add extra complexity.

There is another thing: perhaps people don't know the systems they program as well as before. This is magnified by several things:

• We are using high-level languages which hide what is really going on.
• We are all on-top of operating systems (of some sort), usually with complicated API's.
• We most often are not the only one programming and certainly not the only one creating the whole game. Level design, concepts, design, requirements, artwork, etc., is usually outside our control as programmers.
• We leverage various libraries (3D engines, sound systems, physics engines, embedded scripting systems and on and on) because it's just impractical to write all this stuff ourselves with the technologies changing so fast that we can't use previous project's code.
• The underlying hardware platforms are changing. Even if I write Windows or Mac games (or applications) the hardware changes normally mean more testing.
• The IDE, project management or build processes make things more complicated - even though they are meant to make things simpler.
  
• They might be working with code written before by someone else (the old "look, just learn it and change it"). I think you always know your own code better, even if you've currently forgotten how it worked.

CHANGES?

Practically, the only thing that we can change easily, I feel, are the tool-set and programming language.

Let's look at what I'm doing in programming languages and see what possible things there are to speed things up.

Most of my game programming nowadays is done with a C++ compiler on Mac OS X with a 'zero-effort' Windows Port - all using the SDL (www.libsdl.org) for the 'low-level' access. This avoids me having to use OS specific system calls (something which I have done in the past - but I feel, in this day and age, it's stupid having to write to multiple APIs just because the OS manufacturers are wanting to protect their platforms). It's also a relative simple and well structured API (easy to learn).

However, I'm getting to think, more and more, that C (at least) is not the fastest language to program in (although I know it very well having programmed it at home and professionally for well over 10 years now). C++ has some interesting high level constructs (like vectors, lists, classes) which I'm using as much as possible (mostly limited by the large language size) but packed in a form that requires several times the amount of lines that, say, Python or Objective-C require for the same construct. Of course languages like Python and Objective-C are much more dynamic - which has it's own advantages and disadvantages.

I've toyed with the idea of BASIC (e.g. RealBasic) or Python with SDL (e.g. PyGame) for speeding up the coding games - I've had quite a bit of success using these for small utilities. In my humble opinion RealBasic may have scaling problems (YMMV). I don't know about Python and scaling, however, Python can have interesting problems with 'canning' an application (since it's interpreted), although not impossible to embed it all within a C shell.

Of course, Jonathan did a game in 5 hours in assembler. So maybe I'm missing the point with looking for high level constructs. I have done a fair amount of assembler in the past. And people in other languages (e.g. Forth) believe you can do fast coding without high-level constructs. So perhaps it's a technique thing?

Or maybe I'm just searching for a 'speed-coding' silver bullet or 'holy grail' in vain.

However, his attempt has certainly spurred a new interest here in creating a game in a short time like a day or a weekend. My plan is to finish my conversion work on a project in progress and then allot a specific weekend.

Back to coding.