Podcast

Happy new year!

If you haven’t heard it already, I strongly urge you to listen to episode 31 of the Spam Spam Spam Humbug podcast (http://podcast.ultimacodex.com/e/spam-spam-spam-humbug-31-the-dark-unknown/) which features Adam Burr talking about his Ultima-like tile-based cRPG: The Dark Unknown. Adam has made a heap of progress this year including a successful Kickstarter to provide new assets and art for the project. He’s also in with a good chance of picking up the 2015 Ultima Fan Project of the Year prize (http://ultimacodex.com/2016/01/vote-for-your-favourite-fan-project-of-2015/). I was particularly pleased to hear some positive feedback that also applies to some of the design choices I’ve made for U3.5. I also thought the questions were a pretty good generic set for anyone developing a game like this, so on that basis, if I’d been asked them about U3.5, here’s the short version of how I would have answered them.

What was the moment when you decided you wanted to make your game and what was the catalyst for that decision?

I had created my own 8-bit computer derived from the popular British microcomputer, the ZX Spectrum. I had even persuaded someone to add support for it to a popular cross-platform ZX Spectrum emulator. I wanted a game that would show off what it was capable of doing and I thought Ultima IV was a good fit. Somewhere down the line the plan changed to support the more commonly available but less powerful ZX Spectrum +2B and to do an original game rather than a port.

Was there an initial design document, and has the project exceeded your expectations of its initial scope?

There wasn’t what would commonly be thought of as a design document, just a lot of notes, although over time they have evolved to more closely match a traditional design doc. In terms of the scope, it’s entirely dictated by the hardware platform, the main limitations being RAM, the memory paging system, and the lack of a disk system. The advantage is there’s not much room for scope creep.

Were there specific design elements you wished to celebrate with respect to previous Ultima and Ultima-like games, and if so, why?

The top down view, because it lends itself to attribute-based graphics. The conversation system, because I also like text adventures. The fully realized dungeons from U5, because I also like dungeon crawlers. The music from the Apple ][ versions, because the Spectrum has an AY chip (as does the Mockingboard). The non-linearity and lack of a big boss from U4. The references to other episodes from Serpent Isle.

What are your favourite Ultimas?

Exodus, Quest of the Avatar and Serpent Isle.

Are there other early CRPG’s beside Ultima that have influenced your design and if so, how?

The early Ultimas are populated with real world and historical NPCs and I wanted to reflect that, while at the same time not make it quite so jarring to the player. Because U3 gave you the option to import parties from Bard’s Tale and Wizardry I got the idea that perhaps these games all inhabited a common universe.  But you’ll also meet characters from Bloodwych and Gauntlet, just because I happen to like those games. Bloodwych also contributed staircases to the dungeons which are used in place of ladders for practical reasons to do with the way U3.5 is coded.

What are your least favorite features from the early Ultimas and ones you are attempting to either improve on or completely avoid in your game?

Space travel, end of game bosses, per-party member food levels, reagents, shepherds, and schedules.

If you had limitless time and money, what features would you like to see added to your game?

Ports to other 8-bit platforms, including a Japanese version on the MSX.

What features that are not currently in the game are you planning to add?

I have a plan for what I think can be achieved on the hardware. It has some elements like a dating sub-game that I’m willing to cut out if the rest of the content overruns. Avoiding feature creep is essential to finish large scale projects.

What do you think it is about this particular class of RPG’s that makes them so memorable to people and what would you say to other gamers that may not give them a chance simply because the graphics look outdated or are not 3D?

The problem with photorealistic worlds is that they rob you of your imagination, which is infinitely better than anything even the best artist can come up with. It’s the reason text adventures are still popular. However, unless you were raised on these kinds of games when there weren’t any alternatives, it’s a hard sell.

Many would-be game developers have misconceptions about the actual time and resources it actually takes to finish even a 2D tile based RPG’s such as yours. It’s not hard to find countless other CRPG’s in this class that have been started by other passionate individuals, but that never get completed. Could you share some of the misconceptions you originally had about the development of your game and offer some practical advice to other game developers that may be thinking about embarking on a similar journey?

I think I actually avoided most of the misconceptions. Before I got going I’d read a blog on developing this kind of game for the TI99/4 and so I knew it was going to be a long slog. Here are some tips I’d offer:

  • Read Jason Gregory’s Game Engine Architecture.
  • Know your target platform(s) and design accordingly.
  • Don’t write your own engine unless there’s a really compelling reason to do so.
  • If you’re a lone coder, use Unity. If you have a team, use Unreal.
  • Use scripting for the game logic.
  • Write the plot first.
  • Use placeholders for as many assets as possible.
  • It’s ok to work on final versions of assets when coding is getting you down.
  • Involve the community.

What were some of the challenges you faced?

Predominantly the challenges were the constraints of the chosen platform. The other big challenge is just to keep going with it when it feels like it will never be finished.

What proved to be harder than expected (and/or easier than expected)?

I suspect the hardest bits are still ahead of me. Although it took quite a while to get it fully tested, the dungeon display system, which uses tiles and groups, was actually fairly easy to write.

After you complete Pax Britannia, what can we expect next from Zedex Dragon and Source Solutions?

I’ll be trying to encourage other people to use the ZXodus][Engine to create their own cRPGs. And I’m interested in doing something with virtual reality.

Creating a Game Engine

Apologies for the lack of development blog updates. Hopefully that’s going to change in 2016. I’ve now completed my first year as a video games industry insider and I’ve learned a lot that I hope to be able to apply to the development of my game engine and the Pax Britannia game. One book I read this year that has had a major influence on the project is Jason Gregory’s Game Engine Architecture which I wholeheartedly recommend to anyone looking to develop video games. One tool that is going to be invaluable in making the engine accessible to third-party developers is Bogdan Drozdowski’s asmdoc Perl script which uses JavaDoc style tags to generate API docs from assembly source. It’s CPU agnostic so it’s great for retro-projects. I’m also incredibly grateful to Klaus Jahn, author of many modules for the ZX Spectrum, who has graciously offered to write some asset processing tools for getting original content into the format used by the ZXodus][Engine. So where is development at? Well I’ve been doing the occasional bit of work on different parts of the project over the course of the year. The big announcement was getting the world map working, although I still haven’t hooked it up to the rendering engine. A minor update was the increase in the color resolution of the character generation screens (from 8×8 attributes to 8×2 attributes). Most of the work has gone into restructuring the source code to make it easier to manage. Along the way I added support for a devkit version of the target machine with an additional 32K ROM that can store debug code (invoked by an NMI switch). As neither this ROM not the NMI switch are present on the real machine, there’s no need to have separate debug and release builds. I’ve now been developing an Ultima-like game for seven years so I think it’s time I set a delivery date. And I have. But I’m not going to announce it, because allegedly 70% of projects that announce before they are complete never ship, and this one has already been announced so I don’t want to make things worse. I’ve also recovered a few stray bits of code that I wrote and then forgot to put in the main project folder. Which means I’m finally in a position to hook up the keyboard reading code to the screen printing code. When that’s done I’ll implement the talk system. And when that’s done the game should be playable from start to finish, because currently the “win” scenario of Pax Britannia can be achieved through talking alone. This has the added advantage that the story can be play tested while I work on other things (like an updated version of the character generator). So with that in mind I may actually be looking for play testers at some point next year. However, I want to keep the number small, because although those players will be getting early access to the full plot, it will be an entirely text based experience and potentially much less rewarding than the final fully polished version. But if you want to register your interest, please do so.

The Map Scrolls

That is to say I’ve written the code to grab the current 32×32 area of the 128×128 world map that the player is standing in and display a 9×9 area of that as the viewport. This means wherever the player is, it will be possible to display a 32×32 area map. And the map loops nicely at the edges. Now where did I put that bag of gems of peering?

RedBox SDK updated

Had a go at getting part of the ZXodus][Engine to run as part of a script in ZX BASIC (the scripting language used by the engine). Against all expectations it worked first time. I’ve added the latest development version of ZX BASIC to the RedBox SDK. RedBox is a WINE wrapper for the set of tools that are used to create assets and compile binaries for the ZXodus][Engine. Currently it’s Mac only until I find a way to build a Linux version. WINE doesn’t run on Windows, so there you have to install the tools separately. I’m now working on the next version of the character generator. When that’s done I’ll be able to re-use a fair amount of the code on the script engine.

[Edit] Well Apple has changed the underlying OS again and broken RedBox. Development is now moving to Windows.

Another failed test print

Tried some thinner paper which is supposed to be suitable for laser. Well it’s only coated on one side and the other side won’t hold the toner. So it looks like I have two choices for the Player Reference Card: I can either buy an inkjet printer, or I can get the cards commercially printed. Given what a short run it’s going to be I think buying an inkjet might be cheaper.

Tools

Over on the links page I’ve highlighted some of the tools I’m using. However, when I started my original project to port Ultima IV to the Chloe 280SE, many of these tools didn’t exist. So I wrote my own, or adapted what I could find.

showscreen.cgi

Written in 1996, TrueFONT was my first foray into assembly language. Most of it was written in compiled BASIC, but I didn’t want to drop back to BASIC to handle loading and saving, so I wrote some code to do that directly. I still use it from time to time, but now I mostly use Klaus Jahn’s FZX font editor. FZX is a proportional font format for 8-bits that I came up with. Unlike most 8-bit font systems, it supports kerning. But it was overkill for the ZXodus][Engine.

showscreen-1.cgi

For Spectrum graphics I’ve been using The Artist 2 since I got it in the 1980s. However, I ended up hacking it to suit my needs and eventually released my patched version as The Artist 3.

showscreen.cgi

Before I wrote the tile engine, I needed some tiles, so I wrote a tile editor, again in compiled BASIC. It’s slow and clunky, and only runs on the Timex TC2048 (using hardware 8×1 attribute mode). But it does let you see the bitmap without the color, which you can’t currently do with ZX Paintbrush. The ColorTILE format that I created for ZXU4 has now been used in several other engines.

View window

printing

I’ve slightly modified the view window so that the text has at least a one pixel gap around it. I also had to change the moon and direction windows to make it easier to clear before printing to them. There is a small amount of attribute clash (or color bleed if you prefer) but I think it’s acceptable.

Window cleaning

As the text display is XORed with the background, I needed some code to clear the area the text is written to. This is now complete for the moon phase, wind direction, roster, status bar, and console windows. I’m not sure if I’ll want to put text in the view window so I’ve left that for now. Now I just need to integrate the y-position lookup for those windows and I will be able to print to any area of the screen. With a slight update to the character set I’ll also be able to do inverted text by overprinting a block character.