Wednesday, August 31, 2005

Language Power

My article "Speed Programming?" talked indirectly about the power of languages. This isn't the first time this subject has come up. For instance, last month I was discussing this very subject with a friend of mine.

In the core of this particular debate was this old article by Paul Graham where he suggested that "programming languages vary in power." and "that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one". As a note he is a Lisp expert and suggests that Lisp is one of the more powerful languages available.

However, ignoring the fact that he chooses Lisp, is this argument valid? I've been thinking about this for a good while now and as my previous article might suggest I'm still looking for an answer.

The only thing that I would say (with a possible difference of opinion to his argument) is that I have found the libraries available also seriously factor into the amount of work you can do in a fixed amount of time - strong examples are Objective-C with Cocoa and Python with the Python libraries.

I actually think the difference between a language and it's libraries is more blurred than clear cut. Consider C and its strings / string manipulation libraries - although you can do them "by hand" really they could be part of the language specification. Another more black and white case is that Objective-C/Cocoa provides advanced data types like dictionaries, vector-style arrays, sets and strings entirely by the use of classes and method calls. These feel like part of the strengths of the language when you are programming although they are really part of the library (framework).

Conversely, I guess, quite often libraries can be used with different languages by the use of shared library bridges. For example SDL is available for many languages even though it's written in C. Perhaps languages and libraries not totally unlinked, but can certainly aid each other?

Tuesday, August 30, 2005

Short Cuts Make Long Delays

The line is, of course, from Lord of the Rings. Where exactly it's used, and by whom, is left as an exercise for the reader. Answers by comment or email.

In my case the phrase applies to the work I did before on a bitmap font routine to replace a system routine as I convert this game from classic Mac OS-only to system-independent (portable).

Originally I thought I could get away with a much simpler mono-spaced font routine - effectively a programming short cut to avoid the extra work of variable width fonts. Sadly it's too wide in many places it's used (DOH!). I then had two choices: alter all the text phrases or re-code the routine. Altering all the phrases is probably impractical and will definitely be slower to do than just adding variable width font support.

Re-coding the routine actually means re-doing the graphics with markers. This is a technique we recently used on another game project. Pretty neat and, apart from scanning code, it's pretty easy. Sadly I can't easily use the routine that was written before because I need 8-bit colour and the previous version is for 32-bit colour.

The longest part is drawing the dots for the spacing metrics on the graphics for each of the four font sizes. Which is what I spent last night doing. Tonight is converting the graphics to a data file and starting to write the input routines. Luckily all the conversions are done by programs I'd written before.

Ah well, you can't win them all.

Sunday, August 28, 2005

Blog Progress?

What! Next Sunday already?? It's difficult to believe a week has passed already since I started this blog or that my last post was Thursday (although there were two that day). My plan was to put stuff about the programming I was doing and the difficulties, interspersed with occasional articles about random coding topics that interested me.

It certainly wasn't meant to be entirely a blog with just articles! Of course, that might (or might not!) be more interesting to the people reading this than general stuff about me and my personal programming projects. (Comments welcome about this of course.)

Perhaps part of the problem with the mix of programming diary to articles is that I haven't - until today - done any programming at home since returning last Saturday from my two week holiday. Part of it is, as I call it, "programmer's block" or, in reality, the inability to start. That whole subject I'm very interested in and I've pondered on a lot. I've written part of an article on it today - I'll see whether I can get it cleaned up and published here this week.

Back to coding; hopefully I'll get an update later today or tomorrow with some details about the programming itself, for a change.

Truth be told, I haven't done any programming at work either, except for some translation clean up work yesterday - although I did start a new C file for something I was planning before I went away - just the translation stuff got in the way. Rest has been meetings and email ... ack! ... enough about work already!

How do I like blogging so far? Pretty good actually. It's more creative, I feel, than reading slashdot in odd free moments. Gives me an outlet for the constant random thoughts that are in my head. Let's just hope it doesn't get too much in the way of the actual coding, eh?


Friday, August 26, 2005

Ant Attack!

One of the magazines I've been reading - Retro Gamer Anthology (P108) - had a long article about Ant Attack. Remember that? The author (Sandy white) has a page about it here

Additionally someone is doing something of a re-write here although there haven't been any updates in the last six months. She is not the only one either apparently.

Thursday, August 25, 2005

Mobile Gaming

There is something interesting happening in the mobile game world. There is a split happening. And it will be interesting to see how this pans out.

I'm taking, of course of Java game on mobile phones vs. the current dedicated handheld game units (Gameboy Advance, Gameboy DS and Sony PSP) which use the console model of controlled releases.

At the moment the Java games are simple - akin to the games of the early 80's. People are even converting old 8-bit titles over. Whether it be Space Invaders or Manic Miner they seem to be selling for literally few dollars/pounds each and there are dozens of them.

Of course things like the GBA, DS and PSP have much high quality games for them - some with significant amounts of development resources behind them.

But things like 3D are being added to mobile phones.

Handhelds like the DS and the PSP cost significantly more than the retail price so, economically, they need to get money off games to make money. This always stuck me as somehow wrong, but is a way of bootstrapping your hardware into the market - and perhaps everyone thought it's was impossible to do any other way when competing against others that sell almost give-away hardware?

And the mobile people do something similar as well - but their money is from the network providers (contracts, tie-ins, etc.) rather than from games - at the moment - but it's difficult to see how they could add games royalties as well to this list without breaking the cross-platform gaming effect that is happening.

As Nolan Bushnell said in Retro Gamer Anthology (P142), maybe open gaming systems will win after all?

Wednesday, August 24, 2005

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: 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.


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.


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 ( 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.

Monday, August 22, 2005

First Post

Well here we are. My first post.

ZedCode (hopefully) will cover (mostly) some of my programming (specifically the stuff I do for 'fun') and my general thoughts about programming. I'll probably include some of my comments/reactions to others programming articles and generally links that interest me.

Since over 50% of my spare time programming is games related there will probably be a few links about that!

I'll try to avoid commenting on anything I'm not an expert on (pretty much a very limited sub-set of some coding issues) and avoid the sin of a whole bunch of other bloggers/tv experts :-)