Alien Experiment Laboratories

October 22, 2006

Games that never were - episode 1

A little history here to fill in the time.

Around 1990, the people who would later spend a significant length of time working on “Wingnuts” decided that one of our favourite board games at the time, “Dark Future“, could be made into a pretty cool turn-based game.

wos_title.png The project was provisionally titled “Wheels of Steel”, a name I think was used later on for some PC game or other. (Or am I thinking of the rock song?) It was pursued as far as my creating a few screens for use in the game, and a mockup of what it might look like, by which time we were all starting to move to the Amiga.

The story doesn’t quite end there, though. “WoS” was refined a little, and became something we called “Murphy’s Law”. This was being coded in AMOS within a week of me first owning an A500 and might actually have stood a chance if we hadn’t been in such a rush to get started. It stalled out, but not before a half-working demo was up and running. But that’s another story.

Anyway, here are some mock-up screens which I did (and which were the last Spectrum graphics I’d do for about 12 years)

wos_gamescreen.png
The main game screen would have looked something like this at the start. The idea was to have it pointer-driven, similar to Carrier Command and the like.

wos_mockup.png
And this would have been during gameplay.

wos_weapons.png wos_status.png wos_damage.png
Status displays: Weapons selection, vehicle status and detailed damage report.

I reckon it would be fun to resurrect this idea, probably as an open source project using SDL and OpenAL. It would be a good first project for me to get to grips with those libraries without having to worry too hard about realtime-ness, and of course a lot of the code and simple graphics already exist from “Murphy’s Law”. It would also lend itself well to the open source ideal of “release early, release often”, with incremental feature adds, not to mention network play or even play-by-email.

October 16, 2006

Source control and project management with Unfuddle

I’m a recent convert to the idea of using source control systems such as Subversion. There are some huge advantages to be had from it, like being able to tag release versions and recover from stupid user-level mistakes (like the time I tried to copy the contents of my Spectrum +3’s RAM disk to my project floppy using COPY "M:" TO "A:" instead of COPY "M:*.*" TO "A:", erasing everything on the disk).

But I’m not here to discuss those benefits of source control. Others have done that, better than I ever could. I’m writing because it’s a good way of keeping offsite backup, if you have a suitable repository. So, in the event a huge meteor lands on your office, destroying everything within 3 blocks, including the bank vault you kept your CD-R archives in, your work will still be there.

(I assume, of course, that you weren’t in the office when the meteor arrived.)

Berlios and Sourceforge work well for open source projects, but this one is closed source (sorry RMS!). Some hunting around led to Unfuddle, which meets all my needs for this project, and is free (as in beer) for the basic single developer account.

It provides a private Subversion repository where I can keep my work safe, along with some pretty handy management tools, so I can set milestones (and then watch them slide gently by while I’m preoccupied with real-life stuff), track bugs, and generally try my best to keep things on course.

Everything works through a simple to use, slightly AJAX’y Web interface which makes both Berlios and Sourceforge look rather clunky and unwieldy. The SVN repository is available through HTTP for check-in and -out but can also be browsed using the web interface.

I’m impressed with this offering. The free version is limited to one user per project and 15MB of storage; plenty for a typical one-man retro-platform development. If I was running a small independent dev team, with a definite aim of making money, the paid-for accounts would be worth a look too.

October 11, 2006

Move it!

The site has successfully moved to a whole new server, after some fudging around to get the Wordpress database moved over.

It’s also moved to this, its real home domain name now, not that dumb subdomain it was on before.

If you visited the old address and are not seeing this page instead then…um, never mind ;-)

October 2, 2006

Tools of the trade, then and now

What toolset does a budding retro-programmer utilize, and how does it compare to the situation back when these platforms were current?

Well, back in the 1980’s, we had a glimpse at what a professional ZX Spectrum game developer used, in Crash! magazine’s Cecco’s Log feature.

The Spectrum is actually developed on an IBM compatible PC which runs a fast Z80 cross-assembler that can compile a 200K source file in a few seconds. After the program has been assembled, it can be downloaded to the Spectrum via a parallel link, ready for testing.

The graphics are all designed on an Atari ST using the Advanced Art Studio. This package (programmed by my good friend Chris ‘8-bits are crap’ Hinsley) also features a ‘map editor’ that enables all the screens in a game to be chopped and changed very quickly. The ST format graphics are converted to Spectrum format data to be incorporated into the main program.

All of which was far beyond my wildest dreams. Compare it to the tools I was using around that same time: a Spectrum +3, some blank floppy disks (173k formatted per side), squared paper for designing the graphics, and a crappy little assembler. The 24″ RGB monitor I had back then made up for it somewhat.

The tools I can bring to bear today as a hobbyist, though, leave even the mighty Cecco’s setup looking a bit tame (not to mention space inefficient!).

Development system The basis is a Dell Inspiron 8200 laptop with 512MB memory, an upgraded hard drive (100GB) and a 100GB external USB drive for backup, running the current version of Ubuntu Linux.

The code is written, using the Vim editor, mostly in C, possibly with some embedded assembler, and cross-compiled using the open source Z88DK development toolkit.

Graphics would be done using the SevenuP graphics editor, but right now I can’t get it to run or compile in Ubuntu, so I’ll be falling back to the old-school ways unless I figure that issue out.

The “Spectrum” is provided by the Fuse emulator, which can emulate all the major models and clones of the Speccy, and load the tape image file which Z88DK creates, pretty much instantly. This is especially helpful since I currently have no way of getting my actual Spectrum hardware to put out a useful display on the crappy NTSC tellies here in the US. Running under emulation also allows some pretty complex system monitoring and debugging to take place.

For documentation, I use LyX or plain ASCII text formats.

Total cost, not including the laptop, is $0.00; all the tools are free and open source software. Perfect for on-the-cheap homebrew development!