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.

Alternate Reality X – Release 0.82 Available!

Alternate Reality X – Release 0.82 is now available for download from: www.crpgdev.com/downloads. This release focuses on fixing a number of bugs which players have reported following recent releases.

  • Fixed – Group encounter messages out of sync with their damage
  • Fixed – Group encounter attacks out of sequence
  • Fixed – Fixed encounters not updating correctly (e.g. ghost in Well Lit Area)
  • Fixed – Fixed encounters not leaving weapons or treasure
  • Fixed – City Smithy items selling for minus value at Dwarven Smithy
  • Fixed – Troll Tyrant / Goblin Lord – wrong monster types appearing
  • Fixed – Troll Tyrant / Goblin Lord – didn’t leave ring halves
  • Fixed – Guild names and locations not all correct in City
  • Fixed – Character indicator on large map not in correct position
  • Fixed – Legend on large map not aligned for different window sizes
  • Added – Mercenaries and Paladins Guilds now in City
  • Code – Spells moved into separate source files

 

The Challenges of Remaking Alternate Reality

Every so often I receive an email or a post complaining that I’ve done something “wrong” with my remake of Alternate Reality:The City and the Dungeon – I’m not talking about bug reports or unimplemented features but more about design decisions. I guess in some cases I’m not making the decisions they would make if they were remaking Alternate Reality. For everyone who thinks I’m not expanding the game enough someone else thinks it’s not faithful enough. I think I’m past the point where this bothers me now and I’m realistic enough to know that with a project like this you’ll never please everybody. Most ARX players have been incredibly positive and supportive (and not to mention patient). Their feedback is also constructive, useful and essential to developing my project further.  So I’ll take this opportunity to say thanks 🙂

I thought I would talk about some of the design choices I’ve made with Alternate Reality X, the challenges I’ve dealt with and why these are unique to the Alternate Reality series of games (released and planned). Looking back now I think Alternate Reality was always going to be one of the most difficult and complicated games to remake in comparison to the other CRPGs from the same time period. I’ll explain below why I think that’s the case.

I started what I now call Alternate Reality X way back in 2009. I’ve had breaks during those years and diversions where I’ve looked into other formats or technologies but I’m now settled on the current technology so to speak in terms of using SFML and C/C++. I’d played around with Alternate Reality before but this is the year I made the first iteration of what you see today.

My background with Alternate Reality began with the Dungeon which I received as a Christmas present one year for my Commodore 64. Once I’d managed to keep a character alive long enough to advance a couple of experience levels, obtained some better equipment and stumbled across a quest I was hooked and played it regularly until I carelessly wrote over the Dungeon game disk years later in my haste to create a new character disk. I still have the box, map and manual today.

 

 

When I got access to the internet (around 1995) one of the first things I found was The Original Alternate Reality Homepage at: http://www.eobet.com/alternate-reality/ (it had a different URL back then). This site had lots of information about the games, an extensive FAQ, screenshots, maps (below) and comments from the AR developers including Philip Price. It also led me to the AR Mailing List (which sadly now seems to be offline) which was a great source of information. I’d never played any version of the City though I was aware of it from magazine reviews I’d read back in the 1980s.

One of my early goals with Alternate Reality X was to allow the player to move seamlessly between the City and the Dungeon as originally envisaged by Philip Price.

Whilst they share many similarities the City and Dungeon scenarios are very different games in my opinion. Perhaps the biggest difference is in the combat system. The City has the concept of engaged and disengaged menus (pictured above) but this was replaced by a different system in the Dungeon consisting of options for surprising an encounter, Battle Options and a Transact menu. This was the system I opted for in ARX.

Many other elements are different between the two scenarios from encounter graphics and map style to the use of currency. I don’t think ARX feels like a totally consistent game yet but hopefully as I add features the two scenarios will feel more integrated.

I made a number of development decisions which I’ll try to summarise here:

  • Players can move freely between the City map and the first level of the Dungeon as I imagine was originally intended by Philip Price.
  • I removed the penalties for saving characters in both the City and the Dungeon and provided 10 save game slots.
  • I removed timing from combat – I might add it back in as an option in the future – if there is demand for it.
  • Guilds are set up with multiple “branches” in the City and Dungeon and guild bonuses can be picked up in the Dungeon as well as the City (providing a guild has a location in the Dungeon).
  • 8bit Dungeon-style guilds are used rather than the style that was added to the 16bit versions of the City.
  • I chose to use the Dungeon’s combat system and menus rather than the City’s engaged / disengaged menus.
  • I liked the Charm and Trick mechanics of the City and added them to the ARX Transact menu.
  • The City’s potion system (tasting, sipping etc) where you tried to identify one of over 50 potions was not present in the Dungeon but I liked it so have added it into ARX.
  • As the encounter graphics are very different in style and size I opted to use the Dungeon’s encounter graphics for better consistency between the two scenarios.
  • I expanded the City’s map format to use the Dungeon format which used more bytes to allow more wall and door types and a “special” byte for fixed encounters, messages and unique treasures.
  • The City used a degree of randomisation when creating monster stats but I opted for the Dungeon’s fixed stats. I did originally generate encounters differently between the two scenarios but I felt it would always make the game feel disjointed and inconsistent if for example an encounter with a thief in the City felt very different to one in the Dungeon.
  • The economy – there’s a big divide here with the City trading in coppers (running into the 10,000s) and the Dungeon using silver, gems and jewels. I’ve kept the original prices and currency for now but it’s very inconsistent and I’m not really happy with it.
  • Again for consistency I’ve for now settled on a single font (the Dungeon) and banner colour scheme (the City). Easily changed in the future if required.

