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

Discussion, Reviews & High-scores

Moderator: Moderators

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

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

Post by Ghislain »

The boxed edition of Realms of Quest V is available for pre-sale orders. Click here to order: https://doublesidedgames.com/shop/commo ... f-quest-v/.
realms-pre1.jpg
realms6.jpg
Realms of Quest V is a role-playing game for the Commodore VIC-20 that is influenced by classics from the 1980s such as Ultima, Wizardry, Bard’s Tale, Phantasie and Telengard.

To play the game you will need a 32k ram expander. Joystick is recommended, but not required.

Featuring:

Over 350 multicolor graphical images that depict the monsters, characters and scenery portraits
16 races, 16 classes, 2 genders and 3 alignments
A party can have up to 10 player characters, plus 10 summoned monsters.
An overland map that exceeds it’s predecessor by a factor of four!
20 Cities and 20 villages
Persons that you can talk to and interact with
20 mazes and dungeons to explore
100 hours of game time
PAL / NTSC compatible!

Game package contains:

Cardboard Box
Game on 2 floppies (4 sides!)
Extensive Instruction Manual
World map printed on cloth
Greater Rivaria Coin
Digital version (D64 and D81 versions included)

===============================================================================================================
I've been away from the online VIC-20 community for the past few years, but I have been mulling over what I'd like to do for a new Realms of Quest game. Some of the features that I have in mind are:

-32K RAM expansion required (lesser expansion modes will not be supported this time around)
-multiple disk sides (will play on a single disk drive, but to avoid excessive disk swapping the game works best on an SD card reader or 2 disk drives)
-hundreds of monster, character and scenery portraits (44*88 multicolor pixels)
-16 player races and 16 player classes
-A party can have up to 10 player characters (I think this would be a record for 8 bit RPGs)
-printed game manual and box
-game music
-possibly and overland map that exceeds the Ultima IV world in terms of size
-cities to explore and townspeople to talk to (possibly).

If pressed for time, I might just make it into another Dungeon crawler.

I've designed the game's font quite a long time ago, also designed icons to represent the alignment, sex, race, class and status of the character (see attached image).

I'm also hoping to delegate the graphics, music and even story writing tasks to others so I can completely focus on the aspects of programming and designing the game.
realms5.jpg
Last edited by Ghislain on Thu Dec 19, 2019 6:16 am, edited 11 times 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 »

Here is a rough mockup of how the game would look like. The upper left portion would display the map, dungeon view or image portrait of an encounter. The middle left portion would be reserved for spell effects for the party. The lower left portion would be for displaying the available commands. The section at the bottom would be for displaying text.

The right section shows the 10 player characters. Each PC has 6 icons that reprsent: Level-Up Status, Alignment, Sex, Race, Class, Status. These icons are useful for letting you know what each player does without having to look them up. The hit points will be color coded so that you'll know if they're at fully maximum or not. I also intend to have shortcut keys that let you see how many spell points each player has.

I will resize the VIC-20 screen to 23*26 characters so that everything can fit.
realms5.jpg
Last edited by Ghislain on Thu Feb 02, 2017 7:04 pm, edited 1 time in total.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
joshuadenmark
Big Mover
Posts: 1217
Joined: Sat Oct 23, 2010 11:32 am
Location: Fr-Havn, Denmark
Occupation: Service engineer

Re: Work in progress: REALMS OF QUEST V

Post by joshuadenmark »

Looking forward to seeing this, will be a perfect Christmas gift if you're distributing this on floppy :D
Kind regards, Peter.
____________________________________________________
In need of a wiki logon - PM me
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 »

I'm hoping that I'm done by the end of the year.

Does anybody know how I could find some resources for music composers and 8-bit graphic artists? There surely must be a forum where artists offer their services for retrogaming projects such as this.

I made slight modifcations to the custom character graphics -- mostly how the level-up status and the alignments are displayed. I also reorganized how the party is displayed on the screen -- now spell points are shown (in blue). It does look a bit crammed but I'll see how the game looks and feels as I go along with programming it. I think displaying as much information as possible on the screen will be very useful.
realms5.jpg
realms6.jpg
Last edited by Ghislain on Wed Feb 08, 2017 9:03 pm, edited 1 time in total.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Work in progress: REALMS OF QUEST V

