*ALL PHYSICAL COPIES ARE SOLD OUT*: REALMS OF QUEST V (Digital version is available)

Discussion, Reviews & High-scores

Moderator: Moderators

User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Re: Work in progress: REALMS OF QUEST V

Post by Ghislain »

Thanks all. It's coming along, but it feels like I am progressing at a snail's pace.

I've come up with a framework of how the world map is going to look like. I originally wanted the world map to be as big or bigger than Ultima IV but decided to just make it about 1/4 of the size -- 128*128 tiles. The reason for this is that I want to avoid as much disk swapping as possible when the player is traveling about with a single disk drive setup. If the map were bigger then you could have a scenario where a player travels and then when there is a monster encounter, I want to avoid disk swapping between the monster disk and the map disk.

So the 128*128 world map will be loaded in memory location $A000 and each tile will use 4 bits (a nibble). Nibble values 0 through 14 will have terrain data and value 15 will denote a special unique tile (for city, dungeon, tower, graveyard, etc) and a special checksum based on the player location will allow the game program to lookup what is going to be displayed there (almost like a hash table).

Because the world map will be stored on 8K of memory, it will be simple enough to store it on all 4 sides of the game disks and then load it into memory location $A000 as needed. The map will still be 4 times bigger than the one in Realms III and the player can still enter dungeons, cities, graveyards, towers and all sorts of other areas with 64*64 tile mini-maps. As well, I'll be re-using Mike's most excellent raster routine that he kindly provided to show a diverse amount of multicolor graphics while the player explores the world map.

So I used this online tool to generate a world map:

http://donjon.bin.sh

After a few tries, I finally found something that I liked and envisioned.

And I am using GIMP to show it in a 128*128 grid:
realms5.jpg
And using a text editor to convert the map by hand into a text file so that I can easily manipulate it in a spreadsheet and finally convert it to VIC-20 source code.
realms6.jpg
I would have loved to make a map just as big as Ultima IV, but in the end it's not a major issue if It doesn't have it. Because of the vast number of monsters (at least 150 or more), almost the entirety of a disk side has to be used to store the monster graphics and data--so I had to choose whether I wanted more monster graphics at the expense of a more compact world map (Ultima IV's monster graphics can co-exist on the same disk side as it's world map). And even if the map is smaller than I what I originally wanted, it's basically just an abstraction of what the world looks like. The greater fun is exploring the cities, dungeons and the like. And there will be a lot of these.

Of course, somebody could say that I don't have to support a single disk drive setup -- that the game should just run on 2 disk drives or an SD card or even a special cartridge. But because this is a retrogaming project, I will want to support the "legacy" platform for a VIC-20 user who has a single disk drive (albeit with 32K of memory expansion!). And producing cartridges for a published retro title does also limit the number that will be produced. Distributing the game on physical media like floppy disks makes it more accessible.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Work in progress: REALMS OF QUEST V

Post by Kakemoms »

I have been looking into other programming routines in which I specifically make tables for drawing. I found that there are a number of ways to compress data, but found this one efficient;
Lets say you have a 256*256 map with x bitplanes depth. Now, instead of storing the whole plane, I tend to build each bitplane out of contineous lines. You can then draw any line that spawns the full map using only 256 bits (plus starting point). Its a different way to store the map data (e.g. through lots of lines), but its alot more efficient for some things. You can do lots of things like grouping lines at specific lengths, widths or use them as terrain seeds (for example mountain ridge).

Anyway; in this way your map isn't limited in size the same way and you can make it alot larger.
User avatar
R'zo
Vic 20 Nerd
Posts: 514
Joined: Fri Jan 16, 2015 11:48 pm

Re: Work in progress: REALMS OF QUEST V

Post by R'zo »

Looking awesome! With every update this is looking more and more like the rpg i've been dreaming of playing for a long time. I really enjoy three and this is adding on top all the extra detail and game play features that I would like to see. Since I started messing around with the vic i've felt it is such a perfect system for rpgs and that there werected simply not enough produced
For it. Keep up the great work.

