Vecalabeth – Beta

The remaining fixes turned out to be something I could knock off in what was left of my lunch break. I tested it all last night, fixed a couple of other bugs I found and did a complete playthrough of the game. Having played through it, I changed my mind about the hit point reward when you leave a dungeon and put them back how it was. The game is definitely beatable anyway so I’m calling it done for now. I may revisit it at some point but I reckon I’ve achieved what I wanted when I set out. I’ll fix issues if anyone reports anything but right now I’m dubious as to whether anyone else will ever even play it. You can grab this latest version is at http://www.pixsoriginadventures.co.uk/Vecalabeth.rar as before.
Aside from a Vectrex, you’ll clearly need a Vectrex32 to run it which isn’t cheap and my port certainly isn’t worth that asking price on its own. It undoubtedly makes writing Vectrex games way, way easier than it would be otherwise so if you ever fancied creating a game of your own I’d certainly recommend picking one up. The BASIC variant it uses is still primitive but it’s no doubt a joyful experience compared to the alternative. I had quite a few issues with bugs when I first bought it but the updates since then have improved things no end. My overriding complaint is still the lack of emulation so that I have to load and run my code on real hardware all the time. Aside from the inconvenience, it seems like unnecessary wear and tear on an ever more valuable system. To compensate, I’ve been doing this oldschool and writing the code in a text editor (usually during my lunch) and then only running it when I’ve made decent progress. This isn’t how I prefer to code but it forces me into it.
If anyone does play Vecalabeth, please let me know how you get on. I think it’s a decent approximation of the original but I could do with some other opinions.

Vecalabeth Alpha – Version 2