Post by Mike »

Ghislain wrote:I'm also hoping to delegate the graphics, music and even story writing tasks to others
Does anybody know how I could find some resources for music composers and 8-bit graphic artists?
You can't do much wrong with Pixelation - there's even an own sub-forum to put job offers. :)

For music, you might take a look at chipmusic.org.
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 »

Mike wrote:
Ghislain wrote:I'm also hoping to delegate the graphics, music and even story writing tasks to others
Does anybody know how I could find some resources for music composers and 8-bit graphic artists?
You can't do much wrong with Pixelation - there's even an own sub-forum to put job offers. :)

For music, you might take a look at chipmusic.org.
Thanks. I'll create accounts there in a few weeks (once I've made siginificant progress) and see if there is anyone there willing to work pro bono.

Or maybe I can shell out the money and go all-out with a KickStarter project like these guys did:

https://www.kickstarter.com/projects/st ... mmodore-64
"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 »

Here are the 16 races and 16 classes for the game.
realms5.jpg
realms6.jpg
Alignment is going to play a crucial part of the game.
"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 »

If I don't locate an 8 bit artist, I can always just find images of monsters on the web and use this tool to convert them to C64 Koala Pad format:

https://alex.kazik.de/2/c64-converter/

So I'd take this image:
kobold2.jpg
kobold2.jpg (16.38 KiB) Viewed 31001 times
And perform the following steps:

1. Crop a portion of the image that I want
2. scale it to 44*88
3. Convert it to 4 color grayscale format
4. Paste that to the upper left corner of a blank 160*200 image space:
kobold.png
kobold.png (94.23 KiB) Viewed 31001 times
5. Then use the above mentioned online tool to produce this Koala Pad image:
kobold3.jpg
And then from there, it should be fairly easy to write a script to extract the 44*88 multicolor byte data to convert it to VIC-20 custom character format which I think would look like this:
kobold1.jpg
(obviously once I have the tool created to convert it to VIC-20 format, it will use the VIC-20's colors)

Perhaps there is a less cumbersome way to do this?
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: WIP: REALMS OF QUEST V

Post by Mike »

Perhaps there is a less cumbersome way to do this?
I use a similar toolset with the MG batch suite - for me there's no need to have the C64 as intermediary.

PGM IMPORT dithers straight from a 256 greyscales, 80x192 pixels *.pgm file to a 4 colour MG bitmap. For smaller pictures, I extend them to the sides with a uniform colour, as you do. Some care is necessary to get the pixel aspect ratio right: otherwise, the converts look squished.

As for extraction of bitmap data into a custom charset, you find an example here: VicShroom - My first Vic prod.
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Work in progress: REALMS OF QUEST V

Post by Mike »

In another matter: normally, the exterior border colour doubles as one of the multi-colour colour sources, as you know. That means you'd been "forced" to use yellow (or whatever border colour you might choose otherwise) as one of the colours in the upper left portion. The background colour shares the same issue - it is forced to black.

When you have settled on a given screen layout, I can provide you with a raster routine, which changes the VIC register to another combination of background and border colour, just within that upper left section. It will slow down execution of the main program a little bit, but you get some extra flexibility for the colours. :)

I assume the auxiliary colour will only be used within that upper left frame, so it shouldn't require that treatment (it wouldn't anyhow be possible to change two registers at once).

PAL and NTSC require different register settings for the VIC registers of horizontal and vertical alignment, also the routine needs to take both TV systems into account.
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 »

Mike wrote:In another matter: normally, the exterior border colour doubles as one of the multi-colour colour sources, as you know. That means you'd been "forced" to use yellow (or whatever border colour you might choose otherwise) as one of the colours in the upper left portion. The background colour shares the same issue - it is forced to black.

When you have settled on a given screen layout, I can provide you with a raster routine, which changes the VIC register to another combination of background and border colour, just within that upper left section. It will slow down execution of the main program a little bit, but you get some extra flexibility for the colours. :)

I assume the auxiliary colour will only be used within that upper left frame, so it shouldn't require that treatment (it wouldn't anyhow be possible to change two registers at once).

