It Lives!

Just a quick update today -  a video to show the basic interface off. The verb can be changed via the verb buttons and also a right click, both of which were used in this video. You can also see the hotspot label in action, picking up an item and using it as the current item to detect clicks with, the player changing rooms, and music changing in each room.

It's not much, but I had to figure out how to set all this up before I could start building the actual game itself. Now that all of this structure is in place, I can start putting some actual adventure game elements in.

I captured this using DOSBox and reading the game files from a floppy drive - my hope is that the completed final game will fit on and run happily from a single floppy. Whether or not that's doable is still uncertain, but I have my hopes!

Sorry for the poor video quality, I know nothing about editing videos.

A Strange Obstacle

I hit an interesting problem today, and while I think I've figured out how to work around it, it still makes sense to post it here. These little issues often pepper the development process, and it's interesting to see what sort of shapes they can take.

Something I want to implement on the interface is to have not only the current verb button highlighted, but if an item is selected for use, to have the item's icon highlighted. This shouldn't be too hard - it's simply a matter of finding the right function to change an item's graphic, and then knowing how to use it. A search through the documentation led me to the function SetInvItemPic (int inv, int sprite_slot) - perfect. This is designed to change the inventory item "inv"'s graphic to the graphic in the sprite slot represented by "sprite_slot".

I added two inventory items and put in the code necessary to change their images to the highlighted images when they're selected, and back when they're not. It's extremely straightforward logic to put in place - and I'll probably be explaining how it all works later - so I didn't even bother testing the function to make sure it works (honestly, what can go wrong with such a simple function?)

When I compiled the game to test the functionality, I got an odd error. It claimed I had specified an invalid inventory item. I figured that maybe instead of calling items 1 and 2, it might start at index 0, and therefore need me to call items 0 and 1, but checking this proved this wasn't the case. How odd.

I tried substituting the direct values with a check which gets the current active inventory item number, rather than relying on preset integers. This also threw me an error. How could it claim that the item number was invalid when it was pulling the item number directly from the selected item? It makes no sense.

Frustrated, I went and tidied up a script module for work, figuring a break from the problem might help. That done, I came back to the code and tried clearing out all instances of the function, this time simply calling it once on game start, just changing item 1's graphic, to see if I could get it working by itself. It crashed again. I changed it to item number 2, and tried again.

It worked. Confused, I went back and changed it to item 1. Again, a crash. I then created a new item, item number 3, and tried changing the graphic of both 2 and 3 on game start. It worked perfectly.

I went back through and re-implemented the functions to change the items upon mouse selection/deselection - however this time using items 2 and 3, rather than 1 and 2. Tested the game and it worked perfectly.

The issue, then, seems to be that for whatever reason, this function cannot work with item #1. I have no idea how this could happen, but AGS was build by one chap, and this is an obscure function in an old version of the engine/editor. Perhaps there's some bug that snuck in here that was fixed at a later date.

Whatever the case, it shouldn't be too hard to work around. All I need to do, seemingly, is to have item 1 be a dummy item that can never be collected by the player. This means I'll never have to change its graphic, and hopefully will never have an issue with this again. As frustrating as it is to lose time while stuck on problems like this, it's nice to find a workaround. Hopefully I don't find too many more bugs like this down the path.

Making Music

In the past, I've often collaborated with musicians for my projects. I never had a great deal of experience with recording music, despite having some basic knowledge of writing music and playing it, and I was always trying to focus on doing all the other elements. This time, though, I wanted to see how easy it was to make simple, pleasant game music first hand. As detailed before, I'll be using Midi Maker.

When I was starting out, I had to choose between the MIDI format and the MOD format for music. Both are great formats which some of my favourite game soundtracks have been written in, such as John Broomhall's awesome MIDI soundtrack for Transport Tycoon, and my choice came down to two factors - AGS 2.3 doesn't support MOD music for AdLib sound cards, and I'm more familiar with the sounds I can make with standard MIDI files. MIDI it is, then.

The interesting thing about MIDI music is that it's not really a recording of music as such. Instead it's a set of instructions, which then requires a seperate piece of software to interpret those instructions and turn them into music. This means the format has three interesting features which are worth noting.

Firstly, the "songs" are extremely small - 3kb for 45 seconds of music - which is excellent considering I'm trying to squeeze a game onto a single floppy disk. Secondly, it means that a piece of music will sound quite different depending on the piece of software that is interpreting it. This is important to keep in mind, as it means once a piece is composed, it has to be checked in the target software to make sure it sounds right. Lastly, because it's not a recording, but a set of instructions, the music will always loop perfectly if one chooses to make a looping track. Lovely!

