Mega lo Mania 2 Part 3

Yes, yes, we know you've all been absolutely desperate to find out what's been happening to Mega lo Mania II in the last two months (what with the new Top 100 and all we didn't have room for Diary Of A Game last time), but wait no longer — this month, programmer David 'Ubik' Korn gets completely bored with writing graphics and landscaping routines and — yikes! — gets down to the fine and delicate art of actually programming the game itself...

The Sensibles: still a jolly bunch of chaps.

What's that? You say you don't know what the heck we're on about? Well, it couldn't be simpler, really. Every month this year we're handing a couple of pages over to a top programming dude from top gang of programming dudes Sensible Software (David 'unusual nickname' Korn, to be precise), and letting him take you, the reader, gently by the hand through the incredible amount of drinki— er, really hard work involved in programming a top Amiga game from start to finish.

The game in question is Mega lo Mania II, sequel to last year's fabulous 90 percent-rated fun strategy wargame (for want of a better description), and in previous months David's taken us through the construction of the game's landscape creation system and some of the more basic graphical details. Now, though, we begin to get down to the real nitty gritty. And with that, it's over to you, Dave...

And now, after a short delay, AMIGA POWER, in association with Sensible Software, brings you the latest hot-off-the-grapevine news on the game they're all calling 'not finished'.

Mega lo Mania II — What happened in February

The front-end menu, as in the first Mega lo Mania, choosing an island to play.

Choosing the number of men and placing your starting sector.

And here we are in the game, with a nice new bit of landscape.

The equally unprepared mining menu. There's room for up to four elements, with their icons going down the left-hand side.

The raw army menu.

Another slew bit of landscape, in a new sector, and the factory.

Monday 3rd — Friday 7th February

Well, I couldn't put it off any longer. Having toyed with triangles and grabbed at sprites to my heart's content, it's finally time to start putting the actual game into the game, and about time too.

As the new version is very similar in concept to the original Mega lo Mania, and as people have generally said nice things about the menus'n'icons control system we had there, I'm keeping to pretty much the same format. A sensible way to begin (and this is Sensible Software after all) is by implementing large chunks of the original game in my system, so I begin the week by reading through Chris Chapman's assembly code for the original — and rarely have I seen such a tangled web of mystery, intrigue and hexadecimal!

Reading through someone else's code (and actually managing to understand it) is a fairly difficult business; they structure it in different ways to your own, and it can be difficult to tell which parts of their program have responsibility for what jobs, and which areas of their data contain what information. Fortunately for me, Chris is just across the room, and I can therefore continually interrupt his work to ask him what's going on in his code. Slowly but surely it begins to make sense.

Next, I copy a few selected bits of his code into my program. First off is the data that represents the different levels and sectors in the game — that's most important, because it gives my code something to play with so that I can tell if it's working. I'll design my own levels for the actual game, of course, but I don't really want to spend lots of time doing that until it's a bit clearer how it'll all turn out.

Monday 10th — Friday 14th

How do you begin a game? At the beginning, of course! And at the beginning of Mega lo Mania is the front end menu, where you choose the game options and select which island to play from the epoch. In order to do this, I basically have to get the entire menu system working, and that's no small undertaking.

So how do you write the code for something complex like a menu system? Elementary, my dear teapot — you just use a data structure. What d'you say? 'A what?' Alright then, I'll explain.

Think amount the menus in Mega lo Mania. The main elements they're made up of are icons (and I'm including graphics such as the little arrows in that), numbers and text strings. Some of them do things when you click them on, others are just there for decoration and to make the display clearer. Some of them are only there some of the time too — for example, the lightbulb disappears when there's nothing left to invent.

And there's more. When you click on them, some of them lead to other menus altogether; others change from one image to another (such as the sound effects on/off option); the numbers go up and down when you click on them according to which button you use, although some (such as the amounts of elements) can't be edited in that way. And so on.

