Not everyone who wants to make games is a programmer so I thought I would take a look at how a classic game-making tool for the Commodore 64, the Shoot 'Em Up Construction Kit, worked.
Back in 1987, a very special tool was released for the Commodore 64 called the Shoot 'Em Up Construction Kit, or SEUCK for short.
It was made by a company called Sensible Software and published by Outlaw (which was part of Palace Software).
SEUCK was amazing because it let kids create your own shoot 'em up video games, even if you didn't know how to code even a little
- You could draw your own sprites and objects. You could even make them move and draw different pictures for each step of an animation
- Explosions and Bullets. Design how enemy bullets look and how things explode when they get hit.
- design background characters and then combine them into bigger blocks (5x5 characters big). You could make up to 128 different blocks.
- Arrange the blocks to create long, scrolling levels. There was even a version for side-scrolling (horizontal) games.
- Sound Effects
- Save Your Finished Game (most important part - you could distribute finished games on tape or disk)
SEUCK also came with four free demo games.
It was a fantastic tool for its time. Being able to create a whole game, with all its graphics, sounds, and levels, all fitting into the Commodore 64's limited memory, was a big deal.
The ability to save a finished game with its own fast loader was incredibly cool and helped many young programmers learn how tape loaders worked.
However, games made with SEUCK sometimes SUCKED:
- Many SEUCK games looked and sounded a bit alike.
- Games could slow down a lot when many things were happening on screen.
- When the screen started or stopped scrolling, the sprites would seem to jump up or down a tiny bit, making it look like it wasn't properly connected to the ground.
As it turned out, when SEUCK saved a "finished" game, it often left almost the entire game editor hidden inside the game's code! This used up a lot of memory.
This meant that if someone knew a little trick, they could open up your game, go back into the SEUCK editor, change things, and even re-release it as their own.
It involved typing a special command called a POKE (which changes a specific number in the computer's memory) and then a SYS command (which tells the computer to run a program starting at a certain memory spot).
Back in the day, people with special "freezer cartridges" (like the Action Replay) could pause a game, look at its memory, and discover these secrets.
The Treasure Trove: Where SEUCK Keeps Its Goodies
Martin Piper back-engineered SEUCK to fix those issues and enhance these games.
The question why I did it is very much linked to the technical details of how the original SEUCK worked. All those years ago the SEUCK guys didn't have access to all the modern ideas we now have about the C64. For example te multiplexor in the original SEUCK compared to modern multiplexors is not that good, the sorting is slow, the collision detection routine has a bug in it and it generally cannot cope well with many sprites. The SEUCK game code also doesn't use that much optimisation and this is partly because some of the memory has to be used for the editor code. In general, problems can be optimised by throwing memory at them for look-up tables or unrolling code. But with all these shortcomings I still like the original SEUCK, as do a few other active people on the modern C64 scene.
Here's where SEUCK's background and map data was found in the Commodore 64's memory:
- Characters (the 8x8 pixel designs):
- Start at C64 memory address: $F800. (This is a common place for character sets on the C64).
- Background & Multicolor Screen Colors:
- Start at C64 memory address: $4085. (These are three specific color registers).
- Blocks (the 5x5 groups of characters, 128 of them):
- Start at C64 memory address: $1A00.
- Map Data (how blocks are arranged to make the level, 8 blocks wide):
- Starts at C64 memory address: $0900.
- map data is stored "backwards" in memory. This means the bottom row of your scrolling map is found at the beginning of this memory area, and the top row is at the end. This actually makes sense for games that scroll upwards – the game can just read the data in order as it scrolls.
- Block Colors (the main color for each of the 128 blocks):
- Starts at C64 memory address: $1900.
This new code was organized into files:
scroller_data.asm: This file listed all the important C64 memory addresses discovered (like $F800 for characters, $0900 for the map, etc.). The new program would read the original SEUCK data from these locations.scroller_single.asm: This was the heart of the new engine. It contained:- Optimized Routines: Cleverly written code to draw the blocks and scroll the screen very quickly.
- New Memory Layout: The new code arranged data in memory differently from how SEUCK did it. This was for speed and efficiency. (It also means old SEUCK game cheats or POKEs wouldn't work on games using this new engine).
- Fast Drawing: Special loops for drawing, some "unrolled" (written out long-hand) to be faster.
- Double Buffering: A technique where the next screen is drawn secretly "off-screen" and then quickly swapped into view, making scrolling look very smooth.
The Result? A beautifully smooth, fast-scrolling display using the original SEUCK graphics data but powered by a brand-new, super-efficient engine