PAL and NTSC require different register settings for the VIC registers of horizontal and vertical alignment, also the routine needs to take both TV systems into account.
That sounds like a great idea. The image would occupy the 11*11 screen corner at the top left of the screen -- which is 44*88 multicolor pixels. So would your routine effectively only work for the first 11 chars at the top left for 88 scan lines? You're also changing the background color back to black after beam passes the 11th character, right?

I also plan to put music in the game -- will this raster routine still allow me to play music in the background?

Anyway, since I've already decided on the screen layout, I attach a D64 image where I quickly created basic programs (for both NTSC and PAL layouts) where the screen is resized to 23*26 characters (as well as repositioning the screen) along with displaying multicolor information (using ASCII character 166) at the top left corner of the screen. I explain everything in the REM statements.

Though the screen layout programs are written in BASIC, my intention is to write the game in ML.

Here is the D64 file containing my screen layout programs. You should make sure to run them with at least 8K expansion or more in the emulator.

https://sites.google.com/site/gdbsite50 ... 175e34baff

Thank you very much for offering to do this. I've always wanted to see how code for modifying VIC-I registers on the fly actually works.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Work in progress: REALMS OF QUEST V

Post by Mike »

Ghislain wrote:So would your routine effectively only work for the first 11 chars at the top left for 88 scan lines? You're also changing the background color back to black after beam passes the 11th character, right?
Exactly. Although, it will be necessary to make a small change to the screen *memory* layout, which however won't affect the visuals:

The changes to the VIC colour registers come into effect a single hires pixel delayed with respect to half-char boundaries. Without any precautions, that means the left-most pixel column of the top-left window still would appear with black as background and yellow as exterior border colour source. The (also delayed) change from the new colours back to black/yellow can easily be hidden by the border coloured frame characters in the middle.

To get rid of the single wrong-coloured pixel column, you can add another character column to the left, which is also filled with the frame characters. That character column then hides the change of the VIC register.

Effectively the screen would be 24x26, of which you'd use 23x26 as you planned, and the left-most character column helps to hide the delay within the VIC chip. It might also be helpful to simply the addressing within the text screen.

Just tell me, if you're o.k. with that and I will go and implement the routine with the adapted screen layout.

BTW - the frame character should be done in hires, with yellow as foreground colour - otherwise if done in multi-colour with %01010101 it would just inherit the same one-hires-pixel delay for the exterior border colour, and we would be no better off. If you plan to do effects with changing/flickering border and want the frame characters to follow suit, at least the 11 characters to the left and right of the top-left window need separate handling.

I also plan to put music in the game -- will this raster routine still allow me to play music in the background?
Yes. It's always possible to put an extra routine at the end of the raster processing. Note, however, the IRQ will be called 60 times per second on NTSC and 50 times per second on PAL, so the music routine needs to take that into account.
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 »

Mike wrote:The changes to the VIC colour registers come into effect a single hires pixel delayed with respect to half-char boundaries. Without any precautions, that means the left-most pixel column of the top-left window still would appear with black as background and yellow as exterior border colour source. The (also delayed) change from the new colours back to black/yellow can easily be hidden by the border coloured frame characters in the middle.

To get rid of the single wrong-coloured pixel column, you can add another character column to the left, which is also filled with the frame characters. That character column then hides the change of the VIC register.

Effectively the screen would be 24x26, of which you'd use 23x26 as you planned, and the left-most character column helps to hide the delay within the VIC chip. It might also be helpful to simply the addressing within the text screen.

Just tell me, if you're o.k. with that and I will go and implement the routine with the adapted screen layout.
That sounds great, let's go with that. Using the border frame characters (non-multicolor foreground block chars), you can hide the playing with the raster beam.

Questions:

1. Obviously this routine will only be used when displaying a portrait of a character, monster or a scene. This interrupt would be turned on and turned off as needed. Will verifying for this require more CPU cycles and thus you might need an extra border character of padding on the left (thus increasing the screen size to 25*26) ?

2. Did you want me to rewrite my screen layout programs to include the border character padding?
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Work in progress: REALMS OF QUEST V

Post by Mike »

