**New Release** REALMS OF QUEST 3 (available for order!)

carlsson · Post by **carlsson** » Sat Mar 07, 2009 10:21 am

Perhaps we should try to add an upload service to Denial? It isn't quite rocket science, not even with personal accounts and file management.

MacbthPSW · Post by **MacbthPSW** » Sat Mar 07, 2009 10:28 am

Very cool! I would have preferred Dunjon 3D over a RQ sequel, but this is still very good news

(it's just that Dunjon 2 is about my favourite VIC game ever)

Ghislain · Post by **Ghislain** » Sat Mar 07, 2009 10:50 am

MacbthPSW wrote:Very cool! I would have preferred Dunjon 3D over a RQ sequel, but this is still very good news

(it's just that Dunjon 2 is about my favourite VIC game ever)

Thanks for the kind words, I'm humbled. I decided to go "all out" and make a 32K cartridge for my last, final VIC-20 hurrah.

Realms of Quest II has all the elements of Dunjon 2 and it is more polished with scrolling landscape (sped up by ML), custom char graphics and even background music. Just wondering why do you prefer D2? Just curious

I really do want to make about 10-20 cartridges of this game with a nice-looking box and instruction manual. I'd like for the package to look like an early 1980s D&D box:

Pedro Lambrini · Post by **Pedro Lambrini** » Sat Mar 07, 2009 2:10 pm

^
Put me down for one!

bokvamme · Post by **bokvamme** » Sat Mar 07, 2009 3:51 pm

Me too..

Ghislain · Post by **Ghislain** » Sun Mar 08, 2009 8:36 am

I drew a couple of more graphics (actually, I replaced the 'spectre' with a pirate captain--I figure that such a game enemy will be needed especially if you travel by ship Ultima-style and you get boarded by buccaneers) and programmed a bit more of the main screen display.

I've been thinking about the pros and cons of making a disk-based game VS a cartridge-based one (since my programming environment is done in a PC-based text editor it's not that hard for me to switch from one to the other).

The "Pros and Cons" of making a 32K cartridge:

-single loading game
-more retro "pure" (option to save to disk or tape won't seem out of place)
-the difficulty of producing actual 32K cartridges, even though they will be limited in number.
-those who won't be getting the cartridge (ie: downloading the game from the 'net) will either have to play it on an emulator or locate 32KB of RAM expansion (such as Mega Cart)
-only 3.5KB of RAM

The "Pros and Cons" of making a 16K disk-based game:

-multi-loading
-170K of space to work with for maps, etc.
-less "retro pure" (in the early 1980s, very few VIC users had disk drives though 16K RAM expansion was somewhat common)
-It will be easier for people to actually play this game on real VIC-20s because 16K ram expansion is fairly common today as well as having a disk drive.
-19.5KB of continuous RAM available (can change data within the code so no need to swap from ROM to RAM for graphics, etc)

I'm still leaning towards making a 32K cartridge though. Maybe after the cartridge is done, I'll make a 16K single loading stripped down version.

ral-clan · Post by **ral-clan** » Sun Mar 08, 2009 9:01 am

I'm really looking forward to this game.

Just an idea I had towards allowing you to have a wider variety of monsters without actually increasing the size of the binary by creating more graphics:

- how about just inverting or replacing colour values in existing monster images. i.e. if one of your monsters is a dragon, couldn't you substitute the body colour of the dragon to have green dragons, red dragons, blue dragons, etc. or you could have regular Orcs and "Night Orcs" by referencing the same bitmap data, but making the skin colour dark blue. Ghoul and Blood Ghoul (same graphic but with red coloured body)...etc.

Would that simple colour substitution technique allow you to have more monsters without making the game larger?

Ghislain · Post by **Ghislain** » Sun Mar 08, 2009 9:34 am

ral-clan wrote:I'm really looking forward to this game.

I look forward to finishing it! I find that porogramming in ML is about 10 times more time-consuming than BASIC, but hopefully the learning curve will be overcome shortly.

how about just inverting or replacing colour values in existing monster images. i.e. if one of your monsters is a dragon, couldn't you substitute the body colour of the dragon to have green dragons, red dragons, blue dragons, etc. or you could have regular Orcs and "Night Orcs" by referencing the same bitmap data, but making the skin colour dark blue. Ghoul and Blood Ghoul (same graphic but with red coloured body)...etc.

Would that simple colour substitution technique allow you to have more monsters without making the game larger?

I have thought of this and I'm seriously considering it. I might just do it -- it would add quite a bit of variety without using that much more memory overhead (except for the text that will be used to describe the different monsters and the statistics for them of course).

I also find that having only 32 monsters quite restricting, I might just increase the number of monster graphics to 40 (and add a bat, goblin, insects, elementals, etc) and the "in-context" graphic information will just be moved to the main 24K area.

If I can "re-use" some of the monster graphics, then I can probably have a game where there will be over 70 monsters easily.

ral-clan · Post by **ral-clan** » Sun Mar 08, 2009 10:14 am

Here's another idea:

Remember those old kid's flip books where you have pictures of people and you can flip the top, middle and bottom portions of the page seperately to give the person a different head, body or legs?

Perhaps some of your graphics could be made with a similar approach. I.e. design some monsters so that the pixels around the waists of the monsters match up with those of other monsters. Thereby you could combine the top portion of one monster with the legs of another to have some hybrid monsters. You don't actually have to have distinct bitmaps for these hybrids, but rather call the bitmap data for the top half of the image from one existing monster, and the bottom half from the bitmap data of another monster.

I'm just trying to think of some hybrid monster types that wouldn't be too cheesy if mixed up this way! Mer-Orc? Demon-Mummy?

Ghislain wrote:I really do want to make about 10-20 cartridges of this game with a nice-looking box and instruction manual. I'd like for the package to look like an early 1980s D&D box:

I love that cover too.

I'm not sure what your art-skills are like, or if you are intending to design the cover/label yourself. But if you need help, or are looking for someone to design something, I wouldn't mind taking a crack at it. I did the art for the Mega-Cart if you need an example of my work (that was intentionally made to copy an original VIC cartridge but I can do other styles too) - as long as you don't need anything soon (i.e. summer would be a better time).

Ghislain · Post by **Ghislain** » Sun Mar 08, 2009 10:52 am

ral-clan wrote:Here's another idea:

Remember those old kid's flip books where you have pictures of people and you can flip the top, middle and bottom portions of the page seperately to give the person a different head, body or legs?

That might be a bit too hard to do. One thing that I could do is 'double' the height of some monsters (just copy from the ROM and make each height of pixels into 2--kind of like the way that some VIC-20 programmers copy the ROM character set to turn them into double height characters ) and create 'giant' versions of these: GIANT KOBOLD, GIANT ORC, etc. As well, the GIANT MERMAN could just be called POSEIDON (from Greek mythology). The doubling of height wouldn't look that much out of place because in multicolor mode, VIC-20 graphics are very thin height-wise but much too thick in terms of width.

At this point, there could be over 100 monsters using double size and various combination of colors.

I love that cover too.

I'm not sure what your art-skills are like, or if you are intending to design the cover/label yourself. But if you need help, or are looking for someone to design something, I wouldn't mind taking a crack at it. I did the art for the Mega-Cart if you need an example of my work (that was intentionally made to copy an original VIC cartridge but I can do other styles too) - as long as you don't need anything soon (i.e. summer would be a better time).

My art skills aren't that great. I was hoping to delegate some of the tasks in regards to the manual to others. I really appreciate your offer and I may just ask you at some point in the future for help in this regard.

ral-clan · Post by **ral-clan** » Sun Mar 08, 2009 11:13 am

On last idea re. squeezing out the last drop of monster variety. How hard (i.e. how much more would it enlarge the binary) to simply make a monster's eyes "glow" red. In this case you could have a series of "possessed" monsters which would use the same graphic as thier normal counterpart with only a minimal change of a couple of pixels (for the eyes).

I.e. you'd have your regular orcs, mermen, kobolds, etc. and then ones with red eyes that would be possessed orcs, possessed kobolds, etc.

Ghislain · Post by **Ghislain** » Sun Mar 08, 2009 11:43 am

ral-clan wrote:On last idea re. squeezing out the last drop monster variety. How hard (i.e. how much more would it enlarge the binary) to simply make a monster's eyes "glow" red. In this case you could have a series of "possessed" monsters which would use the same graphic as thier normal counterpart with only a minimal change of a couple of pixels (for the eyes).

I.e. you'd have your regular orcs, mermen, kobolds, etc. and then ones with red eyes that would be possessed orcs, possessed kobolds, etc.

The way I'm designing the memory for the monsters is that they have 2 mandatory colors: background (black), border (yellow) and 2 colors to choose from: character and auxiliary--making for a grand total of 4 colors to work with. To just change the colors of the eyes would require redrawing the monster graphics to make sure that there are no conflicts.

I could however make some monsters cycle through all 16 colors in the auxiliary nibble (bits 4-7 of 36878) through ML code so that they appear more 'animated' or even 'possessed'.

Thanks for the suggestions, it did make me think how I could re-use the same monster graphics to make it appear that there is more variety. For example, I hadn't thought of doubling the monster height before you suggested other ideas (reusing head, body or changing the eye color--which unfortunately, are not viable in the context that I am making this game).

I was flipping through an old copy of Retro Gamer yesterday and it made me appreciate even more the amount of time and effort it takes to make impressive-looking 8 bit graphics.

darkatx · Post by **darkatx** » Mon Mar 09, 2009 10:30 pm

If you need some artwork - painted, hand drawn or even pixels I might be able to pitch in as well

This thing looks so cool man!

Ghislain · Post by **Ghislain** » Tue Mar 10, 2009 7:16 pm

I still continue to design the graphics, bit by bit. I had a sleepless night the other day and during the time as I stared at the ceiling for several hours, I thought about how I will generate the world map. I basically came up with this:

-128 x 128 'overworld' designed by hand that will use 8192 bytes --- basically each tile will use up a nibble (4 bits)... or 2 tiles per byte.
-128 x 128 'middle world' that is generated by a portion (16K) of the ROM space occupied by the main program.
-128 x 128 'under world' generated by the 16K of rom space of the VIC-20 BASIC and kernal (similar to Realms of Quest II).

I also did a google search for 'how to design a CRPG' and I found this great website:

http://www.adamantyr.com/crpg/

He's programming an RPG for the TI 99 computer in assembly language and I am running into the same challenges that he is. It's a great read.

ral-clan · Post by **ral-clan** » Tue Mar 10, 2009 8:07 pm

Ghislain wrote:-128 x 128 'middle world' that is generated by a portion (16K) of the ROM space occupied by the main program.
-128 x 128 'under world' generated by the 16K of rom space of the VIC-20 BASIC and kernal (similar to Realms of Quest II).

As a non-programmer I'm curious to understand what the above two points mean. Does it mean that because you can't store map data in RAM (no room) you are just reading areas of the VIC's BASIC & KERNAL ROM and using the bytes to generate a map (almost a random map)?

Also, do you need medieval sounding music for this game? I'd be willing to compose some. I usually compose in a MIDI sequencer, and could provide music in MID format (but you'd have to conver it somehow). Or I could really force myself to learn how to program the music for the VIC in BASIC.