I posted the other day about these cute little soldier units that get produced by the Barracks building. It was one of those neat little ideas that pops into my head. Usually when I’m on the bog.

The trouble with neat ideas is sometimes they don’t quite fit in The Grand Scheme Of Things. What is the point of the little soldiers? They fire little lasers which are quite good at vanquishing the weedier gidrahs, especially when there’s a whole load of them, but they’re otherwise not so good at anything with any armour. You’d be better off just buying a heavy blaster. So what’s the point of the little guys?

“Oh no!” you cry. “Don’t take the wee soldiers out, they’re so cute!”

Fear not! I figured out what I’m going to do with them. And it followed another little extra new idea I’ve had on the bog, and subsequently implemented. Angry Gidrahs!

Angry Gidrahs

Each alien spawn point emits waves of aliens, with a little gap in between each wave, until the level ends. What I’ve added is the probability that the last alien emitted in a wave is one of these so-called angry gidrahs. An angry gidrah looks like its normal counterpart, except it’s a little bit bigger, and has some sort of special attribute that makes it a lot nastier (and worth 5x as much to shoot). And with a bit of Chazification, it will also be red and smoke slightly. The frequency that angry gidrahs appear depends on how good you are. They’re a bit like mini-bosses.

So some of the things that distinguish angry gidrahs from their smaller, more serene brethren are: 5x as many hitpoints; moves twice as fast; has a weapon; has a special tactical brain; and … spawns gidlets! (Amongst other ideas) Gidlets are teeny tiny little aliens which are the counterpart to the little soldier guys. A gidlet is too small to be targeted by turrets! And they run right through barriers and minefields unimpeded. So you need little soldiers to go running after them before they reach a building and start bashing it. So soldiers by preference now chase after gidlets before they’ll start attacking the bigger gidrahs.

Because gidlets are produced in relatively large numbers and they’re so small, they only do half a point of damage to a building when they hit it as opposed to the full point caused by a gidrah. Angry gidrahs are also good and tough and can bash a building up to four times before they finally croak.

Flying Gidrahs

Also this week sees the introduction of flying gidrahs, which predictably completely ignore minefields and barriers and even rocks and just fly straight past. If they were allowed to just fly straight at the base and collide the game would probably be over in short order which wouldn’t be very fair, so these gidrahs work in a slightly different way to ordinary gidrahs. They will instead fly in a straight line straight from their spawn point directly over their target and then off towards the opposite point on the map, thence to respawn a bit later. En route they will be firing guns or dropping bombs on anything they fly over.

Unlike in other tower defence games we won’t be making you put down a special kind of turret to waste them. Your ordinary guns will do just fine.  Even soldiers will take a pot shot.

Wraiths

More sinister than flying gidrahs are wraiths. Wraiths are actually going to be a kind of angry gidrah, so they won’t be too common. Which is just as well! Because they can move unimpeded through barricades and minefields and, yes, walls too. It gets worse! They can only be harmed by capacitor fire, not ordinary turrets.

Gidrahs with Guns

It had to happen sooner or later. Some of those gidrahs are armed! They’ll occasionally take a pop at anything they walk past that’s in range, significantly increasing their threat level. The only useful countermeasure is to shoot them first by having a blaster with a really long scanning range. They shoot right over barricades so that won’t be any help. Or you can bung a bunch of shield generators down and hope the gidrahs walk into blaster range before the shields all get used up.

That’s it for development news for today. Over and out.

Look! Teeny tiny little men! These guys are produced by the barracks building. They’ve got weedy guns, short range, and don’t exactly move very fast, but when you’ve got thirty of them standing in a line blocking the advancing gidrahs with hail of small arms fire they’re quite formidable!

Of course, the armoured gidrahs just trample on them and squish them. But you need heavy blasters for that anyway. I think I might have several different unit types available, generated at different speeds. These little basic guys are the grunts. I think a tank would be a useful addition to the player’s arsenal but I’m so enjoying the tininess of them maybe I’ll just give every 5th unit spawned a rocket launcher or something.

The number of little guys you can have depends on the number of bases you’ve got, which brings me to a small change I’ve made to the game so that the level begins with no bases – instead you place one where you want to place it (I imagine on the opposite side of the map from the gidrah entry points) and at that point the level begins. A base costs $500, and you’ll get the money back at the end of the level if it survives. While it stands each base awards you a good old fashioned score multiplier. Keep 5 bases on the go and you’ll enjoy a 5x score multiplier for massive points. Yay!

While I’m on about progress, I’ve put in another three buildings besides the barracks: the collector; the warehouse; and the autoloader.

The collector is a handy way of consolidating mouse clickery. Place a collector amongst a bunch of factories, and instead of having to click on all the factories individually to collect money from them, you can simply click the collector once, freeing up more of your time to panic elsewhere.

Place warehouses near factories to increase their capacity before they get full and stop producing.

The autoloader you plonk next to a bunch of turrets. As soon as any turret in range of an autoloader runs out of ammo, it will automatically reload! How handy. It is of course rather expensive.

Only 30 more droids to draw, and 30 levels to design. So realistically I’d say it’ll all be wrapped up in a week. Well, maybe two. A month, tops. 2008 for sure.

and a few more images… Continue reading →

27 June 2007

I have decided to keep a diary of the Treasure Tomb development for posterity, like the Alien Flux one before it somewhere on the javagaming.org forums. It might be an amusing read for you, or enlightening. Mostly though, it’s my public trail of shame. Can’t quit on this game if you have to see a daily progress, eh?

So: where are we with development for starters?