Other considerations:

  • I’m not a professional programmer so I’ve reworked and refined code a lot and will continue to do so until the project is complete. In addition I’ve not always understood the longer term requirements for a feature until further down the line (e.g. custom objects created dynamically in game).
  • The Arena, Palace, Wilderness, Revelation and Destiny scenarios were never completed.
  • A variety of different versions of the game(s) exist across 8bit and 16bit platforms, many of which add further variety in terms of graphics, music and mechanics.
  • Less of a problem in the Dungeon but there are many areas of the City where features and locations were left for later patching.
  • There’s always the question of making the game authentic (in look and feel) versus an “upgrade” with better graphics and sound as well as new features.
  • Should I have treated the City and the Dungeon as two separate games with a compatible character save file? I even thought of developing them as two separate executables (or sets of datafiles).
  • I can possibly address some of the differences as game options and preferences but that does add to further development time. I’m considering this though 🙂

I cannot think of a single game or series of games that would have presented quite so many questions or difficult decisions as Alternate Reality. There are no right answers for many of these If you have a game or series of games in mind though please let me know as I’d love to hear about it.

In the meantime if you have an opinion about any of the above or a design preference I’m interested to hear it. Nothing in ARX is set in stone.

Alternate Reality X – Release 0.75 – Changes

With the public release of Alternate Reality X 0.75 looming for the end of September 2016 I thought I would talk a little bit about what you can expect to see, what I didn’t manage to add and my general approach to have the completed 1.0 release in your hands before the end of the year.

I had planned for this release to complete ALL the elements of the City and the Dungeon that I see as combat and encounter related. I didn’t achieve that for a number of good reasons but I did make some very significant steps that put the project in a much stronger position than it was in before. One of the big changes was to add all the remaining Dungeon monsters as to date only the Well Lit Area and Fixed Encounters had been added and to animate them all.

One major change which I had not committed myself to making was using the original 8bit Dungeon monster data directly from the binary files. I was previously using simple text files which whilst easy to update had numerous errors, lacked a lot of information from the real data and were prone to spoiling of the game / opportunity for cheating from players. In addition to this I had built up similar text files for weapons in the game – an amalgamation of weapons the player could buy, monster weapons and unique items you could stumble across (e.g. the Sword of the Adept).

One of the great features of Alternate Reality (the Dungeon at least) was that it had a very flexible system for customising monsters and items in the game. Many games at the time would have had fixed object sizes with no opportunity to modify those objects in game. The Dungeon in contrast allowed very rich items and monsters which contained a mixture of attribute data (name, bonus to hit, sharp damage) with effects (curses, give off light) and directly included 6502 (the processor used by the Atari 800, Commodore 64 and others) code. In game objects could also be dynamically created in game (clothing in the City) or modified through player actions (weapons having enchantments added at the Weapon Enchantress).

So after a lot of thought I made the decision to use the original binary data. Using some great information provided by Brian Herlihy a few years back, I replaced the original monster loader and also added in support for loading in all their weapons and attacks. These are stored as part of the monster data. This was a lot of work for me but once I had these changes working I felt it made an immediate improvement to the feel of the game as well as adding all those additional Dungeon monsters – about 50 in total. Thanks to Brian for this information without which these changes wouldn’t have been possible.

Another major change in this release was the introduction of properly timed / processor speed independent encounter animation. I had information on encounter animation from old emails from Jim Norris – thanks Jim! – so I used these to hopefully produce a fairly accurate recreation of the Dungeon encounter animations. As part of this work I totally rewrote the main encounter loop and the way that monster and player “turns” are taken during combat and how multiple opponents are dealt with. Monster attacks now use the proper attack descriptions (whomps, slashes, chokes etc), can hit multiple player body parts and can also knock the player to the ground.

Behind the scenes I re-organised some of the game code, introducing more source files to try and better segment and compartmentalise different code areas (e.g the actor source files refer to encounters, load in the binary data, create their weapons and attacks etc). All these changes meant a lot of knock on changes – some foreseen, others not. These took time to sort out. I’ve probably not caught all of these issues yet.

With the introduction of all the new Dungeon monsters and only limited new encounter art I took the decision to temporarily disable the new media options – these will be back in a future version. I also disabled the W command to force an encounter as it seemed to be a source of problems and encounter frequency checking has been re-written in this release to check regularly for new encounters. I had to tone this down a bit as encounters seemed to be happening back to back!

The other feature missing from this release is the ability to pick up monster weapons after combat. There was a very practical reason for this, namely that all monster weapons are now stored in a new format and location whilst the player inventory / object buffer in the game uses a totally different system. In order to allow for the custom weapons of the Dwarven Smithy and enchanted weapons from the Enchantress this system will need to be updated and this in turn will impact on all the existing shops where weapons, armour and clothing can be bought. This work will be the focus of the next release with addition of adding in the original item binary data from the Dungeon to introduce all those special objects into Alternate Reality X such as Trump Cards, Eyes, Wands and Horns. Trying to add these into release 0.75 would have added a lot longer to the development time and I was keen to have a release out before then.

In order to have the 1.0 release ready for the end of the year I have had to focus tightly on what needs to be finished and priority on the gaps that need the most work and will add the most to the game. This may mean that some of the extras will go on the back burner for the time being but I think it will be well worth it to have a complete, integrated City and Dungeon Alternate Reality world to explore! Hopefully these decisions make sense but as always I’d love to hear your thoughts. Watch out for release 0.75 coming very soon. Thanks.