Ghislain wrote:1. Obviously this routine will only be used when displaying a portrait of a character, monster or a scene. This interrupt would be turned on and turned off as needed. Will verifying for this require more CPU cycles and thus you might need an extra border character of padding on the left?
No, that's not the reason for the extra character - I suppose I have to elaborate further:

As I wrote - the colour change happens one hires pixel late with respect to half-character boundaries. Without any precautions, that'd mean I'd place the store to the VIC register $900F so, that the change is supposed to happen at the boundary of border to screen window. Alas, that will come into effect one pixel late - thus the left-most pixel column still appears with black as background and yellow as multi-colour colour source from the exterior border colour.

If I place the write to the colour register one CPU cycle earlier, it happens in the border. This solves the problem for a changed background colour, however now 3 hires pixels within the border will assume the new border colour, which originally was intended for use within the screen window only. :( (1 CPU cycle corresponds to 4 hires pixels)

That's the reason the colour change needs to be hidden by extra frame characters to the left of the top-left window. On the right, the frame characters already solve the issue for the change back to black as background and yellow as border.

At least those 11 frame characters to the left and to the right of the top-left window must be done in hires, with the "real" border colour as their foreground colour.

All other frame characters could be done in multi-colour and thus will inherit any change of the exterior border automatically *), in case you want to do effects with a flickering/changing border colour (say: red for danger). However, the foreground colour of the 2x11 characters to the left and right of the top-left window need to be changed manually along with the border colour.


To recap on this one: "This interrupt would be turned on and turned off as needed." - yes, you need use this routine only as necessary. Especially, during disk drive access, the raster routine might have problems keeping up a stable raster, and it should be deactivated during that time. The music routine should still be there - and while it might suffer from a few delays by the KERNAL I/O, it can remain active and keep the difference between 50 Hz on PAL and 60 Hz on NTSC.
2. Did you want me to rewrite my screen layout programs to include the border character padding?
You'll need take that new addressing into account at least.

Unfortunately, google requires a login, thus I'm anyway not able ATM, to download your disk image. It doesn't pose any problem though for me to write an own version of the screen layout - that will also feature the handling of the two types of frame character. :)


*) BTW - that's exactly how MINIPAINT produces the three windows in the main screen "floating" within the border colour. :mrgreen:
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 »

Mike wrote:
Ghislain wrote:1. Obviously this routine will only be used when displaying a portrait of a character, monster or a scene. This interrupt would be turned on and turned off as needed. Will verifying for this require more CPU cycles and thus you might need an extra border character of padding on the left?
No, that's not the reason for the extra character - I suppose I have to elaborate further:

As I wrote - the colour change happens one hires pixel late with respect to half-character boundaries. Without any precautions, that'd mean I'd place the store to the VIC register $900F so, that the change is supposed to happen at the boundary of border to screen window. Alas, that will come into effect one pixel late - thus the left-most pixel column still appears with black as background and yellow as multi-colour color source from the exterior border colour.
I understand this part. My question was along the lines of if I want to turn off this interrupt routine, say like this:

Code: Select all

verify_display_flag:
     LDA flag_display_routine					// How many CPU cycles will be used
     BNE modify_display_registers				// for these
     JMP play_music							// 3 lines?
     
modify_display_registers:
     // Do the background + border raster interrupt routine here
     // This I presume will be performed 88 times for all of the raster lines needed
     
play_music:
     // Play the music here
     
     RTS
Just wondering where the raster beam will be placed when "verify_display_flag" will be performed? Perhaps it will be well before it reaches the edge of the border of the first raster line anyhow.
2. Did you want me to rewrite my screen layout programs to include the border character padding?
You'll need take that new addressing into account at least.

Unfortunately, google requires a login, thus I'm anyway not able ATM, to download your disk image. It doesn't pose any problem though for me to write an own version of the screen layout - that will also feature the handling of the two types of frame character. :)


*) BTW - that's exactly how MINIPAINT produces the three windows in the main screen "floating" within the border colour. :mrgreen:
Just PM me your email address, and I can send you the D64 file. It's no problem for me to rewrite the screen layout program so you can jump right ahead to the really important stuff!

You are the VIC-I raster master! ;)
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Post Reply