Well.

Well, it's been a long time since I touched this. I was running into so many issues, and I realized that the design for my game relied on stuff that I simply don't know how to do in the version of AGS I was using. Every single thing I tried to do was met with problems, and it killed all progress.

What I've decided to try, then, is to do something a bit different. Rather than take a game I'd designed in my head before using 2.3, I'm going to try and make something small and simple designed with the limitations of 2.3 in mind. It's going to be a lot less complex, and only use the most basic of elements. This, hopefully, should be enough to get me more familiar with the systems, too, to make working on something slightly bigger a more feasible enterprise.

The last few days have seen some actual activity on my part again. I've been fiddling around in the editor. I've drawn some graphics. I even wrote a small piece of music for it. The gears are turning, and something is happening. Here's a quick peek:

Hopefully this time I can get something playable done!

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.