THE WILD WOOD - JOHN HENDERSON INTERVIEW
When did you start making C64 graphics?
I started making C64 Graphics quite late, my first C64 bitmap was created in 2013 for a text adventure “Escape from London” – unfortunately, this was destined to be a “Game that Wasn’t”.
What inspired you to start making The Wild Wood?
That’s a good question. I don't know really, I guess the answer lies with the wish to combine my love of creating art and my love of the C64 and wanting to make something special for it. I started doing some C64 bitmaps just for fun and the idea slowly fomented to produce a showpiece game which looks almost 16bit and where I could treat each game screen like a C64 painting.
My ambition for Wild Wood was to produce the kind of high-end fun platforming adventure I wish had come out on the breadbox when I was a lad.
The Wild Wood setting itself was roughly based on the famous dark location described in the classic book "The Wind in the Willows" by Kenneth Grahame (a favourite of mine as a child). The book celebrates the English countryside and with that as my starting point, there are all sorts of related locations I could create. I’ve always loved the natural world and translating it into semi-realistic C64 pixel art is the kind of challenge I knew I would enjoy. Mostly I was excited about building a world of open fields, gothic cathedrals, river banks, catacombs, underground warrens, woodland glades, lost druid settlements and cosy homes in trees, and then of course populating it with the resident animals.
How do you go from sketches to pixels, and what tools do you use?
The design process varies depending on the type of art/level I am creating.
For an 8-way scrolling level, I will roughly sketch a map before I begin and think of some key features I want to include, for instance, the huge kneeling Angel statue present in the Cathedral. I then just start drawing the main tiles with unique chars to build these key sections. After that, I construct the rest of the map re-using and re-purposing the unique chars to make new tiles. I think it is important to link the tiles seamlessly in a map (I don’t like it if you can see the obvious blocky joins of each tile in a game) - This optimising process is quite laborious, and one map may take me a few weeks. Finally, play-testing and refining and repeating the design process until I am satisfied it all works. I have scrapped and re-started a couple of level designs from scratch, even though they took a long time and looked good, I can’t settle for just OK.
The parallax-heavy horizontal scrolling levels take a lot of planning, working out each layer and where I can use sprites to squeeze the optimal number of layers and detail out of the engine. I draw each layer individually and plan the foreground “edges” which frame background scrolling areas as this is key to making everything flow just right. When all that is in place it’s just a matter of deciding on the terrain variations in the actual play area and working on the gameplay.
For sprite animations I tend to place pixels straight away without working from a sketch, sometimes using film clips of animals as reference. For very large creatures which use multiple sprites (of which we have a few), I need to physically draw the animation frames in a flick book first and scan and port them before making adjustments. It’s a long process, but worth it. For all this, I use both SpritePad and CharPad by Subchrist software. These tools are always being improved and the guy behind them was kind enough to make some special adjustments for Wild Wood a while back when I needed it. The Pro versions are really excellent value for money.
The accompanying bitmaps within the game are a very important aspect of the storyboarding and really help to set the overall feel of the adventure. Every single level is introduced with a bitmap, like a reward for finishing the last level. For these, I draw out an idea on paper with not too much detail and then work closely from that sketch straight into Project One (available app free on CSDB). It’s a basic process, placing one pixel at a time and not particularly time efficient, but it’s how I like to do it and feels the most like actually painting to me. I would hope that my natural artistic style comes through even though it uses the medium of pixels over oil paint. A fair example is the Game Over screen here where I have stuck quite closely to my original drawn design.
There are three different coders working with you, what strengths do they bring to the project?
I am very lucky to have 3 very talented coders onboard who have dedicated their time and expertise to the project.
Achim [Volkers] is the lead coder, and I would say that his strength is his amazing problem-solving skills and ability to look at the big picture, often bringing my crazy ideas based on pure C64 coding ignorance into reality within the game. Also, I would say his resolve in working on a level or game element and ironing out imperfections through many many iterations has been evident throughout. Achim also brings a wealth of experience of working on many successful C64 game projects in the past and his sheer knowledge base is impressive, to say the least.
Jon Woods is a highly technical coder and his knowledge and specialism of working on complex parallax and graphical effects and his willingness to push what is possible is second to none. His own C64 game Parallaxian is genuinely an innovative marvel.
Artur [Bujdoso] has been super to work with, he is willing to work independently on some of the stand-alone elements of the game (such as the animated End Sequence) and make them fit my vision without compromise. Again, his keenness to push the envelope has been essential in order to make these elements special.
Are there any particular coding tricks or graphical techniques that will be used in the game?
I would guess that the logistics and technical process of handling a huge amount of gfx data on a humble stock C64 is something which requires a lot of creative problem-solving, such as in the massive scrolling intro. However, for technicals, I would pass you over to Achim:
Achim: "There are no specific tricks in particular. Biggest challenge from the coder's point of view is the sheer number of different enemies. Each level has its own set of enemies coming with individual movements and interactions. So, every level is basically a game of its own. Apart from that the game engine has to handle typical game features like sprite multiplexing, 8-way-scrolling, various parallax effects, and sprite mirroring."
From my point of view as a pixel artist, one consistent graphical technique I have employed throughout is making sure I create a strong single light source in every backdrop and in particular drawing actual depictions of the light beams to help create drama.
The choice of a hare for the lead character is unusual, how does that affect the gameplay?
A fair question. I wanted a character which hadn’t graced the C64 before (to my knowledge) and also one which would fit into the Wild Wood as being prey. Gameplay-wise, this choice does affect things, certainly in terms of platform spacing and overall level design as a hare is quick and feisty and having a strong athletic leap is intrinsic to its movement. The player has a few moves which look natural to a hare and a couple more unusual feats it can achieve (such as a barrel roll). The hare is not aggressive (won’t be pulling out a shotgun or start biting things), but it is not without its offensive moves.
What other games are you drawing on for inspiration?
I think Turrican II is a pinnacle of C64 gaming, and I admire so many elements of it: The excitement of a whole world opening up as you explore deeper through many varied and beautiful levels, looking forward to see what will come next – The cool bonus sections were always an unexpected treat too. I guess I have borrowed a number of the gameplay features. To me, the sheer ambition of Manfred Trenz is a wonder. Finally, the wonderful Turrican soundtrack can’t be ignored in making it a memorable experience. I am lucky to have the very talented NM156 working with me, and his superb music is carefully thought out to make each section as immersive as possible and fit the individual level styles.
Which other C64 artists do you admire?
I think in terms of talent and attention to detail, you can’t ignore Robin Levy, his bitmaps and animations are always top-class. A “game that wasn’t,” Deadlock, I’m sure would have been the best-looking C64 production ever. Yeah, I would say he is the top of the tree in my eyes.
How large is the game going to be, in terms of levels and map size?
In a word. Massive. There are lots of different types of level and many unique locations to work your way through. Boss events and bonus levels are present as well. Some maps are very very large (Turrican style), others are more of a shorter linear stroll/sprint in the park (think Flimbo's Quest level length).
Have you played many of the other recent C64 releases, and what impressed you?
That Sonic ever made it to the breadbox was a super achievement and I was shocked by its great execution. I of course enjoyed Sam’s Journey and how slick it was in terms of the overall presentation. Working with Acied on Puzzle Bobble C64, I was overwhelmed by the amount of processing power he could squeeze out of a stock machine without the need for a cart or special peripherals, surely, it’s one of the most accurate ports on the C64. An honourable mention must go to the intro on Hunters Moon remastered, you could really see the love that went into that.
What other C64 games have you been involved in?
Off the top of my head, Frantic Freddie II, Planet X 2.1, International Karate - Competition edition, Puzzle Bobble C64, Endless Forms Most Beautiful, Cursed Tomb and a few games still in production, such as Civilisation C64. Mostly loading screens, animated bitmaps or maps or some sprites here and there. I am also busy on some work for games which have a C64 aesthetic, such as the wonderful Skald.
Do you have any other projects in mind?
Yes, I certainly do. Though I won’t take anything on until Wild Wood is finished.
Would you work on other systems as well?
I would consider it. the Amiga appeals to me, but my first love will always be with the C64. A port of Wild Wood would be a possibility for other systems if there was the demand.
How would you rate yourself as a game player?
I would generally say, average at best. A lot of C64 games are very hard (IMO) so I have only completed a few of them. I really enjoy shoot-em-ups and the other year I finally finished Blood Money, a mere 30 years after buying the original on tape! Wild Wood won’t be a pushover, but I will make sure it does not require you to be superhuman or cheat either, plus we don't all have 30 years!
- for more on the game & to get email updates
NEWS BYTES
AMIGA: Jotd unleashed his version of Karate Champ VS at https://bit.ly/karatechamp-amiga
AMSTRAD CPC: Onevision, Lunoka and JMB produced this enhanced version of Ocean’s Mario Bros. https://bit.ly/mariobros-cpc
ATARI 8-BIT: Tenebra Extended is now available for Atari fans, thanks to Haplo - https://bit.ly/tenebra
C64: Station, dude! Check out Bill & Ted’s Excellent Game Boy Adventure, converted by Roman Werner with music by Nordischsound. https://bit.ly/billted-c64
DOS: Raphnet has updated his CGA game Orbital Salvager - https://bit.ly/orbit-salvager
GAME BOY: Asobi.tech made their Super Jet Pak DX game (also compatible with Game Boy Color) available for free at https://bit.ly/superjetpak
MEGA DRIVE: After it was successfully funded on Kickstarter, PSCD Games is offering a free demo of Hunter Girls - https://bit.ly/huntergirls - with physical cartridges to be on sale later.
MSX: Two games recently released are Duckstroma Part 2 from AB UltraNarwhal ( https://bit.ly/duckstroma ) and Virgil’s Purgatory v2 by Amaweks ( https://bit.ly/virgil-msx ) - and both games have ZX Spectrum versions available at those links.
PICO-8: Paul Hammond’s latest (pictured at the top) is the brilliant Lee: Dragon Fury, inspired by the classic Bruce Lee. https://bit.ly/lee-pico8
PLUS/4: A superb conversion of Stunt Car Racer is now available at https://bit.ly/stuntcar-plus4
SNES: Infidelity has converted the original Legend of Zelda game to the 16-bit console – as well as a conversion of NES classic Duck Tales. https://bit.ly/zelda1-snes
CHAMPION CODER - UNDER4MHZ
From: Brisbane, Australia
Website: https://under4mhz.itch.io/
Format: Multi-format
Previous games: Vexed, Pegged, Mahjong, Klondike, Bloktris
Working on: Wolfenstein Maze3D (Master System, Game Boy), Prince of Persia (MSX, ColecoVision)
Paul has produced several recent multi-format puzzle titles and has more games in development.
When did you start writing homebrew games, and which machines did you have when you were younger?
I had a Sega SC-3000H computer as a youth. It was basically an MSX (non-compatible) computer using the same components available at the time - TMS9929 for the video and SN76489 for the sound (identical to the ColecoVision in terms of hardware).
When I decided to start writing homebrew games, I naturally chose the SC-3000 for my primary platform. The SC-3000 was a line extension of the SG-1000 gaming console, so this has become my target, since it seemed to have more attention (though generally less available where I was).
Later on, I had a 286 IBM compatible PC running DOS, so a few of my games are inspired from this system. Much later I had a Palm III, which other games (such as Vexed) came from.
I’m inspired to port games from other systems that I wish I’d had on my SC3000H computer. The system had a thinner selection of games, since most of these were distributed by Sega themselves; either written by Sega or ported from MSX. I was jealous of my counterparts who had Commodore 64s and had a wide selection of interesting and inexpensive games to choose from.
What made you decide to create a single game across multiple formats?
The problem with the SG-1000 was that it only reached the Asia-Pacific and France, and even then it was far behind the major home computers at the time (the C64 and Amstrad CPC). This meant that there aren’t actually many modern users.
When I started releasing my games for the SG-1000, I went to SMSPower.org to post them, which is the main forum for the platform. While they support the SG-1000, their main focus is, as their name suggests, the Sega Master System - the successor platform to the SG-1000. User feedback I received suggested that there would be more interest in my games by supporting the SMS. I wanted people to play my games (that is the point after all), so that’s what I did.
Once I’d supported that platform, the next natural step was to support MSX and ColecoVision, which are very similar systems. It didn’t take much to port it to these platforms.
I started looking for other similar platforms to bring my games to. There were a few other systems that were very close in hardware such as the Memotech MTX, the Sord M5 and the SpectraVideo SVI 328, which have a few quirks but didn’t need any actual changes to the game code to support.
This was a decision point I spent some time considering. How to maximise the reach of my games? Should I write more games for the platforms I support, or do I port my existing games to more platforms? I felt that porting to more platforms would gain more users than making more games. It was partly motivated by personal interest. Since I’d been porting to various systems, I became interested in how these other systems worked. I decided to port my games to the existing popular Z80-based systems of the time.
The next most popular platform was the ZX Spectrum, which of course was popular in the UK. Unlike the systems I’d supported up until now, the ZX doesn’t support hardware sprites and has a bitmap screen, so I’ve stuck to puzzle games for this platform, since it’s much easier to write blocks in 8x8 tiles.
Amstrad CPC support followed, which also didn’t support hardware sprites (in their earlier products. Since I wanted to maximise the extent of my games, I wanted to support the earlier products, and not assume later more feature-rich versions.
The Spectrum Next was, well, next. Since it’s a new platform that not too many developers had targeted, I thought that there may be more interest from users of this platform (that didn’t seem to be the case).
Gameboy followed, which is tiled and has hardware sprites. This is a Z80 variant, with memory-mapped RAM. It only allows writing to the vdu during the vblank period, so it required some optimisation to limit the amount being written to the vdu at the time.
What sort of codebase are you using to port it across formats?
I’ve written everything myself. My original goal was simply to support only the SG-1000, I really had little intention of supporting any other platforms. I started out using SMSPower.org’s devKitSMS as a reference which also has an SG-1000 component.
This library wasn’t sufficient for my needs (for SG-1000), being just a basic API. In order to really get the most out of these platforms, I really had to understand the inner workings and the limitations of the system. It’s different today, where there’s just a game API, and it makes little difference the platform it’s running on (e.g. Windows, Mac or Linux). These old 8-bit machines are running at 3.6Mhz - MegaHertz, not GigaHertz, so 1 / 1000th of machines today. If I want to do anything impressive, there has to be very little between my code and the hardware. Sometimes even a function call has too much overhead and I often use macros to avoid the overhead of function calls.
It took some time for me to really get my head around the ideology of these older platforms. I kept trying to write to them like it was a modern bitmap display. But most are tiled; this is how they got enough speed on such slow systems. They have to be programmed as tiled graphics for them to be effective. I spent a lot of time trying to get lines drawing on the SG-1000 and it’s simply not capable of doing so (at any reasonable speed for a game).
A lot of my motivation is just interest in these platforms, and the challenge of figuring out how they work. They all effectively have their own image formats and data protocol that needs to be worked out.
This approach also allows me to have a lot of consistency in my APIs across platforms. I don’t change my games (very much) when I add a new platform. Just new imagery and a new hardware layer.
One of the consequences of using my own code is I’ve had to work to the lowest common denominator. The SG-1000 has no BIOS, nothing, so I had to write all the code for playing background music and effects, writing to the vdu (video display unit) all myself. The result of this is I have used the same code across all platforms, even when I could take advantage of the BIOS code on the ColecoVision, MSX or CPC to play music, access the keyboard and joystick or access the vdu. This makes my games larger than they should be, but then it makes the porting a bit easier by limiting the need to learn the BIOS API.
What major tools and languages are you using?
All my games are written in C using SDCC (Small Device C Compiler).
It was a choice between it and Z88DK. I chose SDCC mostly because that was the platform the team at SMSPower.org recommended. From what I’ve read, Z88DK tends to create glue code for calling its various functions rather than producing pure assembler, so it tends to produce a slower binary.
I’ve been submitting tickets to the SDCC team over the last 12 months or so and it’s become a very stable and usable product.
cmake I use as a build system. It can be quite finicky to get working and has a reasonable learning curve but it is a powerful tool. It is also a tool I wanted to learn for my professional career.
I used Emacs as an editor. When I started programming, it was either this or vi to use as an editor on Unix platforms, nothing else was available (for free). I’ve just stuck to Emacs over the years. I’ve hacked on it so that it essentially feels like Visual Studio anyway. And when I navigate text using Control-Right Arrow, it doesn’t stop at both sides of every punctuation mark it comes across (seriously, that’s a big deal).
Ubuntu Linux is the operating system I use. The tools I use all tend to be command line and seem to work more seamlessly with Unix than Windows. I use Linux for work anyway, so it’s no extra effort to use.
One of the challenges with SDCC is that it’s only the compiler. It doesn’t support any actual hardware platforms, so I’ve been forced to add support for them myself. It can be difficult to get information on how to actually just do a simple C program to show some pixels on the screen. Often getting crt0 code (the assembler to bootstrap the system and start the game) can be quite difficult. What memory location should a game be loaded to and the header bytes needed can be challenging to find. There’s a lot more information available for these systems now as modern developers have taken more of an interest. But a simple crt0 code for SDCC can be quite rare.
I use Bash scripts to compile resources (level maps, images, sprites and music). This was just easier and more powerful than cmake for file manipulation. Often I split up images and loop through lists of files and this is more naturally done in bash.
I write all the image conversion tools (to the target image format) myself in C. I contemplated using Python, but I don’t know Python that well (though I’m using it a bit for work now) and it meant I could reuse some of the low-level vdu code used in the games.
How do you develop the graphics and sound across formats?
For graphics, I wrote a set of tools that convert PNG images to the native format for each system. I have gimp with the palette for each system and I use it to convert the colour palette of the images or tiles to the target system. Sometimes that takes a bit of tweaking, since gimp matches the closest colour, rather than maximising the colour range. There may be three green colours on a system and these are quite close together in visual appearance (MSX colours for example tend to be quite close in luminance) and gimp will match to one or two, where I’d prefer to match to all three. So I’ll have to manually colour change each green and then gimp will automatically change the rest.
After the colours are right, I’ll use the tools I’ve written to deal with attribute clash. ZX Spectrum, for example, only allows two colours per 8x8 pixel square, so I determine the two most used colours in a square and use those. This generally works well enough. Other times, I’ll manually update the tiles to adjust to maximise the best use of the attribute/colour clash.
Prince of Persia, for example, I use the tiles from the NES version, but I’ve had to tweak the tiles a reasonable amount due to the more restrictive colour limitations on MSX - 2 colours of 16 per 8x1 tiles on MSX, vs. 1 of 4 colours per pixel. This is all manually done by iterating the production of the tiles and trying them in the game.
For background music, I’ve written a tool to convert from MIDI files to the sound format on the system. Some systems have dedicated chips (known as a programmable sound generator or PSG), others have a beeper, requiring the programmer to manually toggle a single bit on and off to generate sound (such as the ZX spectrum). For the ZX Spectrum, I’ve written my own code to toggle the bits (based on an example found on the ZX Spectrum forum).
For sound effects, sometimes I copy them from existing games, such as Mahjong or Sonic for the Sega Master System (SMS). Other games I copy the sound effects by looking at the sound in Audacity, and manually go through the frequency chart 16 ms at time (60Hz, the rate at which the sound can be changed in the video display unit’s interrupt handler). This generally creates effective sound effects, a method I used for replicating the sound effects in Wolfenstein 3D for SMS. I’m a programmer, so I don’t typically design my own sound effects, I get them from somewhere else.
What have been the major issues with working multi-format?
Each system is generally unique and has its own quirks. Often finding and then interpreting the information can be quite difficult.
Recently I’ve been using https://www.chibiakumas.com/ for cross-platform information. While sometimes it can be incomplete, it’s mostly there and he supports most retro platforms. His stuff is largely in assembler, while I’m in C, so it requires some conversion.
Since each platform is different, I have to update my internal low-level API to match the new system. This means changing all the platforms to match this API. Some systems have more colours, or more tiles, some have hardware sprites and some don’t, some are memory mapped, some use I/O. Each has its own way of doing things, so the API must reflect all these variants. Getting something that fits all systems but is still precise and small has been a challenge.
Each time I fix an issue with a system, invariably another system is broken in some way. This means I have to go through and test a game for each system and make sure it still works, adjusting any problems along the way. Then those fixes will create more problems, so I have to fix those. I have to do this for each game as well. It can become time-consuming, taking away from actually creating a game, which is my main goal.
Some platforms are tile-based, such as MSX and Sega Master System. The programmer creates a bunch of 8x8 tiles and uploads these to the vdu ram, then tells the vdu how to arrange these on the screen. Others are bitmap-based, such as the ZX Spectrum and CPC, where the programmer must tell the vdu where each pixel is on the screen manually. (The C64 actually supports both, but I used it in tiled mode).
The tile-based system is much faster, since the programmer usually only needs to update the tiles, whereas bitmap systems need the whole screen to be updated. Other systems, such as the GameBoy, even updating the tiles is slow. For the bitmap systems (and GameBoy), I’ve written a subsystem that uses extra memory to emulate the tile system. This means I only need to update the parts of the screen that have changed. Even games like Boulder Dash, that seem to change large parts of the screen to change, this makes it much faster.
For bitmap systems, which typically don’t have hardware sprites, I’ve only implemented basic sprites that can fall on 8x8 pixel squares, which was the simplest and quickest to implement. Most of my games (so far) have been tile-based puzzles, so this has worked.
Have you seen some of the other multi-format games recently, such as Fabrizio Caruso's CrossLib titles of the Japanese coder Inufuto?
I originally didn’t set out to support all these platforms, I just ended up getting there one step at a time. I was planning to only support SG-1000, so I just wrote my own for that system. I didn’t really start becoming aware of these libraries until later on and it was too late to start using any of them.
I was only aware of CrossLib because I came across Fabrizio posting on Forums I was looking at. I was considering supporting the TI/99 briefly, since it uses the same graphics chip as the SG-1000, but the space available for ROM is too small (8Kb).
Some of the cross-platform libraries can be difficult to find. I’ve done searches for cross-platform and I only happened across a few later on via forums or other developers as I started supporting the platform. Perhaps Google has started doing a better job of listing them. gbdk 2020 (GameBoy which also supports SMS and a few others) and cvlib (for ColecoVision/MSX and SG-1000) are a few others I’ve come across. Inufuto I haven’t seen before, but I haven’t been looking.
It’s been my experience that software platforms usually don’t quite fit what I need. I start adding features to it over time and rewriting parts. Eventually, I end up with my own library and discard the original platform I based it on. I had this experience with wxWidgets. It just didn’t quite do what I needed, and I had to add workarounds and additions until one day I quite literally discarded it and had my own library.
I have looked through CrossLib for ideas on how to port games. It’s an amalgam of other libraries for the systems he supports (devKitSMS is used for Sega Master System) which he’s put a common API across. I think it’s a great idea and he’s supported a lot of platforms quickly.
Do you have any new titles planned, either multi-format or for a specific computer?
Below is a list of games I’m working on, finished or nearly finished (the last part is always the most difficult). Invariably I get bored and start working on something new, or the Resistance comes over me and I don’t release it.
2048, Arkanoid, Asteroids, Burglar Bill, Boulder Dash, Columns, Fantic, Hungry Horace, Minesweeper, Pacman, Paradroid, Pipedream, Pitman 2, Strip Poker, Snake, Ultima 3, Lemmings, Wolfenstein 3D Maze (Game Boy, Sega Master System, Sega Game Gear and Sega SG-1000), Prince of Persia (MSX/Coleco)
DATABURST - REVIEWS
Sam’s Journey
Format: NES/Famicom
Credits: Poly.play (publisher), Knights of Bytes (developer)
Price: digital TBC, boxed cartridges from €60
[Score] 95% - RETRO GAMER SIZZLER
Savage Princess 2
Format: ZX Spectrum (48K)
Credits: Kevin McGrorty (Keezees)
Price: TBC
Web: https://bitmapsoft.co.uk (physical tape) / https://monsters-legs.itch.io/ (digital)
[Score] 85%
Beyond
Format: Sharp MZ-700
Credits: Sharpworks (publisher)
Price: £8 cassette
[Score] 78%
PROCESSING - CHILL3R (C64)
Andy Vaisey howls at the moon with the C64 game Chill3r, inspired by a Mastertronic classic.
What inspired you to create sequels to Chiller?
When I first got serious about learning to code a few years ago after years of dabbling, I wanted to throw myself into the deep end and create a game. However, I didn’t necessarily want to worry about designing a game from scratch as the coding itself would be challenging enough!
I reviewed many budget games that I thought I may be able to do an unofficial sequel to and ‘Chiller’ kind of stood out. I have very fond memories of playing that 1984 game and thought I may be able to make some improvements to the gameplay, sound and graphics while keeping the ‘essence’ and idea intact, thus the ‘Chiller 2’ (C2) project was born.
‘CHILL3R’ (C3) is being created purely for two reasons. Firstly, people asked for more!
Secondly, I’ve learned a great deal about coding in the years since C2 was started, so I wanted to do a sequel to my unofficial sequel and include things I wouldn’t have been able to code or do a couple of years back. Basically, C3 includes all the ideas I wanted in C2, but didn’t either have time or the capability to do!
How much of the new game is based on Chiller 2?
Code-wise, C3 is being coded from scratch other than the control system which was copied over to retain the same ‘feeling’ as C2. As mentioned previously, I’ve learned much more since starting C2 and there actually wasn’t much of the C2 code I wanted to keep, plus the game structure in ‘C3 is slightly different, so lots of the code wouldn’t necessarily have worked anyway without lots of modification.
All the music for C3 is being done from scratch as well, with some reference to the music in C2, again for continuity reasons. I’m aiming for the music to sound the same on both versions of the SID chip. There are many more sound effects as well!
And guess, what? All the graphics are completely new as well other than the game ‘font’ and some sprites and even those have improvements or modifications to them!
Game-wise, C3 is a direct sequel to C2. If anyone completed and saw the short end sequence for C2, then that is where C3 starts. I’m hoping that there will be a small intro that includes the end sequence to C2, and everything kicks off from there. The basic story goes that the boy from C2 is abducted by a monster and the girl must save him.
What are the biggest new ideas in Chill3r?
C3 is a much bigger game being multi-load and disk only. Rather than the one screen per level of C2, C3 has 12 interconnected (flick) screens per stage and I’m hoping for 5 stages, so around 60 screens compared to C2’s 12.
C3 isn’t just about grabbing crosses, although you still must collect 20 to complete a stage. There are also other things to collect such as ankhs (collecting 5 gets you an extra life), coins (collecting 5 entitles you to a speed, jump or strength power-up) and keys (collecting 5 activates something that is secret at present). There are a few other things that pop up to collect as well, such as different coloured apples that boost your energy. There are also a few other hidden features.
There are two game modes. In normal mode, the crosses in each game appear in the same locations, so you can learn and map them to be able to complete each stage. In random mode, the crosses appear in different locations on different screens every single game. That mode is for the real expert players out there!
As already mentioned, I’m hoping to include a small story intro on the disk, along with a nice little ending and maybe a few other bits and pieces. It all depends on time and motivation really as I’m doing everything myself!
When are you planning to release it?
The original plan was to release it next year as 2024 is the 40th anniversary of the release of the original ‘Chiller’. However, I’m not bound by this and if the game is ready earlier, it will be released earlier!
Are you working on any other C64 titles?
Although C3 is taking most of my time at present, I’m also occasionally working on my RPG-lite ‘Lost Realms of Murkasada’ series, two episodes of which have been released so far with the third in production as I type. Also, but a bit further off, is a C64 port of an Amiga puzzle game I’ve coded called ‘Spheroid’ which should be released soon. ‘Spheroid64’ is going to be a direct port handled by myself and should include all the same features of the Amiga version. I’m also hoping to do a PC port as well at some point. Those are personal projects, but I’m also working with my C64 group ‘Arkanix Labs’ on our massive C64 RPG, ‘Crimson Twilight’.
Check out Amiga Spheroid at: https://andyvaisey.itch.io/spheroid
Comments