The map is looking very nice. I can't wait to explore it! Size here I feel matters very little. Awesome dungeons, cities and a sweet battle system are what make for good rpg play, the world map is just a way to transport the player between the above mentioned. I think all of our games start out much bigger in our head than the finished product. We have to make sacrifices along the way during coding in order to make the game fit into system we're writing it for. Choosing carefully what is important to game play and what is not is often a difficult task.

Personally i'm a vic fanatic because of it's limitations. So many newer games have so much put into graphics, speed and technicalities that yes the game may look awesome but seems to be lacking in gameplay. What you end up with are a bunch of extremely fancy button mashers. In short I have been uninpressed by most of the gameplay offered in newer systems. When your writing for a system as limited as the vic is you can't rely on fancy graphics, sound or huge memory or processing speed to draw the player in. You have to be creative and really put some thought and effort into the gameplay itself in order to make the game enjoyable to the player.
R'zo
I do not believe in obsolete...
User avatar
rubygolem
Vic 20 Drifter
Posts: 29
Joined: Fri Mar 28, 2014 5:17 pm

Re: Work in progress: REALMS OF QUEST V

Post by rubygolem »

orion70 wrote:Rubygolem, can't wait to see your blog updated with entries dedicated to this new incarnation of the RoQ saga :) .
Thanks. I can't wait to try out RoQV myself and I'll be sure to write up some new adventuring stories when the time comes. 8)
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Re: Work in progress: REALMS OF QUEST V

Post by Ghislain »

Kakemoms wrote:I have been looking into other programming routines in which I specifically make tables for drawing. I found that there are a number of ways to compress data, but found this one efficient;
Lets say you have a 256*256 map with x bitplanes depth. Now, instead of storing the whole plane, I tend to build each bitplane out of contineous lines. You can then draw any line that spawns the full map using only 256 bits (plus starting point). Its a different way to store the map data (e.g. through lots of lines), but its alot more efficient for some things. You can do lots of things like grouping lines at specific lengths, widths or use them as terrain seeds (for example mountain ridge).

Anyway; in this way your map isn't limited in size the same way and you can make it alot larger.
Interesting. So would the resultant map be calculated (like Telengard or even Realms of Quest II) or would an algorithm be used to populate an area of memory? Minima from the Minigame Competition for the C64 is 2K, but it's map generating algorithm populates the available RAM to produce it's map.

The map I am working on is more or less compressed already -- you can store 2 tiles per byte of RAM. And I'll be using lookup tables for unique tiles so that there is more than 16 available tiles available to be displayed.
Last edited by Ghislain on Fri Apr 07, 2017 4:27 pm, edited 1 time in total.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Re: Work in progress: REALMS OF QUEST V

Post by Ghislain »

R'zo wrote:Looking awesome! With every update this is looking more and more like the rpg i've been dreaming of playing for a long time. I really enjoy three and this is adding on top all the extra detail and game play features that I would like to see. Since I started messing around with the vic i've felt it is such a perfect system for rpgs and that there werected simply not enough produced
For it. Keep up the great work.

The map is looking very nice. I can't wait to explore it! Size here I feel matters very little. Awesome dungeons, cities and a sweet battle system are what make for good rpg play, the world map is just a way to transport the player between the above mentioned. I think all of our games start out much bigger in our head than the finished product. We have to make sacrifices along the way during coding in order to make the game fit into system we're writing it for. Choosing carefully what is important to game play and what is not is often a difficult task.

Personally i'm a vic fanatic because of it's limitations. So many newer games have so much put into graphics, speed and technicalities that yes the game may look awesome but seems to be lacking in gameplay. What you end up with are a bunch of extremely fancy button mashers. In short I have been uninpressed by most of the gameplay offered in newer systems. When your writing for a system as limited as the vic is you can't rely on fancy graphics, sound or huge memory or processing speed to draw the player in. You have to be creative and really put some thought and effort into the gameplay itself in order to make the game enjoyable to the player.
Thanks. This is also the RPG I always wanted to make and play. And the VIC-20 has been largely underserved as far as RPGs go.

