Alternate Reality: A Return to Xebec’s Demise?

In early 2018 I came to the realisation that I probably wouldn’t be able to contribute much time to working on my port of Philip Price’s Alternate Reality (AR) series which I’d called Alternate Reality X (ARX). My last public release was on 21st May 2017 and personal issues had to take priority. Around the same time an enthusiastic AR fan made some changes to my ARX code and then started a brand new AR port written in Java. You can follow his progress at his webpage and on his YouTube channel where he posts update videos regularly. He’s put a lot of work into the project and I look forward to playing it when it’s available.

Alternate Reality: The City

However, Looking back over my past blog posts and my journey developing ARX, I couldn’t help but feel a nagging desire to work on an AR related project of my own again. My time is still limited and I want to continue work on my own Commodore 64 game project though I have no hard deadline that I’m working towards on that project. Anyway I have a number of AR related ideas that I’m considering.

Enhance the original games

When I started ARX a number of AR fans expressed a desire for enhanced and expanded versions of the original 8bit games running on their original hardware. For me this would be the Commodore 64 and Atari 800. There are a number of positives about this approach and it would allow me to build on my recent experiences with 6502 assembly and coding for the Commodore 64. It has the major benefit that the games are already complete and I can just focus on enhancements without having to recreate code! It would also be an opportunity to hopefully unravel some of the mysteries of Alternate Reality that have eluded players for over 30 years by looking more deeply into the code and mechanics.

However, Not everyone wants to run games on old hardware. To address this I think it would be feasible to package up any enhanced versions with a suitable emulator to make for a smooth, single click experience on a modern operating system. There would of course be nothing to stop players from using their old hardware if they have access to it or emulator of choice on modern systems.

Writing for older systems does lead to some limitations that I think for me could actually be a positive. The hardware and storage restrictions mean I won’t go off on any tangents or wild goose chases, helping me to stay focussed on the core gameplay and playability. I have lots of ideas of features and improvements I would like to add.

This would be a challenging project with a high learning curve for me. Fortunately in 2019 we have a wealth of information, online communities and tools to help us understand the games and speed up modern development for these systems.

New scenarios

One option with a lot of crossover with the project above would be to build new scenarios using the core code from The City or The Dungeon as the basis for a new scenario. It should be feasible to replace the data for graphics, maps, locations, encounters etc with new content. Obviously some new game logic would be required as well for quests and special locations. Opening up and creating The Arena and The Palace within the existing areas within the game maps would also be a possibility.

Revive Alternate Reality X

If I were to consider this then I would be taking some time to review what I had done before and probably strip away lots of the code and partially coded features to make for a more solid foundation. This would take some time. I would probably remove the option for the enhanced graphics and focus solely on gameplay and new features. This doesn’t mean there wouldn’t be new graphics and sounds, just that they would be in keeping with the original 8bit style (or with minor improvements).

I would probably modify the code to make it straight C to give me the option of porting it back to the 8bit machines using CC65 as I wasn’t really doing any “proper” C++ coding anyway. The disadvantage of this approach is that I would have to recreate code from the original game’s 6502 assembly code or through observed behaviour through gameplay.

I’d welcome your thoughts or any other ideas you have that I haven’t mentioned.

My Commodore 64 CRPG – August 2019 Update

Though I haven’t posted here on the blog since April, I’ve been busy working away on my Commodore 64 CRPG. Since I last posted I became a little side-tracked learning how to code certain things on the C64 as well as considering some different game styles.

At one point I was interested in creating some sort of CRPG / Adventure / Choose Your Own Adventure hybrid. I still like this idea but I eventually came back to the idea of doing a more traditional tile based CRPG – I think this is still my favourite style of CRPG although I was also tempted to go for an Alternate Reality or Bards Tale first person view – maybe next time!

I spent quite a lot of time experimenting with the various graphic modes on the C64, coding up examples thinking about their pros and cons which I’ve discussed here previously. I also worked out how to locate and reserve space for graphics and screen displays using CC65. This is the C programming environment for 8bit systems I’m using. It also includes a full assembler so I can freely mix my C and assembly language code as required in a single project. I’m only using it for the C64 currently, but it also supports platforms such as the Atari 8bit and Apple II machines. It’s taken me a bit of effort to get to grips with it but I’m enjoying working with it now.

