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

CRPG Visuals – My thoughts

One of the challenges of creating a CRPG for the Commodore 64 is deciding what sort of visual style I would like for the game. I’m working with an overhead view as I think that plays well to the C64’s capabilities and I’m a big fan of top down games such as the Ultima series and Legacy of the Ancients.

Ultima IV on the C64

Whilst my options with the C64 are more limited than modern machines, I still have many decisions to make on the visuals front (putting aside my lack of artistic talent for a moment).

The C64 has a number of display modes with a maximum screen resolution of 320 x 200 pixels (or 40 x 25 character cells) in a choice of 16 colours. If I’m willing to sacrifice the horizontal resolution of the display then I can increase the number of colours I can use in each 8 x 8 pixel “character” cell from 2 colours to 4 colours but this will double the horizontal size of each “pixel”. You can see this in the image below. You also have the choice of bitmap versus character modes. This is a big over simplification of the capabilities of the machine but will hopefully suffice for this post.

Gauntlet on the C64 – Illustrating the use of multi-colour mode (image from MobyGames)

Currently I’m using character mode to redefine the 256 character set with my own characters and then piece them together to build up maps on the screen. The player moves around the map and can move to other map sections when the end of the current map is reached.

If I required more colour in each character cell I could use multi-colour mode but this tends to make the graphics look more “chunky”. If I require more detailed graphics then I could use bitmap mode but at the cost of additional memory (8Kb for a full 320×200 screen).

One of the other challenges I’m facing is trying to make interesting displays with individual character cells which are only 8 x 8 pixels wide. Now the Ultima games and most CRPGs of the 1980’s typically used 4 character cells to build each of it’s map tiles, doubling the resolution of each tile but halving the number of tiles you can display on screen. The Ultima display also kept the party icon centred in the map display with the map being redrawn around the player after every move.

Combat in Ultima IV illustrating the use of 16 x 16 pixel tiles

One of the things I like about using the individual characters as tiles rather than 2 x 2 characters per tile, is that it allows me to display more of the map on screen at a time but at the loss of some graphical detail. I’ve started playing around with some of the redefined characters and colours in the CBM PRG Studio screen editor which is great for creating simple graphics and prototyping screen displays. Programming single characters as tiles is also a lot easier for me as well and will perform more smoothly in play.

Playing around with some redefined characters and colours to build an on-screen map

I’ve included a sample image above of my brief sketches so far. Regardless of what screen mode and tile size I eventually use I’m also likely going to use the C64’s sprites as a means of adding higher resolution images for the player character, NPCs and monsters. These have the benefit of being independent of the screen display so can have their own colours, hires or multi-colour mode option so can be used to add some further interest to the display.

Creating a Commodore 64 CRPG in 2019

At the age of 11 I became the proud owner of a Commodore 64 home computer and before long, started to draw out dozens of game designs on paper. Whilst I wrote some initial BASIC coding for many of these, it usually wasn’t long before I hit some roadblock and moved onto the next idea. Many years later the Commodore 64 was sold but it kept a special place in my heart and my desire to create a game for the computer never really went away.

Roll on 2019 and I received a C64 Mini as a Christmas present. Opinions vary on this system but personally I think it’s a great recreation of the system, especially since the firmware has been updated to allow the use of the thousands of disk images available online via a USB stick.

I had been playing around with the CC65 C cross compiler for a number of months. This allows you to write C code which can then be cross compiled to a Commodore 64 executable. Whilst I thought this was great in many ways my C code wasn’t as fast as I expected it to be and I struggled to understand how to deal with some of the memory management that CC65 requires. It just didn’t feel the same as programming the C64 with its original BASIC or with machine code (which I’ve dabbled briefly with).

I made a decision to switch over to the CBM PRG Studio which I found to have a number of nice features built in including support for BASIC and assembly language programming, character set editor and a screen editor as well as many others.

The map using some redefined, thinner lines for the City walls

Much to my delight I was able to fairly quickly put together a machine code program and gradually add to it – displaying a map on the screen, reading the keyboard, moving a player character around the map and redefining the default character set. I also found that my code ran very quickly – amazingly so compared to my BASIC programming I did about a year ago. My map below displays in an instant whereas my BASIC program took more than a minute to display and colour a smaller map. Most importantly of all I’m having a lot of fun putting this together.

The game running with the thicker walls, making use of some of the C64’s built-in characters

The game itself is not a million miles away from one of those early C64 games I started writing all those years ago. It currently presents a map of a City which you can move around exploring various locations (above and below ground). Currently the game is set on a single 40×20 “cell” map but I may expand the City map to flip to another 40×20 section when the map border is reached. The player is currently shown on the map as an @ – as in a roguelike game. I’ll work on some more interesting graphics and visuals once I have some more gameplay features implemented.

I’ll shortly be adding some characters, places to visit and items but I’m pleased with the progress I’m making and I’ve managed to sort out all my assembly challenges to date without too much pain, though it’s a very different way of coding for someone who is more familiar with C or C++. Content wise don’t be too surprised if there is a bit of Ultima or Alternate Reality type inspiration in the game. It’s very straightforward to play C64 games on a modern PC using an emulator like Vice so accessibility for players isn’t really a concern for me just now. The game is still in its early stages but I have a good idea in my head where I want to go with it next.