The work on the world map continues, but work is very slow. I think 128*128 tiles will be enough once I have the map designed entirely by hand. I only have 23% of it done so far.
realms5.jpg
realms6.jpg
Designing the cities by hand should be a lot easier I don't have to meticulously go over the terrain details like I have to with this one.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Work in progress: REALMS OF QUEST V

Post by Kakemoms »

Ghislain wrote:Interesting. So would the resultant map be calculated (like Telengard or even Realms of Quest II) or would an algorithm be used to populate an area of memory? Minima from the Minigame Competition for the C64 is 2K, but it's map generating algorithm populates the available RAM to produce it's map.

The map I am working on is more or less compressed already -- you can store 2 tiles per byte of RAM. And I'll be using lookup tables for unique tiles so that there is more than 16 available tiles available to be displayed.
The idea is to calculate the map or parts of it at runtime, so you don't need to store all the tiles. Maybe I will try to generate a terrain generator at a future date to demonstrate the principle. Use lines for putting down most of the features, then smooth out for a more gradual terrain. Lowest level can be defined as water.. and so on..

You are probably better off with your compressed map. This is basically an idea in the making. :roll:
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Re: Work in progress: REALMS OF QUEST V

Post by Ghislain »

Kakemoms wrote:The idea is to calculate the map or parts of it at runtime, so you don't need to store all the tiles. Maybe I will try to generate a terrain generator at a future date to demonstrate the principle. Use lines for putting down most of the features, then smooth out for a more gradual terrain. Lowest level can be defined as water.. and so on..

You are probably better off with your compressed map. This is basically an idea in the making. :roll:

Well in that case, we could find a random number seed that produces a map to my liking. And let's say the big map is 384 * 384 tiles of which 64*64 are calculated and stored in RAM at one time. I could pinpoint to specific areas where the cities, castles and dungeons will be.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Work in progress: REALMS OF QUEST V

Post by Kakemoms »

Ghislain wrote:
Kakemoms wrote:The idea is to calculate the map or parts of it at runtime, so you don't need to store all the tiles. Maybe I will try to generate a terrain generator at a future date to demonstrate the principle. Use lines for putting down most of the features, then smooth out for a more gradual terrain. Lowest level can be defined as water.. and so on..

You are probably better off with your compressed map. This is basically an idea in the making. :roll:

Well in that case, we could find a random number seed that produces a map to my liking. And let's say the big map is 384 * 384 tiles of which 64*64 are calculated and stored in RAM at one time. I could pinpoint to specific areas where the cities, castles and dungeons will be.
Thought I had answered this.. probably forgot to press submit :lol:

Anyway, the generator in basic is veeery slow. 384*384 is going to take an age to generate. The plotting I can get into assembly quite easily, and that should plot quickly.

I have been looking into random number generation in assembly, but its still not really random. Now, the RND function in basic is quite poor at randomization too, so it may not make much difference. Another way would be to connect a NEOS mouse and use x-y input to randomize the generated code (while one continuously moves it).
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Re: Work in progress: REALMS OF QUEST V

Post by Ghislain »

Kakemoms wrote:Thought I had answered this.. probably forgot to press submit :lol:

Anyway, the generator in basic is veeery slow. 384*384 is going to take an age to generate. The plotting I can get into assembly quite easily, and that should plot quickly.

I have been looking into random number generation in assembly, but its still not really random. Now, the RND function in basic is quite poor at randomization too, so it may not make much difference. Another way would be to connect a NEOS mouse and use x-y input to randomize the generated code (while one continuously moves it).
Several months ago (as I was mulling over in my head how I would make this game), I envisioned storing a compressed 384*384 map on a single side of a disk. A byte would have tile information 0-31 (5 bits) and the other 3 bits would determine the number of times that the tile is repeated (1-8). So depending on how much repetition there is, you could compress the map by up to a factor of 8. the game would load the map data on an on-needed basis from disk.

But I scratched the idea for having such a large map altogether, largely because designing it would be so time consuming and I want to reduce disk swapping as much as possible (see my comments regarding supporting floppy disk users earlier in the thread). In fact, I only have a fraction of my 128*128 map done and it's the thing that's taken me the most time so far. I asked around if anybody was interested in designing a map by hand and putting the data in a spreadsheet, but nobody has the spare time.

