Games > TODOR

Creatures (C64) clone
made by andraaspar
uploaded by andraaspar
download cartridge


I always wanted to make a Creatures clone. This took a while... It was fun to create this together with the kids. They created levels, sprites and music. Since I made this for the kids, there is no blood. What's more, you don't have to kill anyone to finish this game. You can pass by ALL monsters, and you can collect ALL the gems without killing anyone. Of course, that takes dexterity. But I've done it all over and over again to make sure it's possible. That's why you've got a separate high score table for finishing the game peacefully. Real pros do it that way.

The source is here:
Please file bug reports here:






Thanks! A thing I am proud of: the starting screen is stored in the code, not in the graphics. I drew it in GIMP and then converted it to 6 bitmaps, one for each color. A Lua number can store 51 bits, that is 51 pixels. Every 51 pixel is converted to a number. To shorten the numbers, I store them as base 36, separated by commas. Those are the blobs you can see in the cover variable. The cover image takes up about 7 kb of code space. The code to produce the blobs is in the source repo I mentioned above, in the img folder.


The other thing I felt real proud about is the palette roll effect (not sure if that's the real name) I used for the gems and some of the text. It is such an old-school C64 trick I haven't seen in decades. And the kids loved it!


Loved Creatures when I was growing up. The swimming physics feels great, and I enjoy how the game goes monochrome. The gem shimmer is really neat, and I didn't even notice the technical challenge in it until you mentioned hahah. Signs of a good design working around technical limitations.


Creatures was an amazing game at the time. It was so much better than anything else made for the C64. And the music! I still put it on sometimes. My attempt at making a good chiptune (above) is simply not worthy. I am no Steve Rowlands. :) (And that chainsaw!)


As for the physics: it's all straightforward vector based stuff. X speed, Y speed, etc. The walking part is done by testing 3 possible positions: 1 pixel down, straight ahead, 1 pixel up. Whichever doesn't collide with the terrain is the solution. Collisions are simple rectangle hit tests, with a few triangles thrown in for the slopes. Swimming is when you're at least 60% immersed in water. That cancels out gravity and starts to slow you in both X and Y directions. The bigger the jump, the deeper you go. Dropping walking monsters into water (possible by shooting the ground below them) kills them instantly for the sake of simplicity. :) I was lazy there.


I don't know the technical, but this game is very interesting.


Thank you, kikeroga! We put our hearts into it.


TIC-80 uses Lua 5.3, which can handle 64-bit precision integers.


@StinkerB06: Thanks for pointing that out! I was assuming double precision floating point numbers, and even in that case I was probably not 100% efficient, so the technique could be further improved. Shave off a few more kbs and we can add an extra monster... ;P


More interesting facts:
1. Moonscript instead of Lua. Because of size. Also, because it has a nice short class syntax. And array handling. But you can copy any of my functions and drop it into the online Moonscript compiler and get Lua. I had to do just that quite regularly to get proper compiler warnings. Bit of a pain, really.
2. Some of this was developed on my Android phone. Vim in Termux. The rest was done in VS Code on Windows. Nowadays TIC-80 is broken on Android 9. :(
3. A TIC-80 version change messed up my grayscale code at one point. Luckily I was able to work around it.
4. I wish there was a simpler way to refer to the buttons. That Z/Y/A is really horrible, but it's the best I could come up with. I have a QWERTZ keyboard at home.


3. What version was that? My best guess is, since TIC-80 0.27.0, the palette order in the RAM was changed from BGR to RGB.
4. The official button names are A/B/X/Y, which would map to Z/Y/A/S on a QWERTZ keyboard.


@Stinker2006: 3. The version was 0.69 upgraded to 0.70. The color palette used to be reset between TIC and OVR and then it suddenly didn't reset anymore and the two were tied together. I found that I could still switch to grayscale in SCN without affecting OVR. It feels like a hack though.
4. I know it makes sense when you've got a controller in your hand, but when you have a keyboard and A is not A... That is irritating. The letter Z is super irritating as well. There is no way to detect a QWERTZ keyboard so users may hit the wrong key and decide the game is broken. I wish we had an API to show the correct keys the user has to use. Because of remapping it is basically impossible to do correctly. A minor improvement would be to mark controller keys with symbols rather than letters. But still, keyboards are more common and not handled well.


Maybe... If controller keys were mapped to Enter/Space/Ctrl/Alt by default, that would clarify it a lot. Breaking change though.


Actually, for QWERTZ, it would be Y/X/A/S. With the standard QWERTY, it's Z/X/A/S.


@StinkerB06: No, with QWERTZ it's Z/X/A/S initially and the Z is in a weird place and you have to remap it. At least, that's what I had. We should really have Enter / Space / Alt / Ctrl. Then there is no mistake.

Post comment