[**Commercial Release Is Now Available**] Realms of Quest IV
Moderator: Moderators
-
- Vic 20 Hobbyist
- Posts: 129
- Joined: Sun Dec 26, 2010 1:51 pm
Looks great. I played a lot of realms of quest III, after it was released for free, and thought the combat was really sharp, and the dungeons had much more character than the previous installments. What bored me was the overworld. I played it enough to understand where the exploration lies, but but for a large part game, I didn't really feel like I was exploring the world, just dashing between a handful of towns.
Maybe a point distribution system instead of rolling. Less classic, but speeds starting a game, and with that many classes, there seems like there could be a lot of customisation.
Anyhow, this all looks great so far. I like the monsters in monochrome. Mood setting I think.
Maybe a point distribution system instead of rolling. Less classic, but speeds starting a game, and with that many classes, there seems like there could be a lot of customisation.
Anyhow, this all looks great so far. I like the monsters in monochrome. Mood setting I think.
Thanks. Well, there's not going to be an overworld in this one, the focus will be on a designed dungeon with all sorts of surprises--good and nasty.malcontent wrote:Looks great. I played a lot of realms of quest III, after it was released for free, and thought the combat was really sharp, and the dungeons had much more character than the previous installments. What bored me was the overworld. I played it enough to understand where the exploration lies, but but for a large part game, I didn't really feel like I was exploring the world, just dashing between a handful of towns.
Rolling characters is definitely going be in there. I can't imagine the game without it. Rolling a character for me is one of the most fun things about CRPGs.Maybe a point distribution system instead of rolling. Less classic, but speeds starting a game, and with that many classes, there seems like there could be a lot of customisation.
I hope it turns out good, it will definitely look and feel different than the previous. I'm not even sure if there's going to be music beyond the intro screen.Anyhow, this all looks great so far. I like the monsters in monochrome. Mood setting I think.
Last edited by Ghislain on Fri Apr 05, 2013 7:20 am, edited 1 time in total.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
-
- Vic 20 Hobbyist
- Posts: 129
- Joined: Sun Dec 26, 2010 1:51 pm
Ah, I see what you mean by Oubliette inspired. Would there be a menu town like wizardry? Or would you bump into NPCs that talk to you?Ghislain wrote:The focus will be on a designed dungeon with all sorts of surprises--good and nasty.
I used to play this old DOS rpg called Swords of Glass, where one very useful feature was that you could use some chalk to mark an "X" on the wall, sort of like leaving a trail of break crumbs behind. Something like that would rely on having persistent dungeons (I.E. having to make a copy of the game disk, and saving the state of dungeons)
Some spot sound effects could be effective, running water when standing near a fountain, a subtle draught (after a listen check) if you're standing next to a hidden door.
Yes, there will be a castle menu on the screen. The NPCs that you encounter will be characters you meet along the way in the dungeon.malcontent wrote:Ah, I see what you mean by Oubliette inspired. Would there be a menu town like wizardry? Or would you bump into NPCs that talk to you?Ghislain wrote:The focus will be on a designed dungeon with all sorts of surprises--good and nasty.
I used to play this old DOS rpg called Swords of Glass, where one very useful feature was that you could use some chalk to mark an "X" on the wall, sort of like leaving a trail of break crumbs behind. Something like that would rely on having persistent dungeons (I.E. having to make a copy of the game disk, and saving the state of dungeons)
Some spot sound effects could be effective, running water when standing near a fountain, a subtle draught (after a listen check) if you're standing next to a hidden door.
I continue to work on the game, getting a little bit done at a time. Today, I programmed those routines to display the 64x64 pixel image at the upper left corner of the screen.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
- orion70
- VICtalian
- Posts: 4342
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
Great project Ghislain! Keep up with it.
I agree about rolling characters being a must-have. If I can suggest some mods, I'd stick with a different font, e.g. a thinner one, and a general layout more oriented towards a gothic, shades-of-grey setting with colors only for warning messages, status, and other important details. I think something like the Bard's Tale 2 (DOS) frame would blend more with your 64x64 b&w window of the outside world:
(FYI: I'm biased because I have a green monitor )
I agree about rolling characters being a must-have. If I can suggest some mods, I'd stick with a different font, e.g. a thinner one, and a general layout more oriented towards a gothic, shades-of-grey setting with colors only for warning messages, status, and other important details. I think something like the Bard's Tale 2 (DOS) frame would blend more with your 64x64 b&w window of the outside world:
(FYI: I'm biased because I have a green monitor )
Thanks. As for a gothic 'shades of grey' type of menu, I've pretty much planned out the use of every single custom character graphic that's available, and there isn't much room to add more graphics. As well, the VIC-20 color palette is limited there.orion70 wrote:Great project Ghislain! Keep up with it.
I agree about rolling characters being a must-have. If I can suggest some mods, I'd stick with a different font, e.g. a thinner one, and a general layout more oriented towards a gothic, shades-of-grey setting with colors only for warning messages, status, and other important details. I think something like the Bard's Tale 2 (DOS) frame would blend more with your 64x64 b&w window of the outside world:
Today, I've redesigned the menu system to highlight the menu choice so that it can be selected either by cursor movement or by pressing the first letter of that option.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
I continue to make progress -- I'm programming the routines to view the characters and I've also codified the magic spells into numerical data format.
Though I am not making progress as quickly as I did with Realms 3, I'm still working on this a little bit at a time.
I will be creating a list of items very shortly as well.
Though I am not making progress as quickly as I did with Realms 3, I'm still working on this a little bit at a time.
I will be creating a list of items very shortly as well.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
If all this fits 16k, I believe it's a great achievement
I was wondering how you choose to make a part in basic or asm (what's the criterion behind that).
Looking forward to your progress!
I was wondering how you choose to make a part in basic or asm (what's the criterion behind that).
Looking forward to your progress!
Pallas - OPByte
http://www.opbyte.it/vic20/
http://www.opbyte.it/vic20/
It's going to be a 16K RAM game, but since I intend to use an entire disk side (or at least try to), then it's going to be a 170KB virtual memory gamepallas wrote:If all this fits 16k, I believe it's a great achievement
I was wondering how you choose to make a part in basic or asm (what's the criterion behind that).
Looking forward to your progress!
As for deciding what I choose to program in ML -- I choose those things that I think can be handled better by it. Displaying graphics or the user interface will be sped up with ML. Displaying the maze on screen will also be handled by ML.
Another example--If I'm going to have an array of 250 strings for text item elements, then instead of doing FORX=1 TO 250: READ I$(X) : NEXT every time a program module is loaded (which would take up some time), I'll have it pre-loaded into the ML memory segment, and if I need to display item 95 on the screen, it will be called with SYS 10000,95 (assuming that 10000 is the address where the text of items routine is located).
Maybe I should program this entirely in ML instead of jumping back-and-forth -- but the advantage of Commodore BASIC is that any changes that are made to the program listing can be tested immediately with RUN.
Basically, I use BASIC for speed of development and for ease of debugging. Realms III was frustrating to program at times when I had to use the ML monitor quite often to figure out what went wrong when I encountered a bug.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
- orion70
- VICtalian
- Posts: 4342
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
Can't wait, too . A couple of questions, Ghislain:Ghislain wrote:It's going to be a 16K RAM game, but since I intend to use an entire disk side (or at least try to), then it's going to be a 170KB virtual memory game
1- is this going to have also a commercial version, like RoQ3 (jewel case with disk, manual, etc.)?
2- will loading chunks of the game from floppy will down/interrupt its action?
(well, three questions)
3- will it be possible to save all in the FE3 "RAM disk", and load from it to speed things up?
I will certainly try to do this. I was going to submit RQ4 in the future to be bundled with my previously done games like Theater of War, but then I noticed that those games I've done from 2010-2013 can actually take up the whole side of a disk, so I submitted a "Theater of War + Other Games" D64 image to Psytronik a few days ago. I haven't heard back from Kenz yet (other than to say that he's gotten it).orion70 wrote:1- is this going to have also a commercial version, like RoQ3 (jewel case with disk, manual, etc.)?
I'd like to release RQ4 plus the anniversary editions of RQ1+2 in it's own jewel case.
I visualize the modules of the game to be as follows:2- will loading chunks of the game from floppy will down/interrupt its action?
1. MAIN MENU & CASTLE
2. DUNGEON CRAWLER
3. BATTLE
So when you exit the castle, it will load the dungeon crawling module. When you encounter a group of monsters, then it will load the battle module and so on. If you go up or down the stairs in a dungeon, the dungeon crawling module will load the data for the new floor from disk, of course.
I don't have an FE3 so I'm not familiar with how it works. Can files from a disk be transferred to the FE3 and then be loaded?3- will it be possible to save all in the FE3 "RAM disk", and load from it to speed things up?
The thing about RQ3's 32K requirement was that it's not a common form of memory expansion, so a few people weren't able to play it on the real hardware. I did make a 16K version, but I didn't hear of too many who tried it.
So the 16K RAM requirement for RQ4 plus a disk drive will have a larger user base who will be able to play it on a real VIC-20.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
-
- Vic 20 Hobbyist
- Posts: 129
- Joined: Sun Dec 26, 2010 1:51 pm
If you can cram the battle system in with the dungeon, and only disk access for graphics and maybe spell and item names it'd hopefully cut loading times. Monster info would be floor dependent anyway, you could include that data with the dungeon map.
Will the dungeons be persistent? That is, would one have to copy the original disk because changes to the dungeons are saved? (Or a reset utility?)
Will the dungeons be persistent? That is, would one have to copy the original disk because changes to the dungeons are saved? (Or a reset utility?)
Loading monster info dynamically might be a good thing to do. And since the combat module will load 64x64 pixel monster portraits, then the text and monster data info can be loaded at the same time.malcontent wrote:If you can cram the battle system in with the dungeon, and only disk access for graphics and maybe spell and item names it'd hopefully cut loading times. Monster info would be floor dependent anyway, you could include that data with the dungeon map.
Will the dungeons be persistent? That is, would one have to copy the original disk because changes to the dungeons are saved? (Or a reset utility?)
Of course, if I can do it, I would certainly combine the dungeon and combat modules together in the same program listing. I won't know if this is possible until I actually work on these.
As for the dungeons being persistent--my intention is that any changes to the mazes and such will be stored in save game memory rather than modifying the map data. I don't want the player to have to make copies of the game disk like it was done with some CRPGs back in the day.
"A slave is one who waits for someone to come and free him." -- Ezra Pound