It might be interesting to get a map generator that's able to output the data into a text file, however. Transcribing the stuff by hand is quite a meticulous process.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
R'zo
Vic 20 Nerd
Posts: 514
Joined: Fri Jan 16, 2015 11:48 pm

Re: Work in progress: REALMS OF QUEST V

Post by R'zo »

All of this is making me think of different ways to preduce a map. I once had an idea to do a dungeon map using single bits to produce tiles. Simply 1=wall 2=floor. I could do a 16 ×16 tile map (256 tiles ) in 32 bytes. Items, traps, treasures etc. would be generated by random processes or by being indepently addressed to the map. Using this method I would be able to map a pretty sizeable dungeon map consisting of several 16 by 16 tile rooms could be stored entirely in ram. This would allow for every unlocked door and opened treasure chest to be easily stored tracked, saved and loaded.

For some reason it never occurred to me to apply this concept to a world map. You can change the bits per tile ratio depending on the balance you desire between present tile variety and ram space usage. Cities, Castles and dungeon tiles can be independantly assressed alowing there locations to be constant . Things like trees, marshlands and waterfront are constantly changing so producing these by random seeds could produce a more realistic enviroment.

All of this is very inspiring. I may have to abandon the game i've been working on and release it as is so i can move on to the bigger things swirling around in my head.
R'zo
I do not believe in obsolete...
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: Work in progress: REALMS OF QUEST V

Post by Kakemoms »

Well, I have made a v0.1 alpha plotter in assembly (it generates a 64x64 tile map very fast). The problem is that I can't get it to integrate with the basic program thats generating the map.. some sort of bug.

Anyway, I will post the source here once its working.
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Re: Work in progress: REALMS OF QUEST V

Post by Ghislain »

Somebody suggested that they would like to have the ability to view the player character's portrait from the menu (and not just from the player creation portion of the game). I didn't want to implement it at first because the player portraits would all reside on side 1.

But I figure that since a large portion of the game (map traveling) does take place on side 1, I don't think it will be that difficult to offer this feature for the portions of the game that take place on side 1. As well, the game can always prompt the user to switch to side 1 if they insist on choosing the "View Pic" menu option.
realms5.jpg
I also plan on allowing the player to cast spells and use items (from within the castle) and I will also add another menu item: "Maximum" which will let the player view the maximum HP and SU units for the party members.
realms6.jpg
I took a break from the time consuming task of mapmaking to work on some code again. I was motivated to add the "View Pic" feature largely because I finally did some playtesting of my code on my real VIC-20 and I was constantly using the "Create" menu option just to look at the player portraits.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Re: Work in progress: REALMS OF QUEST V

Post by Ghislain »

So I am taking a break away from map design (the world map .txt file is about 35% complete right now) and started to program the spell casting portion of the game.
realms5.jpg
Of the 20KB I am reserving for the core module, I've used up about 16.7KB so far. I envision that I'll be close to 18.5KB once the spellcastsing portion is completed. And the only other thing left to program for the core is the "USE ITEM" part, and that will be just a few hundred bytes. I think I made a fairly good educated guess how much memory I would be needing for that.

To those of you who missed what I posted about the topic before, the core module handles common routines like loading files, displaying graphics, printing out the character sheet, arithmetic, casting spells, playing music -- anything that can be used by the modules that handle the game playing like traveling, exploring the maps, traversing dungeons and combat. I document each subroutine like I would in a modern programming context--explaining what registers or memory locations to pass and what values will be returned through ACC, X, Y or memory locations. It's basically the equivalent of a KERNAL.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Re: Work in progress: REALMS OF QUEST V

Post by Ghislain »

A milestone today -- I have a framework in place to program the spellcasting system. The first spelltype I programmed was the summon spell. In the following screenshots, the player casts FIND FAMILIAR to add a small animal/monster as an ally.
realms5.jpg
realms6.jpg
With an ally, the player can use it to make attacks in it's stead during combat. In the case above, there is a 1 in 4 chance that the pseudodragon will invoke FIRE which basically autohits an entire row of monsters for 1D3 damage.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Post Reply