Midi Maker has a very simple, tracker based interface which means you can compose your music without the need for a MIDI controller (piano keyboard) - a mouse is enough. After selecting an instrument, it's merely a matter of placing the notes where you want them, and then moving on to the next instrument.

There are 8 channels to be used, and a channel can only have one note playing at a time. That means that if I want to make a chord, I need to use several channels to have all the notes play. For example, if I want to play an E major chord, I need to have one channel playing the root note (E), another playing the major third (G#), and another playing the fifth (B). If I want to also play the octave of the root (or any other note) then I require a 4th channel. This isn't too bad - it's a little like playing the piano with 8 fingers, but each finger can play a different instrument.

Something else interesting to note is that certain instruments don't really sound good outside of certain pitch ranges - either they're too quiet, or too loud, so the usable range for notes is somewhat limited. This means that to get certain chords to sound right, you have to try different inversions until one sounds good.

The benefit of having a different instrument per note in a chord is that I can stick with a dominant sounding one for the root of each chord, and therefore keep it quite strong even when the root isn't in the bass of the chord.

Music theory aside, once I finish making each track, I have to load it up in AGS. Windows' general midi driver has a very different sound to the way AGS sounds, and I've found that some instruments that sound quite subtle in general midi are overpowering in AGS. I can't change the volume level of each channel, so in certain cases I've had to completely cut a channel when it was too overpowering.

I've still a bunch of tracks to make for the game, but I've enjoyed learning to make MIDI music so far. Because using a tracker is so neat (errors are effectively impossible, and any misclicks are a 2 second fix), it's very quick to put together a track for the project.

Creating a Font

A strange quirk of AGS 2.3 is that the only font format it supports is the format from old Sierra games. This means that you either stick with the default fonts, rip the fonts out of old Sierra games or make your own.

I've been using AGS long enough that I cannot stand the default font, it's synonymous with a project that's in the early phases for me, and I can't think of any Sierra games with fonts that would suit the chunky style of font I quite like using. The solution was clearly to make my own.

To work with the font format, I can use Radiant FontEdit, a simple, easy to understand program designed by a fellow AGS user specifically for working with font formats AGS can use. There's very little to it, save having the patience to sit there and make each character, pixel by pixel. I taught myself calligraphy earlier this year - this seems quite pleasant and fast in comparison.

The only real issue I had was that the program mysteriously closes whenever I press [enter], meaning that I had to force myself not to do this when entering values in fields after losing my work around 7 times. I also split the task up over a couple of days so I didn't find it too tedious.

With my first attempt at my font done, the next step is to try importing it into my game and testing it.

A couple of errors here - clearly I accidentally placed z where y should be, the letters are spaced too far apart, f,t and i have different heights which looks awkward here. Back to the editor to make some fixes:

And import it back into the game:

I'm happy with this! I'll be keeping an eye out for odd looking letters as I start adding messages into the game, but for now it's time to move on to the next task!

Obligatory Cat Photo...

Here's a photo of my cat watching me suspiciously while I put together the code for the Lucasarts style status line. This is where he spends most of the day.

Adding a Character

With background graphics taken care of, it's time to go the next step and have a character sprite display over the top of it.

Because I'm using an indexed palette, I need to manually tell AGS the colours I want it to use for the characters in my game. This involves going to the palette editor and manually inputting RGB colour values for each individual colour in the character sprites I will be using. Happily, I'm going to be sticking to a very small colour palette for this game:

To convert the RGB values from the 0-255 values we use today to be recognized by AGS, which has a 0-63 colour range, I need to divide the values by a factor of 4. I believe the 64 values of each hue in VGA mode is a relic from the EGA mode which had a total palette of 64 colours to choose from (feel free to correct me on this if I've misunderstood).

The colours in the palette here that are marked with an X are reserved for the current background's colour - I can set these off or on if I need more colours, but for the small number of colours I'll be using on both sprites and backgrounds in this project I can leave this as is. Those colours marked with an L are locked colours - default shades I'm not able to edit.

With the hues in the palette (as close as I can get when dividing by a factor of 4), I import the sprite at the top of the post to the game. The result:

Here, several colours have been badly converted to other entries in the palette. It's messed up enough that I can't use this in the game. However, the backgrounds have been painted with the same base colours as the sprites (with blending providing the wider range of hues), so I should be able to set the sprite to use each room's background palette too, right? I tried this, and got a pretty good result:

That's quite good! A little different to the original sprite, but it's much closer to how I originally drew the sprite. Although all backgrounds share a common palette, I feel it's best to check with this sprite over another background. The result:

Not good. This is more messed up than I thought possible. Clearly I'm not going to be able to rely on room palettes after all, then. I'm going to need to figure out how to get my sprite palette to conform to the sprite palette I've put in the game without being able to get the exact hues right. This in mind, I took the palette in the game, imported the game's palette into Aseprite as the colour palette for an image, pasted the original sprite in, and fixed up the few colours that converted badly. This means the sprite now has every hue exactly the same as the hues present in the game. I import the sprite and test:

Perfect! To be sure, I test in another room (although now that I'm not relying on room palettes to dictate sprite colours, this should affect nothing - still, for the sake of testing):

Lovely! With this in mind, every sprite I create for the game now needs to be saved with the exact palette the game has. This should ensure that every sprite is imported perfectly, with no colours messed up. Let's hope - I don't think anybody could handle another post with the word "palette" repeated this many times ever again.

Getting a Scene Ready

The first thing I'll need to get started is a background for one of the rooms. Without this I can't test anything else, so it's a natural first step. For this project I'm going to be using graphics I did some time ago. Here's the first scene I'm going to be using:

The space down the bottom of the image is where the interface is going to go - all of the scenes will have this gap. This takes the playable screen resolution from 320x200 to 320x144 - a common size in adventure games from the early 90s. The issue with this image, though, is that it's not going to work with the game, which has a colour depth of 256 colours. This image has thousands of colours, and so I need to take it from a standard PNG to being a PCX with an indexed palette.

When starting a new image in Aseprite, there is a choice of RGB colour, grayscale or indexed colour. Indexed colour suits this project, so picking that and specifying a canvas size of 320x200 will set the image up so that I can paste the old image in to convert it to the colour depth needed. The palette is still a standard palette, though, so anything pasted in now will use that default set of colours and become quite skewed:

To fix this, I need to specify the image's palette before it gets loaded in. I go to the palette options, select 'load palette', and select the original PNG image that I'm going to be pasting in. This tells Aseprite which colours I'm going to be using, and it selects a limited palette from the thousands of hues in the image I loaded. Now with my palette in place, I paste in the original image:

That's more like it! You can see that some banding and quality reduction has occurred, but for the most part the image remains quite intact. I can now save it as a .PCX file and import it into the AGS room editor:

Now that the palette has been set, I can paste all of my backgrounds in (because they're all painted with a very similar palette. If you have very different scenes in terms of colours used, you'd want to load a new palette each time). With that done, I can import them into the project and move on to the next step.

The Tools

Now that we've had a quick look at what I plan to do, let's have a look at how I plan to do it. While the building of the game itself is something I am going to be doing entirely in DOS, I'm going to use Windows based applications for creating assets, simply for reasons of convenience and familiarity.

The game itself I plan to build in Adventure Game Studio 2.3. Having downloaded various versions and compared system requirements, this appears to be the last version of the engine that can be used in DOS. You can find a copy of it over on the AGS Archives. For those of you unfamiliar with AGS: It's an engine aimed specifically at point and click adventures, with an easy to use editor which also features a high level scripting language. 2.3 is several versions earlier than when I started using the engine, and a lot has changed, so I'll be needing to refer to the manual plenty and trying to figure out how to do what I want, but it should be a fun challenge!

To create the graphics, I'll be using two different programs. One is my standard version of Photoshop that I use every day for work (I use Elements 12.0, but any modern version is good). The other is going to be Aseprite, an affordable, light and nice to use pixel art program, which has plenty of nice features and is good for working with indexed palettes (essential for this project).

For testing and fiddling with things I will be using DOSBox, a very cool emulator which I use all the time for running DOS programs on modern PCs. Please note: due to the lack of support for the "edit" command, you cannot edit AGS scripts in DOSBox. To code the game itself, I am running Microsoft DOS 6.0 on a seperate PC. I'll go into more detail about this later, as it's something which had me a little stumped for a while.

To make the music for the game's soundtrack, I'll be using Midi Maker, a very simple, easy to use and free program. This is the only MIDI creation software I've ever used, so no doubt there are alternatives which others will prefer, but having played around with this for a short while, I'm confident it'll be everything I need to create a simple soundtrack.

To create a font for the game, I'll hopefully be using Radiant FontEdit, a small, free utility that allows one to create their own fonts. Due to AGS 2.3's very limited font format support, this appears to be my only real option for having a custom font in the game. I've no idea if it will work - we'll cover that when I get there.

Finally, for transferring files, backing up, and testing, I'll be using a USB 3.5" floppy drive, so I can get files from my Pentium 120 to my computers with internet connections and the like. These are relatively inexpensive, and are a very convenient way to get any modern Windows PC with a USB port to read a floppy disk. I've never tested them with other operating systems, but no doubt there devices compatible with Mac and Linux, too.

If I find myself using more than these, I'll update this page to reflect this. I'm quietly confident that this will represent everything I need to create a small game. Naturally, there are still many unforeseen challenges that will no doubt lie in my path, and I'll be writing about those as they happen. For now, however, we have a plan and set of tools, so it's time to start building a game!

The Challenge

Before I started working on this project, my first step was to identify the challenges I was going to be facing. I'm fairly familiar with the process of making games, so I felt my biggest issues were going to arise from the areas I'm not familiar with, or somewhat less familiar with.

Indexed colour palettes:

My intent is to create a game with VGA graphics - 256 colours at 320x200 resolution. While I'm familiar with working with smaller palettes, I've never worked with a strict, indexed palette before. Figuring out how to work with these is going to be one of the major challenges of setting up the initial game.

Unfamiliar scripting language:

While the language I will be using is somewhat known to me, the version I will be using is a much older variant than I started with, and much of the coding structure has since changed quite drastically. The manual is also a plain text file, which makes finding things a little trickier. I also have no idea exactly what can be done in this version of the engine, and I'm expecting that a lot of the things I take for granted may be more limited or not accessible at all in this version.

Limitations of the systems:

Building a project on an older machine presents a few limitations that haven't been a problem for some time. Working in DOS means I can't quickly change between windows to check things, meaning I have to make notes by hand. Working with 3.5" floppy disks as a transfer medium means backing up multiple versions is less convenient, and that game file size is a real consideration.

My plan to counter these issues is to work step by step, to work carefully through one issue at a time, to take notes and do research and to ask for help with any issues that I can't figure out easily myself. Half the challenge of this project will be learning how to make the game, the other half will be making the game itself. I'll be documenting as many of these challenges as I can, and perhaps if anybody else decides to undertake a similar project at some point then this can be helpful to them.

The Plan

Last week I saw an old Pentium 120 for sale, and I found myself contacting the seller and arranging to buy it from them. It's a great machine, with a super fast 12x CD-ROM drive, 32mb of RAM and an enormous 1.9Gb hard drive. It currently has a single 3.5" floppy drive, and I have plans to add a 5.25" floppy drive, and it runs Microsoft DOS 6 and Windows 3.1. It's exactly the sort of machine I'd been looking for.

It may seem odd to be purchasing a personal computer so outdated and be excited about it, but let me explain. The past couple of years I've been running a tumblr that showcases all sorts of DOS games - both the old favourites I grew up playing, and ones I'd never even heard of before. I've collected quite an assortment of old games from eBay, and I felt it would be fun to have an original machine, that runs these games just how they were supposed to. Although DOSBox  is a fantastic piece of software that makes playing DOS based games incredibly simple, nothing quite beats the feel of an old joystick, the chunk of an old keyboard and the hum of an old floppy drive.

But that's not the only reason. For the past 7 years, I devoted a huge chunk of my free time to making games. I started knowing absolutely nothing, and worked my way up until I was lucky enough to be hired to do it as my full time job around a year ago. It's been amazing, and I genuinely believe I have the best job. But now that making those sorts of games is my job, I wanted something different, something to challenge me. Something that will push me to learn more skills, more history and give me something to be proud of.

My plan, then, is to build a game that can run on this old PC. I'll even be using the PC itself to work on the game, if all goes well. I'm going to step away from the comfort zone I've settled into and try something new. To put my goal as a single statement:

I aim to create a short, graphical point and click adventure game designed to run entirely on PCs running MS-DOS 5 or greater, and to write about each step and detail some of the challenges I face along the way.

It's going to be an interesting ride, and I have no idea how I'll actually go with this, but hopefully somebody out there will find the process interesting, and maybe at the end I'll even have something playable to show!