Take 526… and action

You know those insufferably cringey ‘behind the scenes’ features they sometimes do for films and TV shows, where star actors pretend to be best friends with the tea lady whilst engaging in some of the most hilariously embarrassing and forced (ugh) ‘banter’ ever known to the human race?  Well, this article is rather like that.  Only without the banter.  And the actors.  And the tea lady.  But apart from that, it’s exactly the same.  Oh yes.

Which is to say, in this thrilling instalment of the Maxwell Mouse development saga, I’ve decided due to overwhelming public demand (that is, one or two people casually asked) to cover the tools I use to create my games, and how they all fit together in perfect, game-creating harmony, where everyone holds hands and skips through forests and all the animals are friendly and the sun is always shining and… er, yes.  Sorry about that, I got a bit carried away there.  Anyway, it’s not just sitting at a keyboard for hours tapping out code (although that could be considered reasonably important).  We need to find ways to build level maps, store graphics in a way that they can be used in a game, and so on.  Many ‘proper’ coders would create their own tools for these purposes, but if you’re lazy and incompetent like me, you’ll want to save yourself some time by using one some other poor sap has spent time and effort putting together.  Like these, in fact…

Shapes Manager

ShapesMan

In Blitz Basic land (the language being used to program Maxwell), the majority of graphics (such as map blocks, objects, characters and so on) are stored in a format it likes to call Shapes.  There are numerous ways to convert your lovely artwork into something Blitz understands (it even has the commands to do this within your own programs), but I use a twenty-year-old tool called Shapes Manager.  This handily cuts out anything with a box around it, and then allows you to resize them, change the order they’re stored in, animate them and so on.  It does seem to come with one or two quirks, however.  Namely that it tends to crash when it feels like it, and should you have over 300 shapes in one file (say, the blocks that are used to build the level maps) it will similarly decide to go on strike.  It still does enough for me, and I can’t be bothered to find anything better – I’m so used to it by now I can just ruffle its hair, give it a playful slap and send it on its way.

RED Map Editor

REDMapEditor

Having the ability to design your own maps is an essential part of game development.  It’s not at all practical to merely draw and save each screen as a normal picture file – disk space and memory will be eaten up within seconds – so what we tend to do is split the graphics up into small tiles (traditionally 16×16 pixels in size, as is the case with Maxwell) so we can reuse them over and over again if we wish.  When we’ve saved them out into their very own Shapes file, we can load them into an application such as RED Map Editor and then use it in a very similar way as we would a paint program – that is to say, selecting the block you want to use and simply pasting it onto the screen.  When we’ve finished, the map is saved out as data and luckily the code to read the files into your own code is automatically generated, so the world is your lobster.

At this point, the more attentive might be thinking “Okay, so you’ve got your map layout, that’s all well and good, but how do you position your objects and non-player characters?”.  (More likely you’re wondering “What’s for tea tonight, then?”.)  If there’s one thing I should be throwing together, it’s a primitive editor allowing me to place where I want them all to go with a couple of mouse clicks and then save that data out separately.  Except, naturally, I don’t.  Up to this point, I’ve hard-coded all the relevant data, which isn’t that time consuming when you can multiply by 16 (and have the map painstakingly drawn on graph paper).  It’s quite possibly not the smartest way of working, though.

Blitz Basic 2.1

BlitzBasic.jpg

This is where the magic happens.  You’ve got all your graphics files organised.  You’ve painstakingly designed your level.  Now for the small matter of bringing everything together into a game you can actually play.  Blitz is ideal for games like this one – it’s fast, versatile, relatively easy to learn (although it will take an awful lot of time and dedication to even think about producing a huge game like this one, especially if you don’t possess any coding experience whatsoever) and allows you the freedom to do some impressive things with the hardware.  That’s not to say it’s perfect – the editor isn’t to everyone’s taste, the documentation is appalling and contains no end of typos and factual inaccuracies, and there are one or two bugs lurking, but it still does more than any other equivalent BASIC on the Amiga, for my money.  Not that I’m literally putting any money on it, of course.  I’m far too tight for that.

RED Debugger

Debugger.jpg

When it comes to releasing a computer program, the discovery of bugs are about as welcome as Rolf Harris at a child’s birthday party.  However, like Rolf, it shouldn’t take too much to banish them from view forever.  Not that I’ve grasped most of what goes on here, of course.  It looks clever, and that’s clearly the most important thing here.  The debugger helpfully points out if your code will cause something to fall over entirely (unless, for example, you spend an hour cobbling together a title sequence and in your eternal wisdom, run the code without saving it first only to find you’ve unwittingly divided by zero and brought down the entire system), but there’s no substitute for thorough playtesting – preferably by somebody else – to break what you’ve written in a humiliating manner.

(Incidentally, the Debugger and Map Editor are part of the Blitz Support Suite expansion, as well as an improved editor and additional commands.  I have all this installed and I’m more than willing to share my development environment if anybody wishes to have it.  Just let me know and it’ll be winging its way to you, if not now, than hopefully as soon as I remember.  Or can be bothered.)

Well, there we are.  That was an undoubtedly thoroughly tedious glimpse at what really happens when I settle down to mess about on – er, sorry, I mean do some serious game developing.  Hopefully it has provided some vague interest without getting too heavy for the non-techy types out there and hey – it’s hidden the fact I’ve done almost no work on Maxwell for the past week, so it’s bought me time to think of something more engaging.  That’s torn it.

Advertisements

2 thoughts on “Take 526… and action

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s