With the guts of Monster Mash ripped out and a quick package name refactor, I’ve got a basic game framework set up in Eclipse that launches and has a title screen, register screen, nag screen, hiscores screen, options screen, help screen, and credits screen. Of course all of the graphics and layouts are from Monster Mash (I just scribble over the top of the title with “TREASURE TOMB” using the Gimp) and it’s for Chaz to sort out later. But there we have it – the cradle in which a game sits.

Currently tapping M on the title screen brings us to the Map Editor. I’ve decided to do the editor completely before I do any game development, as it’s by far and away the most work involved in this project.

The map in this game is rather big. 1024×1024 tiles, to be precise, which is a lot to fit in memory at any one time when you also consider that each tile may also have an item on it (like a munchable dot, or a jewel, or monster spawner). Not only that but some of the map squares have special actions associated with them: teleports have a destination; script tiles fire off a “script”; and switches fire off a sequence of changes to the map. Furthermore, in the editor, we want to be able to turn switches on and off and see which tiles have been affected on the screen with some sort of indicator.

Were I to implement that naively and have each coordinate on the map represented by, say, some TileInfo class which contained the floor tile, item tile, any special action, and a flag, I’d need to create an array of 1,048,576 of them, and each one would take up 8 bytes overhead and 16 bytes of object data. That’s 24 megs! Not to mention the 4mb just for the array pointing at them. I don’t really fancy using half of my entire heap just to store the ingame map – not to mention the fact it’d make serialization slow and probably very bulky – so I’ve already decided to optimise this data structure.

The map now consists of two short[] arrays which point at indexed Tile instances; that’s the floor and item layers. Now it only takes 4 megs for the entire tile storage. There’s another 4 megs that points at optional ExtendedInfo instances – so mostly null. An ExtendedInfo, when present, is where I can bung everything else when necessary, like tile actions, flags, etc. So that’s more or less got map storage down to just over 8 megs, much better. And serialization will be lightning fast.

The editor is proving extremely difficult to write because I’m doing it properly – one of the most important things I’ve implemented is a multiple undo feature. This is quite tricky to implement especially when drawing one tile can affect its four neighbours (the wall tiles automatically adjust to get the edges right). But it works! Hurrah.

Also implemented is setting Teleports and destinations – just to test that part was working ok.

Tomorrow comes the much more extremely difficult design and implementation of the switch editor. Why so difficult, you ask? Well, firstly, because I want to be able to undo switch edits. And secondly because I want to be able to flip switches in the editor – both on and off. In the game, they cannot be flipped off. However, they can be flipped in any order, and the bit which recalculates walls has to be able to cope. And Undo. Gah. It’s making my brain hurt just thinking about it.

Continue reading →

Every now and again, you can be writing a game and be really enthused about it… and then suddenly your mind just goes a blank. All feelings about the game just strangely dissolve, and no matter how much you try to motivate yourself to continue writing it, you just can’t be arsed.

Unfortunately, Monster Mash has succumbed to this phenomenon. There it languishes, a year after we started it, still going nowhere. But fear not! This happened during Titan Attacks too, and what we did to get around that was write Ultratron instead. And then we went back to Titan Attacks and made it the best space invaders game ever (in our humble opinion of course).

So what has taken the place of Monster Mash? Well, the game we are now working on – and getting quite into with much enthusiasm and aplomb – is code named Treasure Tomb, and it might end up staying with that name too because I like it. It’s beginning to look a bit like this:

That’s the grassy bit. Eat flowers. Yum.

This one looks like the original Pac-Man.

This looks rather like the underground passages one might find in a volcano. Or Hell. I like Hell.

And here’s a dark and futuristic hi-tech “base” of some sort.

What’s the game all about then? Well, it was originally scribbled down on a bit of paper as the “scrolly dot munching shooter”. Imagine Pac-Man with a gun, inside a massive 100×100 screen world that scrolls, with a few treasures and powerups scattered about, and a few puzzles based on flicking switches and opening locks with keys. And there you have it. The core gameplay comes from Time Bandit for the Atari ST and Amiga, and of course we’re puppyfying it somewhat with powerups, lots of dots to eat, and lots more puzzles to solve.

Right now I’m half way through writing the map editor, which may or may not make it in to the released game. Chaz is busy turning those mockup screenies you see there into real tilesets for use in the game.

Slow progress the last couple of weeks, due to mounting pressures at work. Ah well, such is the indie developer’s lot.

Tonight I finally had a few hours to do a bit of coding on the game again, and I’ve implemented robot turrets and minefields. Borrowed some graphics from Ultratron which look completely out of place, and also cobbled together some wizzy computer HUD style aiming computer type graphics for the robot turrets. They look more or less entirely awful. Chaz will hopefully spot them on Monday morning and sprinkle magic Chaz dust on them.

Robot turrets are nifty but expensive – drop a robot into a turret and you don’t have to worry about firing it any more. There’s a 1 second delay before they fire and their range is limited to the suspiciously computery number of 96 pixels.

Minefields you can just scatter about the place and the gidrahs wander into them. BAM! 10 points of damage, usually enough to finish them off instantly. Minefields work 3 times then stop. They also have a 1 second delay between explosions so the gidrahs can rush through if they’re determined.

We’ve been working on our new game the past week or so, and Chaz has been experimenting with all sorts of various graphics. Here’s a mockup:

The game currently actually plays, with the game starting, an initial base formation spawning in the middle, and then the gidrahs start to appear at the top of the screen and wander down looking suspiciously like they’ve escaped from Ultratron. Saucers appear here and there. And when you’ve blasted all the gidrahs to bits the shop screen appears, but you can’t buy anything yet.

Actually rather a lot of the game currently looks suspiciously like Ultratron because currently about 90% of the code is the same!