Given the potentially vast number of combinations, it would require a horrendously complicated piece of code to draw them all, update them when they changed, and decide what to do each time the mouse button gets pressed. And when you think that a separate routine like this would be needed for each of the many different menus, the complexity and potential for bugs becomes... well, it's the sort of thing that makes programmers wake up screaming in the night.

But wait! What's that, up there in the assembler? Is it a bug? Is it a bit-plane? No, it's data-structure to the rescue!

A data structure is a small set of data values that stores all the information about something important in your program. If you write your code so that it correctly reads the data in a data structure, changes and updates it correctly, and displays it suitably on the screen, then you can be sure that your code will also work correctly with any number of them.

So how can this wonderful concept be applied to my menus? Well. I use one data structure for each single item — icon, number, text or whatever — that appears on a menu. The data structure contains all the information about that item: its X,Y position on the screen, the width and height of the area around it in which you must click to select it; whether it's a number, text or graphic icon; whether it should currently be displayed or not; what to do when it is selected (choose a new menu, or call a subroutine); and so on. Each menu is then simply made up of a list of these data structures, one for each item. Then it only takes ones mega-menu routine to draw them all (or only the ones that have changed since last time), find out if the mouse has been clicked on one of them, and decide what to do about it.

And that's how I spend the week, although I'm sure I'll be finding bugs in it for a while to come. The point is that now I'll only have to fix them once, in my mega-menu routine, rather than all over the place, as would be the case if I'd written a separate routine for each menu.

My joy at having written this terrific piece of program is somewhat dissipated on Thursday when I come across a copy of Commodore Power (no relation to this magazine) and find that their covertape has one of my old C64 games on it — Arcade Classics to be precise.

As this is the first I know about it — and they've even had the cheek to claim they own the copyright, and not even mention that I wrote it! — I'm not in a very good mood when I phone them up. They try to fob me off by blaming their duplicator for saying they could have it, but that doesn't excuse them claiming it as their own. As far as I'm concerned they're as bad as the worst kind of pirates — taking someone else's game, mass-duplicating it and selling it.

Unfortunately. there's no way I can afford a lawyer to sue them with, and they know that, so to date I've received no apology or payment from them. If you're reading this, lads, I hope you all die soon. Painfully. (Commodore Power is no more, you'll be pleased to know — Ed.)

Monday 17th — Friday 21st

I'm feeling a bit hungover on Monday, having been drowning my sorrows all weekend in the pub. Still life, and Mega lo Mania, must go on. Thanks to my Super-Mega menu routine, it takes no time at all to get the front end menus working, and I launch myself into the game proper. Since all the weapons need to be invented first, and, of course, all inventions in the game need elements to be built from, I start off with mining options from the main menu. It's not too difficult, and by the end of the week I'm happily clicking on elements, setting men to mining them, and watching the stockpiles mount up. At last, the game is begun. What a feeling of satisfaction!

Monday 24th — Friday 29th

A whole week without Mega lo Mania, amazingly enough! John has asked me to write a little demo for AMIGA POWER's issue 13's coverdisk — "It'll only take a couple of days," he says, and so of course I agree to do it. Surprisingly enough, by the end of the week... it's still not finished. Still, never mind — a change is as good as a rest. Seeya' next month, dudes.

Okay, so we've got the game started, but what happens now? Let's hope Ubik remembers that far back in time for next month, eh?

Guess who? Yes, it's that David 'Ubik' Korn again, Mega lo Mania II programmer, unrepentant old hippy, owner of just one set of clothes and now... part-time journalist!

Mega lo Mania 2 — not!

Amiga Power issue 16 contained a small news item on page 10 with bad news about the Mega lo Mania II diary:

Don't expect any more instalments of Sensible Software's Diary of a Game, not for six months at least. Programmer David Korn has been moved onto a mysterious new project, thus leaving Mega lo Mania 2 frozen until the more urgent project has been completed. We'll bring back the diary as soon as Dave gets back down to it. Meanwhile, watch this space for news on his new ultra-top secret project. 

It turns out that David 'Ubik' Korn was transferred to work on Sensible Soccer, and the game was abandoned forever.

Scans

Series Links

Part 1 / Part 2 / Part 3