Bryce's Adventures

A Few Revisions and Recent Progress (VIC 20 point and click engine)

Let me start by updating everyone on the file format.  The file begins with the bitmap (at this point still uncompressed), from address $1100 to $1fff.  There are actually a few bytes at the end of the bitmap that I will find a use for at a later point.  After the bitmap, there are a bunch of zero-terminated arrays of pointers.  I haven’t actually implemented them yet, so order may change, but the pointers needed are:  all the BASIC related pointers (start of BASIC, start of arrays, start of variables, etc.), sprite pointers, string pointers, and object pointers.

In my last post (2 months ago to the day) I said that objects were structures of data.  Well, this has changed.  Objects now don’t actually contain the data.  They just contain the ID’s of their data.  For example, a “decoration” object contains the ID of its sprite and the ID of its string.  IDs were already a central part of the engine for sprite handling, so it made perfect sense to do it this way.  The advantage is that the object can be altered in BASIC just as easily as any other sprite or string.

In my last post I also said that the engine would support multi-color graphics.  It would be simple for me to implement this feature into the engine, but it is not so easy to support this feature in all of the editor’s procedures.  For this reason, I’ve decided to not worry about multi-color graphics.  The fact is, it is very difficult to produce nice mulit-color pictures on the Vic-20 anyway.

Okay, now to discuss progress that has been made.

There’s actually not a ton left to do before the engine can be tested in a relatively complete state.  I’ve created functions that will load all but the BASIC pointers to memory so that they can be handled by the rest of the engine.  Events are not correctly working yet, but I should mention that I’ve beefed up the system for event handling.  Sprites are now capable of triggering events.  This adds some complexity to event handling, but it shouldn’t cause any noticeable slowdown since events are not at all time critical.

Sprites now have transparency, which was a major flaw as of my last post.

I’m not sure when I started working on the editor, but I don’t think I had even begun as of March 9th.  It is now probably 60% the size of the entire engine, so that progress cannot be overlooked.  The editor is capable of producing sprites, strings, and events.  The event creator is the only one with serious flaws.  The string and sprite editors simply need polishing (lots of it I may add :)).

The latest feature of the engine I am currently working on is an exit map.  Anyone that’s played any of the MacVenture games (Shadowgate, Deja Vu, Uninvited) knows what I mean.  There’s a little map with squares that show areas that the player may move from their current position.  It makes movement a lot less frustrating and it’s a feature I’ve wanted to implement for a long time.  Right now I have all the display code done.  I still need to do the user interface and write an editor for it.

Hmm, that should be good for now.

Have a good summer!  Hopefully by the end I’ll have something to show! 😀

-Bryce

File Format Brainstorming

Okay, I lied.  There will be no demo level or screenshots just yet.  I’m not ready yet.

Instead I will be sharing my thought process for the design of the file format for the rooms in my adventure engine.  In order to keep compatibility between games and upgraded versions of the engine, it is important that the format is right the first time.

The item in the format will be the bitmap of the room.  This will be loaded at address $1000, and since it need not be relocated, it will allow for more room for the engine and the rest of the file buffer.  The bitmap will probably also include a window of text.  Not only does this save the  ~240 bytes that would otherwise be used for this text, but it also allows the bitmap to be loaded in a continuous manner (again, no relocation necessary).  The downside is that storing the text in a bitmap format takes eight times that RAM it would take to store it in ASCII format.  This will increase loading times substantially, but there is no other method if the screen is to be loaded directly to $1000.

After the bitmap, it makes sense to have the bitmap’s color memory.  This must be relocated because color memory is all the way up at $9400.  Color memory will take 210 bytes uncompressed.  I will definitely implement some form of compression.  Since each color location only takes a nybble of memory, this can easily be cut to 105 bytes.  Further compression may reduce this even more.  While I’m on the topic of color memory, I might as well explain a little bit about how colors should be used properly.

• The bitmap is either all hi-res or all multicolor.  This is to avoid flickering sprites, and sprites must use the same color-mode as the screen.
• The border color (by default) will determine the color of the cursor sprite.  This is more of a suggestion than a rule.  By keeping the cursor sprite the same color as the border all the other colors are open for the screen to be drawn with.  Two of which (auxiliary and background) have twice the number of colors available as the border.  Most importantly, it leaves the versatile color map alone.
• Sprites cannot (or at least should not) enter the menu.  The menu will always be drawn in hi-res mode to allow for 40 columns of text, so it is particularly catastrophic if the sprite that enters it expects multi-color color (as I expect most will).

Okay, so after the color memory, there will be a few arrays of the item and door structures.  This could take as little as two bytes, or a lot more.  The structures will contain data for the sprite that represents them (their appearance), an ID number, and a status byte that must be written somewhere (RAM or file- if a file then it must be loaded to RAM upon entering the room) to show the state of the item or door.  In the case of the item, a zero will mean the item is no longer in the room, nonzero will mean it is still there.  A zero for a door means it is open, while a nonzero number means it is closed.  If RAM gets tight, these bytes can be consolidated and represented by a single bit.

Finally, the BASIC “script” is loaded.  The BASIC pointers will also need to be readjusted since the “script” is not always located at the same place.  Any free room at the end of BASIC can be used for data used by BASIC for things like sprites.

Alright.  That’s it for now.  I’m almost done with the inventory system, so this is next on my agenda.  Maybe by April I’ll have that demo room ready.

The Vic-20 Point and Click Adventure Engine

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.