I also spent some time using the tools in the C64 VICE emulator ( http://vice-emu.sourceforge.net/ ) and the CharPad software ( https://www.subchristsoftware.com/charpad.htm ) to analyse how some of the C64 games I liked worked and used the C64 to build their displays. Some like Alternate Reality use a mixture of modes with raster interrupts to split the screen, Ultima IV a single high-resolution bitmap screen and Legacy of the Ancients the C64’s character mode. As mentioned these can all make the game look different as well as provide different levels of flexibility, use of colour and use different amounts of memory.

In the end I’ve settled for using the C64’s character mode, initially with just high-resolution characters rather than multi-color mode. This mode allows you to display up to 256 unique characters on the screen at a time across the 1000 cells which make up the display (40 x 25 characters). Using CharPad these characters can be made up into tiles ( 2 x 2 in my case) and then used to build up a map. I can use all the C64’s 16 colours on the screen but I’m limited to a single colour on a common background for each screen location. I plan to get around the limited number of characters by loading in additional character sets for different regions.

CharPad – Showing characters, tiles and a map in progress

Using CharPad I can now export my characters, tiles and map into binary files which I’m loading into my C64 program. Currently the tiles are heavily Ultima influenced but I’ll try and make them more unique as time and my limited artistic skill allows! I also hope to make use of the C64’s sprites for characters and possibly encounters. On the C64 you are limited to 8 of these without more complicated sprite-multiplexing coding which I suspect may be a bit of a challenge for me. Next time I’ll tell you a bit more about the game as it currently stands and pose a few questions I’d like to get your thoughts on.

Moving around the map in my C64 CRPG

C64 Bitmap mode…or not?

I’ve been experimenting a little bit with the bitmap modes on the C64. As mentioned previously there are a choice of high resolution (320×200) or multi-color (160×200) bitmap modes on the C64. There are various pros and cons with these two bitmap modes as well as with using the other character based modes the C64 offers.

Bitmap mode – 2 colours per 8×8 pixel cell

Standard or high resolution bitmap mode shown above has the advantage of giving you the full 8×8 pixels per character cell on the screen but you are limited to only a single foreground and background colour in each 8×8 cell. A full screen uses 8K of memory plus 1K for the colour information.

Multi-color bitmap mode – 4 colours per 8×8 character cell

Multi-color bitmap mode has the advantage of allowing you to have up to 4 colours per 8×8 character cell (one of which is a shared background colour) but has the disadvantage of reducing the horizontal resolution in half, displaying double width pixels. It also uses 9K of memory in total but needs an extra 1K for the additional colour information.

Memory usage for both these modes could likely be reduced by 1-2K by using a split screen mode with a text display at the bottom – think Ultima 2 or any of the many graphic adventure games of the 1980s. Many C64 games used a split screen like this to mix modes on a single screen, saving memory and improving display speed.

My initial tests with these bitmap modes are proving quite slow to display compared to my earlier character based version. This is hardly surprising as drawing a single 16×16 pixel tile on the screen will now involve writing at least 40 bytes to the display (characters and colour information) as opposed to just 8 bytes. I’ll give it some further thought and do some more drawing in the various modes before deciding to see if I feel the additional flexibility is worth the increased memory usage and reduction in speed.

C64 RPG Display Choices

An example of mixing multi-color and high-res characters on a single screen

Since my last post I’ve been experimenting with using the Commodore 64’s multi-color character mode. This mode allows you to display 4 different colours in each 8×8 pixel character cell but with the loss of horizontal resolution. Each “pixel” in multi-color mode is effectively made up of 2 horizontal pixels – this sometimes leads to the slightly “chunky” look of some C64 graphics in games. 1 colour is the background, 2 colours are set universally for each character using registers and the other comes from the C64’s screen colour RAM (one colour per character cell on screen).

A C64 multi-color character – Note the 4×8 “pixels” rather than 8×8

It’s possible to use a mixture of multi-color mode characters with standard high-res characters on a single screen. This is done by setting bit 3 of each character cell’s color memory – the value of this bit determines whether a character on the screen is in standard high-res mode or multi-color mode. The downside of this is that you have a more limited selection of colours. Colour values of 0-7 in the colour RAM will display a high res character, 8-15 a multi-color mode character. This means you can’t use colours 8-15 in your display other than as one of the 3 universal colours – so no light red, shades of gray, light green etc (colours on the right hand side below).

The C64’s 16 colour palette (taken from Pixcen)

I’ve done a bit of experimentation with Pixcen and produced a few sample multi-color tiles but it took me a while to understand how the colour limitations work and I find the loss of horizontal resolution hard to work with, and I have little artistic skill to start with! I also need to work out what my graphics development process is. Pixcen seems to be a good enough utility but I think there may be other tools which might suit me better. Some form of C64 graphic, tile and map editor might be required.

So I have a real balancing act to consider, deciding on whether to use multi-color mode (losing resolution and colour choice) or just stick to using high-res characters but having the limitation of a single colour per cell. I’m aware that I could use one of the C64’s bitmap modes which provides the programmer with control of individual on-screen pixels with greater colour flexibility but from what I’ve read that will use a lot of memory (8K just for the bitmap data) and would potentially be slower than using characters. Let me know your thoughts.