Believe it or not, but I actually finished and released a game once. To be more precise, it was in September 1995 according to a file with a seemingly intact modified date, so I guess I'm writing this with the 20th anniversary coming up!
The game was a simple turn based strategy game where squads of armoured soldiers fought off an Alien Invasion of terrible blobs. The rather generic title Alien Invasion was to be changed to Blob Attack for the sequel which was already in progress... a progress spanning two decades. I've worked on it every now and then but always get distracted. The original game, written in Amiga AMOS, was unusually "full feature" with a title screen, an intro featuring generated sounds, and even a level editor.
I released it on a floppy disk using the informal floppy-swapping publishing method so I don't think it made it very far across the desolate countryside. My Amiga hard drive died but one backup floppy of Alien Invasion survived, partly corrupted. I managed to pull an old version of the source code off it as well as 20 levels.
The game was very simple as far as TBS games goes. The player controls a number of soldiers with 5 action points which can be used to move forward, turn left or right, or shoot. The computer controls a number of blobs which are spewn forth by teleporter worms attached to the walls. I think I got the idea for the teleporters from an old Swedish Sci-fi comic called Achilles Wiggen (the Asmoroog story in particular).
My blobs behave in a simple manner: If they see a player at a distance they will charge 2 steps, then all blobs will make 3 attempts to move 1 step in a random direction. Finally, all teleporters have half a chance of spawning a blob. No one can move or shoot diagonally so there are certain safe spots to consider. The blobs attacked the player's soldiers by simply moving over them (consuming them like in the movie blob).
While the game mechanics were quite simple, the game still managed to have some strategical depth with cover fire and risk taking. It was a sort of mix between rigid logic and random events, similar to MineSweeper.
An actual screenshot of the game (not final version) running on my A1200 connected to a cheap LCD TV. I really should make a RGB video -> Scart cable.
As you can see the playfield was quite small at 25*20 tiles (10px each). The game used only 4 colors: red brick walls, white soldiers, green blobs and teleporters, and black for background.
The surviving source. Got a chuckle out of my old AMOS programming antics. Here I'm cleverly using a single integer (4 bytes) to store TWO values with a range of 0-9! It took a lot of fancy string footwork let me tell you! Software patent pending...
The intro, perhaps lost, was animated, so I'll animate it with some text:
What is that strange humming sound? Aah! An alien saucer floats across the night sky... hold on, it has parked itself right over the city... a sudden beam of pure $FFF has shot out, widening, widening! That is the fanciest filled polygon I have ever seen! Something is descending inside the light beam now. A monstrous teleporter! What evils will it spew forth? Assemble the troops!
A graphical mockup that I started working on in 2007 and noodled on every now and then. It uses my 16 color palette (v20). Over-provisioned so I can fit in some new map variation tiles and units. Will have to write a tile grabber in AMOS. Static noise frame is to disrupt switching of portraits so they look more different on change.
This is the RGB values of the palette / 16. Transferring via an IFF might do something similar as IFFs seem to store 0-255 rather than 0-15 in the color map. Because I have (random) trouble with loading Photoshop saved IFFs in DP I might transfer the images in a custom raw format (e.g. 4 bit chunky nibbles) and replot using AMOS and save as IFF from direct mode.
I'm stricken by an irresistible Amiga mood every now and then. Since it's that kind of now now I want to do an Amiga version (I normally use BlirzMax). The game is mostly retain mode so I should be fine with using AMOS Pro and Bobs. Hopefully it will run on an OCS machine, though I will be developing on an A1200 with a 1220/4 Blizzard card. Might Double Buffer.
One problem with the original game was that it was sometimes hard to see what moved where. This can perhaps be solved with half steps. I'm going to use a tile size of 12 this time so a moving unit will briefly be seen with a 6px (halftile) offset. There will also be visual alerts to important locations, such as a flashing ! mark.
I'll probably use Put/Paste Bob or Block/Icon for the map tiles, but I'm not quite sure if the units, muzzle flashes, explosions etc will have transparent black or not. If they do I'll have to redraw the map cell to clear then whatever goes on top. The map cells which are floor tiles can be updated with debris which fades at the end of turn but doesn't quite disappear. I'm a firm supporter of permanent corpses / residuals as it gives the player a sense of history and achievement. Sprites will definitely be used for the mouse and flashing selection cursor, as well as for other unique temporary overlay objects.
Blobs should be movable with either keyboard or mouse. Perhaps there should be a help screen showing hotkeys layered over the GUI, similar to MoO1.
I like how units are retained in X-COM, and I've already pixeled medals and items, so I think it would be fun if the game had a "five little piggies" theme... similar to Cannon Fodder or Lemmings 2 : Tribes I guess. Each new level the player is given a random mission and a random selection out of the limited pool of troops. The goal is to complete all of the levels. Because the troops have different weapons and items and are selected at random, the levels will play a little differently each time. I'm thinking the should be about 10-20 troops and 20 levels, with 1-5 troops spawn points on each level.
The player controls one or several troops of various types. Troops use action points for moving, turning and shooting. Some weapons use several action points because they are heavy.
All units will probably store AP, Angle and Type in the map array, but the player's troops have a little more peripheral data. Unsure how map array will refer to these. There are several solutions.
Movement is kept simple. The troops can only move forward or turn L/R. Note that the soldiers can't strafe, or back up. This was a part of the difficulty of the original game.
Other actions (using AP) includes using items, picking up and dropping items. Shooting uses up move points as well, but some troops can only shoot once or twice per turn.
I'm thinking of keeping all 20 maps in RAM so they can be loaded quickly. A 20x20 map is only 800 bytes, x2 for Map and unit layer. Unit data can be compressed into a single byte. I can quickly copy this data into the playfield map which should be 22x22 to provide anti-leak/bounds sentinels. I could probably use several playfield byte data layers such as Tile, Unit type, AP, Angle, special effects. Maybe 20K for all map stuff.
The background map has several types of tiles, type can be identified by a switch, probably.
Given randomly on crate loot.
The teleporters have a chance of spawning in new blobs at the end of the blob's turn. IIRC, the chance of this happening was 50%, or lower because a teleporter will often be obscured.
Freshly spawned blobs will not move, because it's the end of the turn. Green blobs normally check line of sight to troops, charge if they can see anything. They do this twice, so it's possible for them to change target. Programming-wise, it's more practical for troops to attract blobs up, down, left and right though. The blobs finish their movement by trying to make a random move (UDLR) three times. Most of the time they will probably bump into something. I'm thinking it's best to make three complete passes to scramble the for-loop read order a little.
Since the blobs make the random move last, and the charge move first, the player is able to tell whether he's safe in terms of line of sight at the end of his turn. A blob can't jump out behind a corner, and then charge into the player. A blob can charge the player, then it may come down to the last random move whether the player dies or not. This means that the player can predict the game, but gamble with distances to save turns (e.g. being 2 moves away from a blob at the end of a turn and hope for the best during random move). I'm not sure if I ever tried reversing move order.
It might also be fun to have smarter blobs which move more surprisingly, such as pathfinding blobs, or blobs laying out pheromone tracks for their friends to see. E.g. At this position, I saw a troop 5 steps down. Then friends will LoS check for troops, then pheromone spots. They might see a troop 12 steps away, and a pheromone spot 6 steps away, suggesting a troop 3 steps away (9). They can either go for visible troops first, or go for the shortest distance. Pheromone maps would accumulate distance over time, eventually killing off pheromone spots. this would make old spots less interesting.
When playing on a map, the troops are picked using the mouse or numerical keys. Movement is done via the arrows buttons in GUI, or on keyboard using the arrow keys, or WASD (maybe not S, no backing). Using gear, Shooting, and other actions could be done using buttons or adjacent keys, such as rCtrl, Num0, QE/AD or Space.
Not sure if there should be some sort of intermission display here, showing living troops, progression, etc.
Offsets could be pointed at using constants... (though AMOS does not have them) using relative values in case I need to add or remove frames, or rearrange the sprite sheet completely. All angles are clockwise, starting with up. Some tiles vary in appearance randomly, like debris and blood splats.
Instead of switches I can use GOTO X where X is a line number:
ANTIOCH = 3 GOTO ANTIOCH RABBIT: GOSUB AAAAAAAH: 1 Print "One!" : GOTO RABBIT 2 Print "Two!" : GOTO RABBIT 3 Print "Five!" : GOTO RABBIT
More random thoughts, now in a list!