I uploaded a new version of Vecalabeth yesterday (http://www.pixsoriginadventures.co.uk/Vecalabeth.rar) with some bug fixes and gameplay tweaks.

This version improves the flickering and more importantly fixes a good number of game-breaking bugs. I’ve played this one far enough to complete about half the quests on the easiest level without noticing any major problems. There are a few bugs I’m aware of which for my benefit as much as anyone else are:-

  • I still haven’t fixed invisible passages showing up from certain angles.
  • If you kill a carrion creeper the text goes off the screen
  • Monsters don’t attack you if you are stood on something (ladder/chest)
  • The menus are still a little fiddly – I may not do too much with these as it wasn’t really an issue when playing.
  • You will keep being told a quest is completed every time you kill the appropriate monster
  • Lucky number selection starts at 0 instead of 1

I went back and played the original Akalabeth again as a basis for comparison. There are clearly different versions of this as the usual Apple II version does not quite match the source code I’ve got or the code analysis. I was fairly certain I remembered it playing differently but it’s been years so I needed to go back and make sure. As such I’ve made some changes to make my version a bit more playable and bring it more in line with the later version:-

  • I’ve altered the dungeon generation to include empty blocks in the grid. Believe it or not, this would never happen with the original dungeon generator and it makes the dungeons much more open and playable. It is still possible in my latest version to not have paths through the dungeon but far less likely.
  • I’ve doubled the number of hit points awarded when exiting the dungeon. This feels much closer to the original to me and a whole lot fairer on the player.
  • On the earlier version, all the monsters for that level didn’t always spawn on each level. I’ve altered it so they are always on there somewhere. Best find a dead end to fight off the onslaught on those lower levels…
  • I’ve made traps about half as likely to be generated. They were a nightmare on the original version.

Another major difference in the later Akalabeth is the persistence of dungeon levels. i.e. they are the same when you go back. This didn’t happen on the original and I’m tempted to leave this alone on the Vectrex. I don’t have enough memory to store more than the one level at a time – I could try to save them to the cartridge but I’m going to leave as is at least for now. The random levels offer an easy way to compensate for potential dead ends if nothing else.

There are no doubt other little differences but this felt very close to playing the Akalabeth I remember at any rate. The current plan is to fix the bugs in the first list, play through the whole game to see if I can finish it and then if nothing else shows up, call it a beta and see if anyone else ever actually plays it. None of that will take too long so I should be done in the next few days.

Vecalabeth – Resurrection

Readers with good memories may recall that well over a year back I got hold of a Vectrex 32. This is effectively a mini computer on a cartridge that can be used to run BASIC programs on a Vectrex. My first thought was of course to port Akalabeth since all those line graphics are a perfect fit for a vector screen. Life soon got in the way and I managed all of about 3 brief sessions coding, much of which was spent learning the ropes. The ropes are now well and truly forgotten but it’s time this project got finished off so I intend to pick it up again until I at least have something playable. First, a look at where I actually got to.

1

Luckily, I never clear out my PC desktop and all the code is still sat there untouched since boxing day 2016. The last thing I was working on was the initial text/menus at the beginning of the game. You would imagine this would be quick and easy but placing text on the screen has to be done one line at a time with all the coordinates being set manually. It was a bit of a pain as I recall but I got further than I remembered with it. With no keyboard, the interface is going to be clunky but I’ve got all the text on screen for the shop and a currently broken means to select things to buy. I didn’t have any means to exit from this shop so I’ve added that in for the purposes of trying everything out.

3

In the time I did spend on this, I concentrated on the graphics since that is the fun part. The overhead world is pretty much all there. I’d created a random world builder for this based on the original code and can walk around it. I can’t go back into a shop or chat with Lord British as of yet. You can see where the idea for tile graphics in Ultima 1 might have come from in this section since it is effectively tile graphics in a 3×3 grid.

There was no means to enter a dungeon either as I’d just bypassed the dungeon code when adding the world map. I made some changes to fix this at which point things started breaking. A load of painful debugging later, I managed to figure it out (a shared variable name). This is the problem with picking up a project a year down the line especially in BASIC which I’m not used to. I am relearning my own code but you really need to have a clear picture of it in your head given just how unstructured the language is.

2

The dungeon is just a predefined array for now with one of each monster kicking around a load of corridors. The beauty of using vector graphics comes into play here as there is no actual 3D programming going on whatsoever. I simply have an array with scaling factors for each block in front of the player and a routine to draw any given object. I then apply the scaling factor when drawing the object to shrink the graphics by the appropriate amount to place it that many blocks away. The disadvantage of vector graphics comes in as well in that it can all get a bit flickery. As with the overhead map, all I can do is move around.

No doubt I’m forgetting something but my checklist to get a playable game is :-

  • Sort out dungeon generation.
  • Implement ladders, traps.
  • Get the player stats in place and inventory.
  • Get the monsters to move around and attack the player.
  • Implement combat.
  • Shops
  • Add in Lord British and the quests

The only job I’m not sure about how to tackle is the first one. I’m seriously tempted to bypass it altogether and just hardcode some levels.

Here’s a bit of video of Vecalabeth in action (and yes it really does buzz that much). The flickering is if anything worse in real life. It’s something I’m probably going to have to live with as the platform is even more limited than the Apple II was. I don’t reckon it’s looking too bad though. It moves faster than the original Apple II version ever did and is recognisably Akalabeth at the very least. Let’s see if I can make it actually playable over the next week.

Announcing Vecalabeth

I’ve been something of a fan of the Vectrex console ever since getting hold of one a few years back. The Vectrex was unique in the history of games consoles as it came with a built-in vector monitor. The pin sharp, glowing line graphics this produces are completely unlike the raster graphics we are all used to and give the console a timeless quality as far as I’m concerned. I’ve always fancied having a go at programming on one but never built up enough courage to take the plunge into the assembly coding that would be required. Thanks to a newly released cartridge, (the Vectrex32), I no longer need to.

img_20161016_183343

The Vectrex32 plugs into the Vectrex like any other cartridge. The difference is that it’s a 32 bit computer in its own right that takes over all the processing duties of the console. This means programs can now be written in BASIC instead of assembly and it vastly increases the processing power available. In addition, the cartridge can interface with terminal software on the PC via USB for easy debugging and copying the basic code over in the first place. Having spent a few hours playing around with it, it’s quite a neat system and it didn’t take long to get my first code up and running. I am finding that I need to stop each program running entirely before copying over my new version of the code every time otherwise I got file corruption trouble. This is slightly tiresome but not a major deal now I figured it out. The other snag with the Vectrex32 is that I need the real hardware to be able to try to run my code. I’d really hate to wear out my Vectrex and would prefer an emulator option in the long run.

Hopefully, the option to code in a high level language will produce a flood of new Vectrex games. I’m going to be giving it a go at least and the project I’m tackling is a reasonably faithful port of Akalabeth onto the platform all those line graphics were clearly meant for in the first place. How successful this will be is yet to be seen as there are still hardware limitations to deal with (mainly the number of lines and buttons). I thought I’d deal with the most difficult and interesting stuff first. I’ve built a single level 9×9 maze array to give me something to work with and set about getting the movement and graphics in place to wander around the level. This has proved considerably easier than I expected actually. You basically draw what’s on the left, middle, and right directly in front of the player, then scale it down a little and repeat, and just keep going scaling it down a little more for each grid of the map. No maths skills or understanding of 3D were needed whatsoever which is probably just as well.

Something you don’t realise about the Vectrex until you start programming on it, is that the lines are all effectively drawn with a virtual pen that you have to move around the screen in the code. This pen drifts a little with each move meaning that your lines don’t necessarily meet up despite having the same coordinates. I keep having to reset my pointer to the middle of the screen and draw things in chunks to get around this.

I only started this weekend and have got as far as being able to walk around the maze, go through doors and have drawn the graphics for a couple of monsters. The Vectrex can only really handle one monster at a time reliably or the cartridges 2K buffer runs out of space + the screen starts flickering with the pen not being able to keep up. This means the monsters in this version will be able to hide behind each other. I reckon with chests, trap doors, ladders, etc. they are much simpler graphics and it will be OK to show all of them at once.

I considered porting the code from the original Akalabeth since it was also written in BASIC but the two variants on BASIC looked far too different for this to be worthwhile. Instead, I’ve written everything from scratch so far other than borrowing the monster drawing code. Even this is quite different but I can still extract the coordinate numbers and scale them down a little to suit my needs. I may borrow some more of that code in the long run for maze generation and the like but I’m nowhere near that point yet. The next stage will be to finish implementing the graphics for all the different monsters and objects, then I’ll have a go at putting some actual gameplay in.

I’ll release the source code once there is something worthwhile to share. In the meanwhile, here’s a few screenshots of what it looks like so far, including a close up of the fearsome balron. You’ll never be able to get quite that close to it when I’m done as you shouldn’t really be able to occupy the same square.

img_20161016_183951 img_20161016_184031

img_20161016_184012