The Vic-20 Point and Click Adventure Engine

February 24, 2010 at 6:31 pm | Posted in Uncategorized | Leave a comment

For a little over a month my active project has been to build an engine that will allow the easy creation of point and click adventures for the Commodore Vic-20.  The concept for this project began back in May when I began work on a little game I call “Castle Rex”.  Back then my skills in 6502 assembly were nothing like they are now (not saying they’re all that great now).  Heck, when I started, I never even used the indirect Y indexed address mode.  I just always simulated it with self-modifying code simply because I never cared to learn about it!

So, after about 6 months of working on Castle Rex, I got very discouraged because the system was designed very poorly.  Every room had to have its own machine language routines to handle the player’s actions.  I had tried to make it work with unexpanded memory, but the quality of the project was just horrible compared to what I could have done with just 8 or 16 k of extra RAM.  I was so discouraged that I basically gave up the project.  For all of November and most of December I ignored it.

Finally, in late December I released a small (and crappy) Christmas demo on the Denial forums.  The second effect was involved a 16×16 bitmap screen.  A very active and intelligent member of the forums, Mike, suggested that I set up the bitmap with the data mapping down the  y axis instead of how the C64 handles it (going across the x).  Soon after, he PM’d me asking if the suggestions he had made regarding bitmap graphics would be used in Castle Rex.  At this point I had been playing around with redesigning the game from the ground up.  With this question, I decided that I would. A few PM’s later and Mike had steered me in the direction that I am now heading.  Major improvements to the design include:

• bitmap graphics.  These allow 40 column text, smooth sprites, and of course detailed room design
• BASIC “scripting”.  With this rooms will be able to be designed flexibly and without the rigidness of ML
• RAM expansion.  Considering the added features it is quite clear why this is necessary.

So now, it’s been almost two months and things are starting to come together.  The first thing implemented were the bitmap graphics because it is the basis for everything that happens graphically on the screen.  This was no challenge.  The screen is set up as a MINIGRAFIK screen is, which allows rooms to be designed in the outstanding MINIPAINT program and used in the game.

The next thing implemented was software sprites.  This is what most of my time was spent on.  The original software sprite routines I wrote worked, but were tragically slow.  In fact, drawing the sprite pixel-by-pixel with the pixel setting routines I made would have been faster than the way I did it (seriously).  I was going to ignore this and optimize later, but I couldn’t let myself.  So, the new routines are reasonably fast.  I’m sure there are better ways out there that wouldn’t have been too much trouble to implement, but what fun would that be?

After the sprite routines were done, I implemented the 40 column text drawing code that Mike provided me.  I’m really thankful for that because I really didn’t care to write my own printing routines.

Next, I moved onto the low-resolution event map handling.  It works like this: there is a map of bytes corresponding to the character locations on the screen.  For each 16×8 pixel rectangle, there is one byte.  If the byte is zero, it means that no event will be triggered if the corresponding screen location is clicked.  If it is not zero, the value will be returned to BASIC, where it will be decided what should be done.  Zero is returned to BASIC also, so any number could represent “no event”, but 0 works best with BASIC’s “ON” statement.  Besides, it just makes sense.

And right now I’m working on the menu and inventory systems.  Right now they are in quite early stages, but they’re getting there.. Slowly but surely.

After the menu and inventory system get to acceptable stages, the next step will be to figure out what BASIC needs access to and make a jump table to give access to it.  A fixed-address jump table will allow games built with an older version of the adventure engine to be updated to a newer version very easily should bugs ever arise.

Well, that’s about it for now! 🙂  Screenshots and a demo room next update.