Work in progress: REALMS OF QUEST V

[R'zo]

The changes are good. Health status to the left of the name will be useful.

Yes, makes it easier to spot. Looking very nice.

[Ghislain]

The changes are good. Health status to the left of the name will be useful.

Yes, makes it easier to spot. Looking very nice.

Yea, I think I'll stick with this.

I also just programmed a feature where the settings for font, music on/off and the disk system are saved at the menu screen so that the player no longer has to set these manually every time they load the game.

[Ghislain]

Without the numbers to denote the player character slots, I put in a "." for when there is an empty slot. It's ubiquitous and noticeable enough.

[Ghislain]

A small milestone -- I finally transcribed the map I generated into a .txt file (in NotePad++). Now I can manipulate and finalize it before I convert it to the game program format.

[R'zo]

Looking nice. I can't wait to explore it.

[Ghislain]

The map is almost finished (99.9%). Here is how the entire 128*128 map looks like in VIC-20 graphics format:

(click to enlarge).

I will probably make some minor fixes and adjustments, but I'm pretty satisfied with this overall.

[Ghislain]

I worked on the routine that displays the map's surroundings based on the player's location on the map.

Hopefully, everything will look good once I test moving around the map. And I have to place the player icon in the middle of the map area as well.

[Ghislain]

I was playtesting my work so far on my real VIC-20 setup which is connected to a HD TV. I found that the multicolor tiles looked funny with the upscaling to HD, with some of the tiles being undiscernable. So I decided to add a feature where the player can choose between multicolor world map tiles and hi-res ones. I defined the latter a little bit bulkier so that the player who connects a VIC-20 to a modern HD TV would have an easier time to tell the tiles apart with this option.

The multicolor tiles do look fine in emulation and I am pretty sure they would also look fine on a CRT television (as I remember Realms III looking OK on CRT back in the day), so by making two distinct tilesets for overland maps, the player has more choice on how they'd like the game to look. The hi-res tilesets are presented against a black background which makes it more visible.

[Ghislain]

I decided to add unique portraits and a text description of each castle in the game. Here is one of them:

I'm also contemplating whether or not to allow saving the game anywhere. I was reading Jimmy Maher's latest blog post:

http://www.filfre.net/2017/05/the-view-from-the-trenches-or-some-deadly-sins-of-crpg-design/

Here Irby hits on one of the most fraught debates in CRPG design, stretching from the days of the original Wizardry to today: what should be the penalty for failure? There’s no question that the fact that you couldn’t save in the dungeon was one of the defining aspects of Wizardry, the game that did more than any other to popularize the budding genre in the very early 1980s. Exultant stories of escaping the dreaded Total Party Loss by the skin of one’s teeth come up again and again when you read about the game. Andrew Greenberg and Bob Woodhead, the designers of Wizardry, took a hard-line stance on the issue, insisting that the lack of an in-dungeon save function was fundamental to an experience they had carefully crafted. They went so far as to issue legal threats against third-party utilities designed to mitigate the danger.

I could easily take away the "save anywhere" feature that I'm implementing throughout the game, as well as having a "perma death" policy, but the problems with these is that players could easily save state in emulation for the former and the latter is difficult to do because this game will span multiple disk sides. I am admittedly not quite strong in CRPG story design -- I much prefer to emphasize and focus on game mechanics, but the article above does provide a lot of things to think about.

[Ghislain]

When traveling, there are spells that let help your party:

1. Light - lets you see in the dark areas of the dungeons
2. Detect Magic - lets you see magic traps in the dungeons
3. Invisibility - lets your party evade monster encounters while moving around
4. Wizard's Eye - lets you see secret doors in the dungeons
5. Find Traps - lets you see trap doors in the dungeons
6. Protection From Evil - lets you detect the enemy before you encounter them (so you can avoid getting attacked by surprise)
7. True Sight - basically combines light, detect magic, wizard's eye, find traps and protection from evil at the same time (everything except for invisibility)

In the example screenshot, the player cast the Light spell (which is unnecessary when traveling outdoors, but I just wanted to test my code. The most useful spells for traveling outdoor are invisiblity and protection from evil). These spells have a time limit so their effects eventually run out.

[R'zo]

I'm also contemplating whether or not to allow saving the game anywhere. I was reading Jimmy Maher's latest blog post:

http://www.filfre.net/2017/05/the-view-from-the-trenches-or-some-deadly-sins-of-crpg-design/

Here Irby hits on one of the most fraught debates in CRPG design, stretching from the days of the original Wizardry to today: what should be the penalty for failure? There’s no question that the fact that you couldn’t save in the dungeon was one of the defining aspects of Wizardry, the game that did more than any other to popularize the budding genre in the very early 1980s. Exultant stories of escaping the dreaded Total Party Loss by the skin of one’s teeth come up again and again when you read about the game. Andrew Greenberg and Bob Woodhead, the designers of Wizardry, took a hard-line stance on the issue, insisting that the lack of an in-dungeon save function was fundamental to an experience they had carefully crafted. They went so far as to issue legal threats against third-party utilities designed to mitigate the danger.

I could easily take away the "save anywhere" feature that I'm implementing throughout the game, as well as having a "perma death" policy, but the problems with these is that players could easily save state in emulation for the former and the latter is difficult to do because this game will span multiple disk sides. I am admittedly not quite strong in CRPG story design -- I much prefer to emphasize and focus on game mechanics, but the article above does provide a lot of things to think about.

As nicely convenient as it is in an rpg to save anywhere I would have to agree with the article. It does take away from the base challenge and atmosphere. When you enter a dungeon you know that "this is it, if I don't make it i'll have to do it all over again." You're more on edge, focused and determined to make it through.

That being said, it can often be a challenge in Roq just to make it to a dungeon with your party alive and well. I would suggest disabling saves only in the dungeons.

As far as save states are concerned, cheaters will cheat others will play by the rules of the game for the true intended game experience. I rarely use save states.

[Ghislain]

As nicely convenient as it is in an rpg to save anywhere I would have to agree with the article. It does take away from the base challenge and atmosphere. When you enter a dungeon you know that "this is it, if I don't make it i'll have to do it all over again." You're more on edge, focused and determined to make it through.

That being said, it can often be a challenge in Roq just to make it to a dungeon with your party alive and well. I would suggest disabling saves only in the dungeons.

As far as save states are concerned, cheaters will cheat others will play by the rules of the game for the true intended game experience. I rarely use save states.

I might keep the "save anywhere" feature but keep track of the number of saves the player makes while they play.

Started working on monster portraits now. 2 done -- only 137 more to go!

[Ghislain]

I created 4 more monster portraits. Instead of posting every single picture of them, I thought I'd provide a demo of the latest build. You can download it here:

https://sites.google.com/site/gdbsite50 ... ects=0&d=1

(You'll need a VIC-20 or VIC-20 emulator that runs in 32K expanded mode. You can start the demo by first loading the RQ5.BOOT file and then running it)

If you want to see the 6 monster portraits, just assemble a party in the castle , leave the castle to the outside world map, then choose 'Move' from the menu and press 'C' to go to the combat module. From there, you can cycle through the 6 monster portraits I created so far (by again pressing the 'C' key). I only need to make another 133 to complete the game's bestiary!

[Kakemoms]

Wow, this looks really amazing. I am looking soo forward to play this on a real Vic-20.

[Ghislain]

Wow, this looks really amazing. I am looking soo forward to play this on a real Vic-20.

Thanks. I can't wait to finish it. But I haven't gotten sick and tired of working on it yet because I'm now having fun making the monster images.

I just did 6 more today. Here is a sample screenshot of one of them:

It takes me between 15-45 minutes to produce one of these images; find an appropriate image on the web, manipulate it with GIMP and then use Mike's PGM Import to convert it to VIC-20 format. And that's not really that much time when you think about it. Considering how useful and productive this tool is, I'm surprised that many other projects have not used it to produce image content for their games. For Realms IV, I used PGM IMPORT MONO to produce about 100 black and white hi-res monster graphics.