TRANSFORMING TOKI
Interview with artist &co-ordinator Davide Bottino:
1. Why did you decide to remake the C64 Toki graphics?
This needs a bit of backstory... The C64 was my gaming machine in the 1980s and until I switched to the Amiga in late 1992. I am very fond of it, I have wonderful memories, but also many bitter disappointments mainly due to the bad conversions of my favourite arcade games (I could make a similar argument for the Amiga as well): Strider, Final Fight, Football Champ, and precisely Toki come to mind. In the summer of 1990, my friends and I went crazy for Toki, we played it at our local bar, it was very challenging and fun and quirky, it was filled with humorous touches and weird stuff. When halfway through 1991 I saw the advertisement in the Italian ZZAP! magazine announcing its upcoming release for C64 on cartridge, I was ecstatic. I often found myself thinking what it would be like, whether a good conversion or yet another piece of crap. But then strangely the game never made it to the stores in my city, and it wasn't even reviewed in the Italian ZZAP!. It was never heard of again. It is likely that the flop of the C64GS and its costly cartridges (in Italy they were priced the equivalent of 70€!) prompted the then-Italian importer not to market the game at all at the last minute, but at that time, without the Internet and with ZZP! remaining silent about it, I was completely in the dark about all of it.
My wait for Toki on C64 did not end until many years later when I was able to find the cartridge rom to load into an emulator called CCS64, but by that time I had already played the game on my Amiga first and then the coin-op on MAME, so the interest I had in the 8 bit Commodore version was now only superficial. Still, I played it a bit, and I knew that if it had come out in '91, as it was supposed to, I would not have been entirely satisfied with it. Despite being an above-average porting that follows the original quite closely, in fact, there are several flaws. The sprites aren't particularly faithful in design and in many cases, they are quite ugly. I was particularly disappointed with the main character, but it’s not even the worst-looking of the bunch. On the other hand, the backgrounds are nice, yet the last level is of a significantly and strangely lower quality than the others. The soundtrack is nice, but it has almost nothing to do with the original mood, it’s just one piece of music for the whole game and is not played along with the SFX, which are quite poor anyway. Finally, playability is decent, but some problems in the control system and unforgiving collisions make the game too difficult and frustrating.
Now let's take a time jump and get to early 2023 when I got the urge to do pixel art for a game again (I used to make homebrew PC games between 2002-2008) and decided to finally make one for the C64, which I had never done before. To speed up the process of learning the limitations of the machine, I thought it would be nice to redraw an existing game that was lacking in the graphics department so that I would have a reference point and I also could have done justice to both the game and the C64. I almost immediately thought of Toki, not just because I am still very fond of it, but because fundamentally the structure of the game is well done: it is not by any means perfect, but it is playable and very similar to the coin-op, even just changing the sprites without rewriting the code would result in a game more like the original, and only a few fixes would be needed to make it more playable. I also thought that it would be much easier to find some coders willing to help me modify an existing decent game than if I chose to rewrite Final Fight from scratch, for example.
2. What tools are you using to draw the graphics?
Years ago, when I was making homebrew games for the PC, I used to create my own pixel art with Paint Shop Pro 8 which I was really happy with. Obviously, that program now doesn't work on a current PC so for Toki C64 Remastered, not knowing if the project would take off, I chose to use Paint.NET, a free tool with a minimal learning curve, which allowed me to focus right away on the fun, creative part. Initially in fact I had tried Gimp, but for me, the GUI is counterintuitive and uncomfortable. Paint.NET is obviously much less powerful, but the program's simple interface and lightness make up for the lack of some advanced features I was accustomed to using back in the PSP8 days. Along the way, I've added a couple of very useful extensions, such as one to reduce the number of colours on the source material and one that allows previewing animations, and so far I haven't felt the need to upgrade to a more advanced tool.
For future projects, I may consider looking into dedicated packages such as Aseprite, but at the moment the bulk of the work is done in Paint.NET. When I reach a point when I am happy with the results, in order to do the final retouching in a 100% C64 compliant environment I import everything into Spritepad Pro or Charpad Pro, depending on whether it's sprites or character-based backdrop graphics. These two commercial tools made by Subchrist Software do a really good job for me.
3. How did Euan get involved with the coding?
After deciding on the sprite palette and drawing a few test characters, in early February 2023 I began posting on social and forums looking for programmers willing to collaborate. Mariano Cigliano contacted me almost immediately, and a few days later Pasquale Sannino also joined the team. A fantastic surprise came a few weeks later when Aldo Chiummo, author with his brother Gaetano of the soundtrack to A Pig Quest, quite unexpectedly sent me his excellent version of the music for the first level of Toki! He converted the entire soundtrack for the game shortly thereafter. Meanwhile, Pasquale got the first results in reverse engineering the cartridge and Mariano wrote custom tools to replace in the code the old sprites with the new ones automatically, starting from spritesheets prepared by me. So we were able to create the first updated build and validate the whole project! Later Mariano suggested that we invite Euan Gamble, an expert in disassembly, to help us out. Euan thus spent a lot of time understanding the sprite inputs and now quite a few of Toki's enemies are updated with correct colors and offsets. This is not an easy task, even knowing where and what to look for, because Toki's code is very complex and exploits both multiplexing and multi-sprite characters.
4. What has been the toughest part so far to redraw?
There’s been a few things that gave me headaches, and some still do. Take for example the first fundamental choice I had to make at the beginning of the project, the sprite color palette. Sprites on C64 can use just 3 colours, only 1 of which is customizable for each sprite, while the other 2 are fixed and common to all sprites in the game. It goes without saying that with 2 fixed colours out of 3, it is literally impossible to reproduce with the "right" colours all the characters of a colourful coin-op like Toki. From my point of view, if there is one sprite that absolutely must have the right colours, it is that of the main character, the one the player has always in front of their eyes. In the Ocean version, Toki has a light grey cadaverous face and even the fur turns to dark grey, definitely not a pretty sight that has always annoyed me greatly. One of my sticking points from the beginning is that the protagonist ape must have a yellow face and brown fur, like in the coin-op. So I chose to use as fixed colours those that guarantee me the best possible rendition of the main character: brown and yellow. This choice allows me to create a very colourful game (unlike the pale original conversion that used as many as 2 greys as fixed colours), also quite faithful to the original in most cases. I cannot stress it enough: on C64 there is no sprite palette choice that allows complete colour fidelity in all the sprites of the game, it is a matter of choosing what you are willing to give up.
The problem now is how to handle situations where I don't have the right colours at my disposal: of all such cases, my worst nightmare is still the level 2 boss, Rambacha, the eye-shooting white ghost. I can use white as his sprite colour, but to really do him justice I would also need a grey shade and I can't because of the limitation of 1 sprite colour (white in this case) + 2 fixed global colours (brown and yellow). So even though I drew him with almost absolute fidelity to the coin-op design, I’m not totally happy with the colouring and I'm still considering whether it would be best to completely rethink his palette and "Commodorize" the character’s look. That of the 2 fixed colours in the sprites is in my opinion the biggest stumbling block any C64 conversion has to deal with. The other problem is the low resolution with rectangular double-width pixels, which is felt quite a bit in Toki. The characters in the arcade have very pronounced physical features and facial expressions that make them grotesque and unique, so making them recognizable and expressive with a halved horizontal resolution is really challenging. This is the reason why I didn’t start redrawing the main character's sprites until 8 months into the project: I saved Toki for last on purpose, in order to build on the experience gained from redrawing all the other characters and make sure to nail his design and make him look as good as possible. I am quite happy and actually relieved with the way it turned out in the end!
5. What are your plans once the remake is finished?
My biggest dream is to develop a high-quality, original commercial game for the C64. It is with this ambitious goal in mind that I started the Toki remaster, to pick up my skills as a C64 pixel artist and find collaborators. I would like to publish commercial games for other systems as well, such as Amiga, Mega Drive, and Spectrum Next.
I have several game concepts in my drawer waiting only for the right coder to become reality, so if there is any experienced programmer listening who is interested, please do not hesitate to contact me! I would also enjoy remastering another 8-bit game, probably for C64, but I am open to all possibilities. Again, I invite anyone who has some familiarity with retro systems programming and wishes to deepen their knowledge while having fun in a challenging project to join our passionate team: the retro gaming community will be grateful to you for reviving one of their favourite games!
Interview with coder Euan Gamble:
1. How did you get involved in the Toki project with Davide?
On Twitter I post exclusively about Commodore 64 reverse engineering. I was reverse engineering A View to a Kill to get the solution to all levels. I then started working on Ghostbusters and Chiller. I was hoping to make Chiller a little easier and was posting my progress. One of the developers from the Toki project messaged me and asked if I could help them out. So, I joined. I have been quoted as a 'C64 reverse engineering expert' - I do not know if I would consider myself that, but I do a lot of it.
2. What tools are you using to reverse engineer the code?
So, I use Retro Debugger (C64 Debugger) a lot which is a great tool. I also built my own Python disassembler because I found most other tools were not flexible enough. That and I also wanted to include my own comments. So, my Python script is really helpful and speeds up the process a lot.
3. What have been the most difficult parts so far to change/update?
Toki is a really complex game. Ocean was converting from an Arcade game with multiple enemies and levels, so the game has all these assets crammed into the cartridge. So, the game is constantly switching assets in and out during the game and dynamically making a set of sprites to show. Davide has extremely specific ideas about how the sprites should look (almost arcade exact) and so that requires repositioning, changing hitboxes, etc. So, finding the sprites, finding how they are loaded, and then finding the sprite properties is quite challenging. That and its super-complex code.
4. Are you working on any other C64 projects?
So, at the moment I switch between updating my own Python disassembler, writing scripts to convert from Spritepad to the custom sprite format that Toki needs, and Toki reverse engineering. If I need a break, I sometimes go back to A View to a Kill and Chiller as I want to make a complete set of commented code for both games.
NEWS BYTES
AMIGA: Andy Vaisey released Spheroid (previewed in RG254) at https://bit.ly/spheroid-amiga
Locomalito’s L’Abbaye des Morts received two different Amiga versions both requiring 1Mb of memory – Jeefrog’s version is at https://bit.ly/abbaye-amiga while The Abbey(s) of the Dead by AB UltraNarwhal adds a second abbey to explore, via https://bit.ly/abbeys-amiga
AMSTRAD CPC: Play On Retro released the excellent Booty Remake - https://bit.ly/booty-remake
JAGUAR: Reboot Games announced the forthcoming Rebounced, inspired by the C64 game Bounder - https://bit.ly/rebounced
LYNX: Lynx Jam 2023 - https://itch.io/jam/lynxjam-2023/ - challenged competitors to make a game with the same tile set, resulting in great games including Dungeddon and Silly Archery (the latter played in TATE mode).
MASTER SYSTEM: Tzar created an excellent port of the classic Battle City, with v2 adding sound. https://bit.ly/battlecity-sms
PICO-8: Paul Hammond’s latest arcade adaptation is Amidar - https://bit.ly/amidar-pico8 - while Crazy Taxi fans will enjoy Whiplash Taxi from Tom Mulgrew - https://bit.ly/whiplash-taxi - with its Time Attack, Street Race and Free Explore modes.
PLUS/4: Csabo has produced Into The Eagle’s Nest Deluxe, recolouring the graphics and fixing bugs. https://bit.ly/eaglesnest-plus4
SNES: Try the demo of super-cute platformer Dottle Flowers from Goldlocke (pictured) to get instructions on buying a physical cartridge (Super Famicom compatible). https://bit.ly/dottieflowers
NOTE: Since this issue was released, the game is now available for free download at the above link.
ZX81: Jonathan Cauldwell’s Fun Park recreates Theme Park, requiring 16K memory, the Chroma colour board, and the Quicksilva Character Generator board. https://bit.ly/funpark-zx81
CHAMPION CODER
[Name]
Olof Naessén
[Info]
From: Sweden
Website: http://darkbits.se / https://darkbitsorg.itch.io/
Format: NES, SNES
Previous game: Death Strike, Dazed In Space (Windows)
Working on: Data Man (NES)
After creating homebrew games for Windows, Olof is turning his attention to Nintendo hardware.
What got you into programming your own games?
It all started when I got my Commodore 64 as a kid. I remember I was super excited when I realised you could program your own games on the machine. However, I didn't know English at the time and information wasn't available in the same way as it is now with the internet, so it was quite difficult. The only thing I had was the C64 manual to go on, so in the end, I managed to make a few simple text adventures in Basic and that was it. But it was enough to spark my interest in programming.
What inspired your Windows games on your website?
It varies from game to game. I guess ultimately, it's about fulfilling childhood dreams of making the games you dreamt of making. I'm mostly drawn to 2D-pixel art games as I like the fact that you can make a complete game with everything it entails by yourself. I usually make a game to prove something for myself, be it that I have a story idea, some idea about a soundtrack or that I have an idea for new tech or a game engine.
How are you enjoying developing for NES and SNES?
I really like developing for NES and SNES. It's a stark contrast to my daytime job in the AAA game industry with huge complex games and big development teams, which makes NES and SNES dev a nice and relaxing hobby for me. NES and SNES enforce limitations which I think makes it easier and more fun to be creative. The fixed hardware is also a comfort, if a game runs well on your NES at home it probably runs well on every NES, compared to a PC game where you never really know if it truly works due to the endless number of hardware configurations out there. It's also an incredibly good feeling to master hardware. For instance, I occasionally go back to my old Commodore C64 and program silly things in assembler which is great fun. I finally have a good grasp on how the Commodore 64 works, something a seven-year-old me could only dream of (I now know what the strange words LOAD and POKE actually mean)!
What development environment and tools are you using?
NES and SNES games are programmed in assembler with a text editor and CA65. For debugging, I use the emulator Mesen and a flash cartridge from Krikzz, such as the EverDrive N8 PRO and FXPAK PRO. I always regularly test on real hardware, but emulators today are so good that you seldom encounter issues. For graphics, I mostly use Aseprite and NES Screen Tool. Usually, I also develop tools of my own to ease development, for things like generating level data or graphics data. I write my own tools mainly in C/C++ but sometimes Python. What tools are needed varies between games and hardware. A typical example is images that cannot be stored as PNG files but need to be converted to a native format the hardware understands.
What is the idea behind Data Man, and what games inspired it?
Data Man is made by me and two friends. It all started with the fact that we wanted to make an NES game and a game we could play together without competing but truly cooperating. Early on we decided to target the smallest possible cartridge commonly used in the early days of NES to restrict ourselves as much as possible. The cartridge itself has 40kb of storage and our thinking was that with 40kb of storage, we will run out of space someday and will be forced to acknowledge that the game is done. Once we had settled on a cartridge the decision to go single screen - like most early NES games - was pretty easy. Exactly how we came up with the idea that you defend the NES and its CPU itself from bugs I don't really remember, but I think we were all very focused on the hardware, so I guess it started as a joke. In the end, it fitted the co-op game we wanted really well given that health is shared between players. For games that inspired us, I think Xeno Crisis by Bitmap Bureau was a big inspiration, not only in terms of gameplay but also the fact that it is a fantastic homebrew for the Mega Drive.
The videos on Twitter promise flicker-free movement with lots of sprites onscreen - what's the secret?
We don't promise flicker-free movement as the hardware limitations are what they are. What we have said is that we can have a lot of entities on screen at once without any noticeable or big slowdowns. And when it comes to secret, there is no real secret, just optimized assembler code that handles all the entities when it comes to updating their logic and drawing them onto the screen.
How much more work is needed to finish the game?
The game is more or less done at this point. What we have left is balancing and testing to make sure we have as few bugs as possible. At the time of this writing, we have 247 bytes left of cartridge space, so plenty of space for fixes!
Are you planning a digital or physical release?
We plan on a digital and physical release and the target is Q1 2024.
How is your SNES project progressing, and what sort of game is it?
My SNES project is a port or perhaps remake of an unfinished RPG or adventure game I've done for PC. Ever since I first played a SNES RPG I've always wanted to make something similar, but I've never really gotten around to it until recent years. I started the work on PC as I already had a pretty solid game engine to work with, but in the end, I never managed to complete it. Moving it over to SNES is a way for me to start over fresh and to try to fulfil my old dream of making an SNES RPG. At the moment the project is on hold until we have finished Data Man, but I will definitely come back to it soon.
What have been the most difficult parts of developing for Nintendo hardware?
I think today in general it's not as difficult as people might think. There are many good tools available, lots of documentation all over the internet, a very friendly and good community around homebrew and several languages and options to use to develop games. I would highly encourage anyone who has an interest to try it out. But if I would pick something it would be the first hurdle you encounter when you need to learn how to coup with a machine that doesn't have multiplication, division, or floating-point numbers easily available. Things you take for granted in most programming languages of today simply aren't available, and it takes a bit of time to get used to.
Have you played any great homebrew titles recently that impressed you?
As mentioned, Xeno Crisis by Bitmap Bureau is an amazing game and a true source of inspiration. I've also got a copy at home of Alwa's Awakening which is a very impressive title for the NES made by Elden Pixels.
DATABURST REVIEWS
Briley Witch Chronicles 2
Format: C64
Credits: WitchSoft (Sarah Jane Avory – design, graphics, programming, music; Paolo Rathjen - graphics)
Price: $9.99 or more (digital download)
[Score]
90% - Retro Gamer Sizzler
Strife Sisters
Format: PC Engine
Credits: Matthew Kersey
Price: £20 (digital download), £48/£80 (physical CD/limited edition)
[Score]
83%
Forest Escape – A Knight’s Quest
Format: ZX Spectrum (48K)
Credits: IrataHack
Price: $3 or more (digital download), £9.95 (physical cassette)
[Score]
82%
PROCESSING - PREVIEW
The Sorcerer’s Curse is the working title for badcomputer0’s Master System platform game currently in development.
What is the idea of the game, and what games inspire it?
You play as a tiny wizard trying to defeat an evil sorcerer and release a curse from your village. It's inspired mainly by Wonder Boy III and Castle of Illusion, two games I loved growing up.
What is your development environment for Master System games?
I'm using devkitSMS by sverx: https://github.com/sverx/devkitSMS It's a development kit and collection of libraries for SMS and Game Gear and allows you to program in C language rather than assembly.
I program in Visual Studio Code and debug using the SMS emulator Emulicious. I also use Aseprite for pixel art and Tiled for constructing level maps.
Is there anyone else involved?
Not yet, but I'll be looking to work with a chiptune musician later on for sounds and music.
Any idea how long development will take?
Not sure, I'd guess at least 6 months. I can't devote all my time to it, but I work on it some evenings and weekends.
For more updates follow @badcomputer0 on X/Twitter, or his pixel art feed at @helpcomputer0.
