**New Release** REALMS OF QUEST 3 (available for order!)
Moderator: Moderators
**New Release** REALMS OF QUEST 3 (available for order!)
Well, I only really started this morning, but I was thinking of a concept for a sequel to Dunjon II for some time. So after a few minutes I came up with the following mock-up screen:
(**edit: moved original mockup screen from picpaste to imagehosting)
This is not final but will be a loose basis of how the finished game will look like. The upper left section shows the maze from a first-person perspective (ala Wizardry). You also see the monsters that you encounter (up to 16 of them), with the first letter of the monster name representing the individual ones The upper right section shows the party members. The middle right section shows the active/selected player's statistics and items. The middle left section shows the party's common items and supplies (gold, healing potions, ammunition and a group-wide spell or curse that is affecting everyone in the party). The bottom section will be for scrolling text.
As with the first 2 versions of Dunjon, this is going to be a "generic RPG" where there's no specific quest--you pretty much wander in the dungeon hunting for some orc and to find some cool magic items. And like it's predecessors, your characters tend to die a lot. But this time, you will adventure as a group so if someone does die, you just create a new character to replace him or her.
I will work within the following parameters:
-will be a game for the unexpanded VIC-20
-only PETSCII graphics
-save game feature
-lots of ML to speed up the display
Maybe I shouldn't put this out there only because 70% of the projects at this stage never actually get finished, but hopefully by making this announcement, it will give me motivation to see this through the end.
(**edit: moved original mockup screen from picpaste to imagehosting)
This is not final but will be a loose basis of how the finished game will look like. The upper left section shows the maze from a first-person perspective (ala Wizardry). You also see the monsters that you encounter (up to 16 of them), with the first letter of the monster name representing the individual ones The upper right section shows the party members. The middle right section shows the active/selected player's statistics and items. The middle left section shows the party's common items and supplies (gold, healing potions, ammunition and a group-wide spell or curse that is affecting everyone in the party). The bottom section will be for scrolling text.
As with the first 2 versions of Dunjon, this is going to be a "generic RPG" where there's no specific quest--you pretty much wander in the dungeon hunting for some orc and to find some cool magic items. And like it's predecessors, your characters tend to die a lot. But this time, you will adventure as a group so if someone does die, you just create a new character to replace him or her.
I will work within the following parameters:
-will be a game for the unexpanded VIC-20
-only PETSCII graphics
-save game feature
-lots of ML to speed up the display
Maybe I shouldn't put this out there only because 70% of the projects at this stage never actually get finished, but hopefully by making this announcement, it will give me motivation to see this through the end.
Last edited by Ghislain on Mon Nov 02, 2009 5:53 am, edited 7 times in total.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
- orion70
- VICtalian
- Posts: 4341
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
VERY WELL! I'm eager to try it- so please don't leave this project in the drawer.
The type of display reminds me of Ultima: escape from Mt. Drash.
That one was for 16K VIC, and probably yours will end up to be far less expensive .
The type of display reminds me of Ultima: escape from Mt. Drash.
That one was for 16K VIC, and probably yours will end up to be far less expensive .
Actually, the color schemes that I came up with are pretty close: black background, green border and white text.ral-clan wrote:This looks great. I like the fact it's going to be for the unexpanded VIC.
Since it is PETSCII, could you please allow users to define the screen colours? I would love to run this game with a black background, black border and green text. It would feel like I was running it on a PET.
I'm working on it now as we speak.
I'm trying to use as much ML as possible.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Yesterday I got as far as preparing the display and created a routine that will clear a section of the screen (by passing coordinates, location, etc).
The next thing that I will work on is displaying the player stats. I've never done arithmetic in machine language before (aside from 1-byte numbers) and my RPG games have always involved a lot of numbers.
I was planning on using _some_ ML for this and I could take the easy way out by using BASIC, but I want the game to run as quickly as possible, especially when it comes to the display aspect of it.
So I'm not sure which one to use--BCD or standard hexadecimal. Both have their strong points and weak points. I'll probably use a combination of both.
I'm also thinking of changing the number of characters in a party from 6 to 4 -- only because I can save on memory as well as display space on the screen. As well, with 4 characters, I can easily fit them in one contiguous memory space between 828-1023 and thus save the game to and from disk.
The next thing that I will work on is displaying the player stats. I've never done arithmetic in machine language before (aside from 1-byte numbers) and my RPG games have always involved a lot of numbers.
I was planning on using _some_ ML for this and I could take the easy way out by using BASIC, but I want the game to run as quickly as possible, especially when it comes to the display aspect of it.
So I'm not sure which one to use--BCD or standard hexadecimal. Both have their strong points and weak points. I'll probably use a combination of both.
I'm also thinking of changing the number of characters in a party from 6 to 4 -- only because I can save on memory as well as display space on the screen. As well, with 4 characters, I can easily fit them in one contiguous memory space between 828-1023 and thus save the game to and from disk.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
If you don't fancy writing your own routines to convert a "hexadecimal" number to ASCII, there are some routines in the Basic ROM you can use with certain limitations (i.e. converting it to FAC FLPT format). See the sticky thread about ROM calls. I believe I used one of those when displaying the six digit score in Jewels.
Anders Carlsson
Are there kernel routines that I can borrow where I can just pass parameters to them and then it prints the values to the screen according to what is being passed? I just jotted down a routine on a piece of scrap paper that will print out a BCD value:Kweepa wrote:I would choose non-BCD for a larger project. BCD is good when you want to optimise the number printing routine for space, but the savings slowly disappear when you have a lot of operations on different numbers, as you have to sed and cld around each operation.
Code: Select all
;PRINT BCD VALUE
;parameters to pass: mem locations 1+2 start of memory where BCD resides
;mem location 3, length (in bytes) of number
;bcd flags turned off to convert numbers to printable ASCII chars
ldy #0
loop1
lda (1),y
and #15
clc
ror
ror
ror
ror
adc (to a printable ASCII character)
jsr $ffd2
lda (1),y
and #240
adc (to a printable ASCII character)
jsr $ffd2
iny
cpy $3 (compare mem location 3)
bne loop1
rts
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Thanks for the tip ("ROM calls and other tricks"). I really should read these sticky threads more often.carlsson wrote:If you don't fancy writing your own routines to convert a "hexadecimal" number to ASCII, there are some routines in the Basic ROM you can use with certain limitations (i.e. converting it to FAC FLPT format). See the sticky thread about ROM calls. I believe I used one of those when displaying the six digit score in Jewels.
There's no sense in me re-inventing the wheel so to speak. I just briefly glanced at the thread and I find the concept of a floating point accumulator very ingenious.
I'm a little bit behind in my ML programming skillz, I must admit.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Assuming you simply want to print something to screen:
It can't be much simpler than that.. only drawback is that $D391 will only accept values 0 - 32767 while your mockup uses values up to 99999.
Code: Select all
LDA score ; high byte
LDY score+1 ; low byte
JSR $D391
JSR $DDD7
RTS
score: .byte 7,208 ; 7 * 256 + 208 = 2000 points
Code: Select all
3 * 256 + 232 = 1000
7 * 256 + 208 = 2000
15 * 256 + 160 = 4000
31 * 256 + 64 = 8000
62 * 256 + 128 = 16000
125 * 256 + 0 = 32000
Anders Carlsson
Oh I plan on having values that go up to 999,999,999 (experience points). For that, I'll be using floating accumulators.carlsson wrote:It can't be much simpler than that.. only drawback is that $D391 will only accept values 0 - 32767 while your mockup uses values up to 99999.
But being able to use 16 bit numbers will be very useful to print out almost everything else (STR, INT, WIS, hit points, etc).
After reading the sticky on those routines, I'm seriously considering making it all in ML. I'll have to dis-assemble some of the other routines such "Perform [exp]" at $DFED (source: http://www.zimmers.net/cbmpics/cbm/vic/rommap.txt) to figure out what needs to be passed to it, but I should be able to do it.
Making it in pure ML will probably take me 10 times as long as it normally would with BASIC but the end result will be worth it.
I've been using Turbo Assembler in a Commodore 64 emulator and then running the executable afterwards on a VIC-20 emulator. Rather than use a c64 emulator with TASS, is there a cross-compiler I can use in Linux that will create a .prg file that can then be loaded into a VIC-20 emulator?
"A slave is one who waits for someone to come and free him." -- Ezra Pound
This looks awesome.
I wouldn't mind seeing user definable fore/background colors myself, since I like blue on green , and ... I dont think anyone else does.
How will the character system be? Lots of classes/races?
and, I agree 4 characters should be good, and will be a different approach than the typical 6 in every CRPG ever made!
I wouldn't mind seeing user definable fore/background colors myself, since I like blue on green , and ... I dont think anyone else does.
How will the character system be? Lots of classes/races?
and, I agree 4 characters should be good, and will be a different approach than the typical 6 in every CRPG ever made!
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
I swear by the cross-assembler in the cc65.org project. I currently use it on both Vista64 and Linux. On Linux, I don't even bother to compile the source, I just run the included win32 binaries using wine!is there a cross-compiler I can use in Linux that will create a .prg file that can then be loaded into a VIC-20 emulator?
From the source, http://robert.hurst-ri.us/files/quikman2k8.s
Code: Select all
ca65.exe --cpu 6502 --listing quikman2k8.s
ld65.exe -C doc/vic20.cfg -o quikman2k8.prg quikman2k8.o
I get the following error when I run ld65:rhurst wrote:I swear by the cross-assembler in the cc65.org project. I currently use it on both Vista64 and Linux. On Linux, I don't even bother to compile the source, I just run the included win32 binaries using wine!is there a cross-compiler I can use in Linux that will create a .prg file that can then be loaded into a VIC-20 emulator?
From the source, http://robert.hurst-ri.us/files/quikman2k8.sCode: Select all
ca65.exe --cpu 6502 --listing quikman2k8.s ld65.exe -C doc/vic20.cfg -o quikman2k8.prg quikman2k8.o
ld65: Error: vic20.cfg(6): Type expected
How does your vic20.cfg file look like?
"A slave is one who waits for someone to come and free him." -- Ezra Pound
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
You did not d/l the doc archive and unpack it? It includes the necessary doc/vic20.cfg (listed below) to assist in assigning memory:
I modified this later when relocating my unexpanded code into $A000 to make a game cartridge out of it. I added this CART memory segment:
Code: Select all
MEMORY {
ZP: start = $0002, size = $001A, type = rw, define = yes;
RAM: start = $0FFF, size = $0E01, define = yes, file = %O;
}
SEGMENTS {
STARTUP: load = RAM, type = ro;
LOWCODE: load = RAM, type = ro, optional = yes;
INIT: load = RAM, type = ro, define = yes, optional = yes;
CODE: load = RAM, type = ro;
RODATA: load = RAM, type = ro;
DATA: load = RAM, type = rw;
BSS: load = RAM, type = bss, define = yes;
HEAP: load = RAM, type = bss, optional = yes; # must sit just below stack
ZEROPAGE: load = ZP, type = zp;
}
FEATURES {
CONDES: segment = INIT,
type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__;
CONDES: segment = RODATA,
type = destructor,
label = __DESTRUCTOR_TABLE__,
count = __DESTRUCTOR_COUNT__;
CONDES: segment = RODATA,
type = interruptor,
label = __INTERRUPTOR_TABLE__,
count = __INTERRUPTOR_COUNT__;
}
SYMBOLS {
__STACKSIZE__ = $400; # 1K stack
}
Code: Select all
CART: start = $A000, size = $4000, type = ro, define = yes;