*ALL PHYSICAL COPIES ARE SOLD OUT*: REALMS OF QUEST V (Digital version is available)
Moderator: Moderators
Re: Work in progress: REALMS OF QUEST V
More work on inspecting items in the inventory -- now adding the final touch: being able to inspect the ally NPC/companion/summon/controlled creature in the player character's "inventory" :
This is a far better implementation of this game mechanic that existed in Realms of Quest IV where you could only summon or control a creature during combat and they only did basic things like perform melee attacks for the remainder of the battle.
This time, your 'summon' can perform all the special attacks as well and it will stay with you beyond one battle -- it will travel during the adventure with you. Now, the 'summon' does not have all the features of the player character (it won't have spell units -- basically, it will only have the special attacks normally given to enemies) but it will help the player enough so that they feel like a member of the party. Throughout the game you will also meet NPCs on your travels, let's say a mysterious ranger you happen to meet at a tavern who offers to help, for example.
The rules for allies/summons are as follows:
-the ally shares the THACO and AC of the player that it is tethered to. As well as IQ, WIS, AGI, HEA and CHA for saving throw purposes.
-during combat, the player either chooses to perform an action for himself (attack, cast spell, use item, etc) or defers to the ally to perform one of it's 4 combat actions (which is chosen randomly by the computer). So only either the player or the ally can perform actions during a combat turn.
-if a monster attacks a player character and scores a hit, damage is done to the ally first and once it has died, then damage is done to the player character.
-monsters will do special attacks (like poison, kill, stone) to allies first. However, if successful they Remove the ally from the game (this is because allies don't have poisoned or statue status variables -- the game program will be complex enough as it is).
-once an ally has "died", it is removed permanently from the game. It cannot be resurrected or brought back.
-healing on a player character will cure damage on the PC first, then the ally.
-if an ally kills an enemy, the player character takes credit for the experience for purposes of leveling up.
-an ally is always tied to the player it was originally tethered to -- you cannot give an ally to another character in the party.
This is a far better implementation of this game mechanic that existed in Realms of Quest IV where you could only summon or control a creature during combat and they only did basic things like perform melee attacks for the remainder of the battle.
This time, your 'summon' can perform all the special attacks as well and it will stay with you beyond one battle -- it will travel during the adventure with you. Now, the 'summon' does not have all the features of the player character (it won't have spell units -- basically, it will only have the special attacks normally given to enemies) but it will help the player enough so that they feel like a member of the party. Throughout the game you will also meet NPCs on your travels, let's say a mysterious ranger you happen to meet at a tavern who offers to help, for example.
The rules for allies/summons are as follows:
-the ally shares the THACO and AC of the player that it is tethered to. As well as IQ, WIS, AGI, HEA and CHA for saving throw purposes.
-during combat, the player either chooses to perform an action for himself (attack, cast spell, use item, etc) or defers to the ally to perform one of it's 4 combat actions (which is chosen randomly by the computer). So only either the player or the ally can perform actions during a combat turn.
-if a monster attacks a player character and scores a hit, damage is done to the ally first and once it has died, then damage is done to the player character.
-monsters will do special attacks (like poison, kill, stone) to allies first. However, if successful they Remove the ally from the game (this is because allies don't have poisoned or statue status variables -- the game program will be complex enough as it is).
-once an ally has "died", it is removed permanently from the game. It cannot be resurrected or brought back.
-healing on a player character will cure damage on the PC first, then the ally.
-if an ally kills an enemy, the player character takes credit for the experience for purposes of leveling up.
-an ally is always tied to the player it was originally tethered to -- you cannot give an ally to another character in the party.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
Inventory data management is probably the least sexy part of CRPG design, but it has to be done. Otherwise, there is really no game without it.
I've been working on the equipment inventory screen lately where the player can see which items can be equipped on the player character that is viewing the inventory.
I've been working on the equipment inventory screen lately where the player can see which items can be equipped on the player character that is viewing the inventory.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
The disadvantage of using a missile weapon is that you suffer an armor penalty (see above) and you cannot use a shield at the same time.
I also created some special swords that are tied to the alignment of the player -- only a lawful player can be quipped with a lawful sword and only a chaotic player can be equipped with a chaotic sword.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
Very nice. The game is starting to sound like it is going to have a very dynamic system that would allow you to take the characters in many different directions.
R'zo
I do not believe in obsolete...
I do not believe in obsolete...
Re: Work in progress: REALMS OF QUEST V
Thank you. I'm improving on the Realms IV engine (converting it to ML), but the NPC/summon/ally system is going to be the major improvement.R'zo wrote:Very nice. The game is starting to sound like it is going to have a very dynamic system that would allow you to take the characters in many different directions.
I've been working on the Market portion of the castle. Here, the player attempts to sell items in the inventory, but Bolzaim's Trading Post is only offering to monetize such items at half of their value.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
I'm putting in about 45-90 minutes a day and I feel like progress has been slow and incremental. I keep making it one piece at a time, like the song says.
https://www.youtube.com/watch?v=rWHniL8MyMM
https://www.youtube.com/watch?v=rWHniL8MyMM
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
Looking forward to this one! The last 1% usually takes the most time, but if you can keep grinding on it you will succeed! Dont give up!
- orion70
- VICtalian
- Posts: 4340
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
Re: Work in progress: REALMS OF QUEST V
BTW could we have a teaser vid of it?
Re: Work in progress: REALMS OF QUEST V
Thanks all. I'm now working on the "buy items" portion of the trading post:
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
I spent this morning writng a routine that switches position slots of players. Since assembly language is very pointer-based, I don't have to copy data from one section of memory to another, I simply modify the pointers. But still, this routine requires the game to ask for the player they want to move and then the new position. I went through a few cycles where the program would crash before I got it right (there is an intricacy of a few JSRs that get pushed into the stack because the same SELECTCHARACTER subroutine gets called twice).
Some of you jedi coders could probably pick this apart and find inefficiencies that I could get rid of. I'm certainly a bit more adept at pushing and pulling the stack compared to the time I programmed Realms III, however.
Code: Select all
;-------------------------------------------------------------------------------------------------
POSITION:
ldx #<(@pos1txt)
ldy #>(@pos1txt)
lda #<(POSITION2)
sta TEMP1
lda #>(POSITION2)
sta TEMP2
lda #0
jmp SELECTCHARACTER
@pos1txt:
; 012345678901234567890123
.byte " sELECT pLAYER tO mOVE ",0
;------------------------
POSITION2:
lda PCHAR
sta TEMP5
tax
jsr PRINTSINGLECHAR
ldx #<(@pos2txt)
ldy #>(@pos2txt)
lda #<(POSITION3)
sta TEMP1
lda #>(POSITION3)
sta TEMP2
lda #1
jmp SELECTCHARACTER
@pos2txt:
; 012345678901234567890123
.byte " sELECT nEW pOSITION ",0
;------------------------
POSITION3:
; finally move character to new position
jsr HIDESCREEN
ldx PCHAR
lda PNAMELOC,x
sta @namelo
lda PNAMELOCHI,x
sta @namehi
lda PCHARLOC,x
sta @charlo
lda PCHARLOCHI,x
sta @charhi
ldx TEMP5
ldy PCHAR
lda PNAMELOC,x
sta PNAMELOC,y
lda PNAMELOCHI,x
sta PNAMELOCHI,y
lda PCHARLOC,x
sta PCHARLOC,y
lda PCHARLOCHI,x
sta PCHARLOCHI,y
; and move whatever is at new position to
; the old position
lda @namelo
sta PNAMELOC,x
lda @namehi
sta PNAMELOCHI,x
lda @charlo
sta PCHARLOC,x
lda @charhi
sta PCHARLOCHI,x
jmp PRINTCHARS
@namelo: .byte 0
@namehi: .byte 0
@charlo: .byte 0
@charhi: .byte 0
;-------------------------------------------------------------------------------------------------
SELECTCHARACTER:
; lets the player select which character they want to select before performing an action on it
; pass x,y = address of text to display
; pass TEMP1,TEMP2 = address of routine
; pass ACC 0 = selected character must not be empty
; pass ACC 1 = override empty slot (can be empty or not)
sta @override
stx @tempx
sty @tempy
lda TEMP1
sta @jsrpoint+1 ; self-modifying code that modifies where to JSR to
lda TEMP2
sta @jsrpoint+2
jsr SELECTCHAR
ldx @tempx
ldy @tempy
lda #48
jsr DISPLAYTEXTBOTTOM
@v1:
jsr GETKEYPRESS
cmp #157
beq @vx
cmp #32
beq @vx
jmp @v2
@vx:
ldy #0
ldx PCHAR
jsr PRINTSINGLECHAR
lda #0 ; return false
rts
@v2:
jsr CURSORSELECTCHAR
cmp #255
bne @gochar
jmp @v1
@gochar:
sta PCHAR
tax
lda @override
cmp #1
beq @gochar2
jsr ISCHAREMPTY
cmp #1
beq @vx
@gochar2:
lda CMENUSEL
pha
lda CMENUMAX
pha
@jsrpoint:
jsr SELECTCHARACTER ; the subroutine to JSR to (modified by TEMP1/TEMP2 above)
pla
sta CMENUMAX
pla
sta CMENUSEL
lda #1 ; return true
rts
@override:
.byte 0
; these store the x/y address of the text to be displayed
@tempx:
.byte 0
@tempy:
.byte 0
;-------------------------------------------------------------------------------------------------
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
These past few days I've worked on the Temple and also the save game feature.
In previous instalments of the series, I'd have the player press a key (between 1 and N) to select the save game slot, but I want the new game to be as cursor key/joystick-driven as much as possible. This way if you happen to be a bit far from the keyboard or you're using a special handheld emulator (say on a smart phone or one of those open source handhelds like the GP2X or OpenPandora), then the interface is easier to use.
In previous instalments of the series, I'd have the player press a key (between 1 and N) to select the save game slot, but I want the new game to be as cursor key/joystick-driven as much as possible. This way if you happen to be a bit far from the keyboard or you're using a special handheld emulator (say on a smart phone or one of those open source handhelds like the GP2X or OpenPandora), then the interface is easier to use.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
Thanks. I can't wait to see how this game will be like once I am finally finished. The total filesize of this game is now about 68K -- just a tad bit over 10% of the 650K or so that this game will be. However, a lot of the disk space will be used up by graphics, so I should be making more and more progress as the game modules are being completed.Muzz73 wrote:Looking more awesome by the day!
I just finished programming the Inn portion of the castle. As well as the aging and leveling up process. Poor Xavvry has permanently died of old age while testing this portion of the code. This means that the castle module is more or less finished (save for keyboard shortcuts, but I can do those later). Now I can finally move on to the next module: world map design and traveling. For this, I'll need to create a tile set (terrain features, cities, dungeons, etc) and a map editor. The data for the world map will be loaded into the 8K block at memory location $A000. Which is about 90*90 tiles or so. Now, the world map as a whole will be considerably larger than this -- it just means that about 8K of the world map will be present in RAM at a time. Once a player travels to a portion of the map that takes him to another map, then the other map is loaded from disk into memory.
And for those who are a bit confused by the player icons that represent alignment, sex, race and class, you will find that these will play a crucial part as far as game mechanics go -- you will be thankful that these will be displayed on the main screen during gameplay.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Re: Work in progress: REALMS OF QUEST V
Looks like it's coming along very nicely.
- orion70
- VICtalian
- Posts: 4340
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
Re: Work in progress: REALMS OF QUEST V
Rubygolem, can't wait to see your blog updated with entries dedicated to this new incarnation of the RoQ saga .