The Legend of Beryl Reichardt

[Opry99er]

I want to cram as much in each 16x16 box as I can, so that's why I often design sprites displaced like that. I don't know how much of a hassle it is to a programmer, but to an artist, it's great!

 

it's honestly not too hard to handle... Depending on what you want to do with it, it's really just offsetting the "offending" SPRITE at the outset--- then when you move the first SPRITE, a simple offset calculation will allow the second SPRITE to always remain in the proper offset position. In Lemonade Stand's title sequence, I had to do this--- but it was very easy because I used auto-motion and after I placed them properly, I just sent both on their own happy little journey. Besides, there aren't many "moving" parts in "LoBR.". The map is updated on user input, so as the map "moves" under the window, the illusion of walking and SPRITE motion is accomplished simply by an "A-B" SPRITE animation, and no actual motion takes place unless the character is near the borders of the map. (Thanks Matthew for that brilliant little lesson). Anyway, for quest items and normal items, this makes absolutely no difference either way, because they will always be static and motionless. Thanks again for your help!!!!

[Opry99er]

Here's the current list of variables I'm using for the battle engine. This is just the front end of the code, so there's nothing that actually "happens" in this post.... The actual portions where I manipulate the variables in battle is not part of this post... it's terribly inefficient as of yet, and I'm not comfortable posting it yet... Give me a couple days and I'll have it ready. In the meantime, take a look at these variables and let me know if you think this will be sufficient for this mock battle.... There will most decidedly be more stuff to factor in as we go... but this should be good for now. I'm really interested in theories on how to create the battle equations so that they are realistic or believable....

 

REM **THESE ARE THE STATISTICAL VARIABLES FOR THE PC'S

REM **MAX HP, HP, MAX MP, MP, ATTACK, DEFEND, MACIC ATTACK ,MAGIC DEFEND

REM ** B=BERYL, R=REPTOSLICER, M=MARKUS, S=SKYLAR
REM ** SK=SKELETON (THE ENEMY)

1 BLEV=10 :: BMHP=100 :: BHP=100 :: BMMP=50 :: BMP=50 :: BA=7 :: BD=7 :: BMA=4 :: BMD=6
2 RLEV=11 :: RMHP=100 :: RHP=100 :: RMMP=100 :: RMP=100 :: RA=5 :: RD=5 :: RMA= 8:: RMD=10
3 MLEV=7 :: MMHP=100 :: MHP=100 :: MMMP=40 :: MMP=40 :: MA=5 :: MD=5 :: MMA=3 :: MMD=5
4 SLEV=5 :: SMHP=100 :: SHP=100 :: SMMP=50 :: SMP=50 :: SA=4 :: SD=4 :: SMA=3 :: SMD=6
5 CHAR$="BERYL" :: BMOV=0 :: RMOV=0 :: MMOV=0 :: SMOV=0 :: COUNT=0

REM **THESE ARE THE STATISTICAL VARIABLES FOR SKELETON
6 SKHP=100 :: SKMP=100 ::SKMMP=100 :: SKMP=100 :: SKA=5 :: SKD=5 :: SKMA=5 :: SKMD=5

REM **DISPLAY HP ONSCREEN

100 CALL CLEAR :: CALL SCREEN(13)
110 DISPLAY AT(2,:"BATTLE TEST";
120 DISPLAY AT(3,1):"BERYL HP";
130 DISPLAY AT(3,18):BHP
140 DISPLAY AT(4,1):"REPTOSLICER HP";
150 DISPLAY AT(4,18):RHP
160 DISPLAY AT(5,1):"MARKUS HP";
170 DISPLAY AT(5,18):MHP
180 DISPLAY AT(6,1):"SKYLAR HP";
190 DISPLAY AT(6,18):SHP
191 DISPLAY AT(12,1):"SKELETON HP";
192 DISPLAY AT(12,18):SKHP
200 DISPLAY AT(19,1):"YOUR TURN:"
210 DISPLAY AT(21,1):"A=ATTACK  M=MAGIC  D=DEFEND"

REM **START BATTLE SEQUENCE

300 COUNT=COUNT+1
301 IF COUNT>4 THEN COUNT=1
305 IF COUNT=1 THEN CHAR$="BERYL" :: IF COUNT=2 THEN CHAR$="REPTOSLICER"
306 IF COUNT=3 THEN CHAR$="MARKUS" :: IF COUNT=4 THEN CHAR$="SKYLAR"
307 DISPLAY AT(20,1):CHAR$

308 GOTO 308
.
.
.
.
.

 

That's it for now... hope you can make some sense of this... there's no "battle engine" in this code, but I'll post that as soon as I get it operational. Thanks... and Codex, Adamantyr... if you're watching... I need some direction here fellas. =) I know jack about battle engine algorithms for an RPG. =)

 

 

[Opry99er]

Alright guys, here's the rough and tough, bare bones concept engine. This is just an outline for testing out different "result" algorithms for magic and attack. For the time being, all you can do is pick attack, magic, or defend--- of which, "DEFEND" does nothing yet, as the skeleton does not attack you yet. In any case, your magics and attacks are based on a few variables... your player's "LEVEL," your player's "ATTACK" variable, and your player's "MAGIC ATTACK" variable. I commented fully, so it should all be pretty self-explanatory. Enjoy.

 

REM **THESE ARE THE STATISTICAL VARIABLES FOR THE PC'S
REM **MAX HP, HP, MAX MP, MP, ATTACK, DEFEND, MACIC ATTACK ,MAGIC DEFEND, DAMAGE INFLICTED ON TURN
REM ** B=BERYL, R=REPTOSLICER, M=MARKUS, S=SKYLAR
REM ** SK=SKELETON (THE ENEMY)

1 BLEV=10 :: BMHP=100 :: BHP=100 :: BMMP=50 :: BMP=50 :: BA=7 :: BD=7 :: BMA=4 :: BMD=6 :: BDAM=0
2 RLEV=11 :: RMHP=100 :: RHP=100 :: RMMP=100 :: RMP=100 :: RA=5 :: RD=5 :: RMA= 8:: RMD=10 :: RDAM=0
3 MLEV=7 :: MMHP=100 :: MHP=100 :: MMMP=40 :: MMP=40 :: MA=5 :: MD=5 :: MMA=3 :: MMD=5 :: MDAM=0
4 SLEV=5 :: SMHP=100 :: SHP=100 :: SMMP=50 :: SMP=50 :: SA=4 :: SD=4 :: SMA=3 :: SMD=6 :: SDAM=0
5 CHAR$="BERYL" :: BMOV=0 :: RMOV=0 :: MMOV=0 :: SMOV=0 :: COUNT=1 :: PDAM=0
6 BMOV$="" :: RMOV$="" :: MMOV$="" :: SMOV$=""

REM **THESE ARE THE STATISTICAL VARIABLES FOR SKELETON

7 SKMHP=500 :: SKHP=500 :: SKMP=100 ::SKMMP=100 :: SKMP=100 :: SKA=5 :: SKD=5 :: SKMA=5 :: SKMD=5 :: SKDAM=0

REM **DISPLAY HP ONSCREEN

100 CALL CLEAR :: CALL SCREEN(13)
110 DISPLAY AT(2,:"BATTLE TEST";
120 DISPLAY AT(3,1):"BERYL HP";
130 DISPLAY AT(3,18):BHP
140 DISPLAY AT(4,1):"REPTOSLICER HP";
150 DISPLAY AT(4,18):RHP
160 DISPLAY AT(5,1):"MARKUS HP";
170 DISPLAY AT(5,18):MHP
180 DISPLAY AT(6,1):"SKYLAR HP";
190 DISPLAY AT(6,18):SHP
191 DISPLAY AT(12,1):"SKELETON HP";
192 DISPLAY AT(12,18):SKHP
200 DISPLAY AT(19,1):"YOUR TURN:"
210 DISPLAY AT(21,1):"A=ATTACK  M=MAGIC  D=DEFEND"

REM **START BATTLE SEQUENCE

300 IF COUNT>4 THEN GOSUB 5000
305 IF COUNT=1 THEN CHAR$="BERYL"
306 IF COUNT=2 THEN CHAR$="REPTOSLICER"
307 IF COUNT=3 THEN CHAR$="MARKUS" 
308 IF COUNT=4 THEN CHAR$="SKYLAR"
309 DISPLAY AT(20,1):CHAR$

REM ** TIGHT LOOP

310 CALL KEY(0,K,S)
315 IF S=0 THEN 300
320 IF K=65 THEN GOSUB 1000
321 IF K=77 THEN GOSUB 2000
322 IF K=68 THEN GOSUB 3000
330 GOTO 300

REM ** ATTACK IS SELECTED, THIS DETERMINES WHAT DAMAGE YOU INFLICT

1000 IF COUNT=1 THEN BMOV=(BA+BLEV)*2
1001 IF COUNT=2 THEN RMOV=(RA+RLEV)*2
1002 IF COUNT=3 THEN MMOV=(MA+MLEV)*2
1004 IF COUNT=4 THEN SMOV=(SA+SLEV)*2
1005 IF COUNT=1 THEN BMOV$="ATTACK" 
1006 IF COUNT=2 THEN RMOV$="ATTACK"
1007 IF COUNT=3 THEN MMOV$="ATTACK"
1008 IF COUNT=4 THEN SMOV$="ATTACK"
1009 COUNT=COUNT+1
1020 RETURN

REM **MAGIC IS SELECTED, THIS DETERMINES WHAT DAMAGE YOU INFLICT

2000 IF COUNT=1 THEN BMOV=(BMA+BLEV)*2
2001 IF COUNT=2 THEN RMOV=(RMA+RLEV)*2
2002 IF COUNT=3 THEN MMOV=(MMA+MLEV)*2
2004 IF COUNT=4 THEN SMOV=(SMA+SLEV)*2
2005 IF COUNT=1 THEN BMOV$="MAGIC"
2006 IF COUNT=2 THEN RMOV$="MAGIC"
2007 IF COUNT=3 THEN MMOV$="MAGIC"
2008 IF COUNT=4 THEN SMOV$="MAGIC"
2009 COUNT=COUNT+1

2020 RETURN

REM **DEFEND IS SELECTED, THIS DETERMINES YOUR "DEFEND" VARIABLE VALUE

3000 IF COUNT=1 THEN BMOV=(BD+BLEV)*-2
3001 IF COUNT=2 THEN RMOV=(RD+RLEV)*-2
3002 IF COUNT=3 THEN MMOV=(MD+MLEV)*-2
3004 IF COUNT=4 THEN SMOV=(SD+SLEV)*-2
3005 IF COUNT=1 THEN BMOV$="DEFEND"
3006 IF COUNT=2 THEN RMOV$="DEFEND"
3007 IF COUNT=3 THEN MMOV$="DEFEND"
3008 IF COUNT=4 THEN SMOV$="DEFEND"
3009 COUNT=COUNT+1
3020 RETURN

REM **ALL PLAYERS HAVE SELECTED THEIR MOVE---THIS SHOWS RESULTS OF YOUR TURN
REM **THEN CHECKS FOR SKELETON'S "ALIVE OR DEAD", THEN GOES TO THE BEGINNING FOR THE NEXT TURN

5000 DISPLAY AT(15,1):"BERYL"
5010 DISPLAY AT(15,14):BMOV$;
5020 FOR I=1 TO 800 :: NEXT I
5030 DISPLAY AT(15,1):"REPTOSLICER"
5040 DISPLAY AT(15,14):RMOV$;
5050 FOR I=1 TO 800 :: NEXT I
5060 DISPLAY AT(15,1):"MARKUS"
5070 DISPLAY AT(15,14):MMOV$;
5080 FOR I=1 TO 800 :: NEXT I
5090 DISPLAY AT(15,1):"SKYLAR"
6000 DISPLAY AT(15,14):SMOV$;
6009 FOR I=1 TO 800 :: NEXT I
6010 PDAM=BMOV+RMOV+MMOV+SMOV
6012 DISPLAY AT(14,5):"TOTAL DAMAGE"
6013 DISPLAY AT(14,20):PDAM
6015 FOR I=1 TO 800 :: NEXT I
6016 SKHP=SKHP-PDAM
6017 IF SKHP<0 THEN GOSUB 10000
6020 COUNT=1 :: GOTO 100

REM **SKELETON IS DEAD, END THE SIMULATION

10000 CALL CLEAR :: PRINT "SKELETON DEAD" :: FOR I=1 TO 800 :: NEXT I :: END

 

 

[sometimes99er]

Please let me email you some other little characters I've made, and then I can animate one, either as a possible hero for Atariventure, or whatever. (I've been a fan of your demos for years, so I'd be honored. )

Absolutely, please email me or attach (like png or gif) to the Atariventure thread. PSP6 starts in a blink of an eye on my quad-core. I wouldn't go back (to PSP4), but changes in UI might annoy you. I think I have to take a look at PSP8 since it has ability to control most elements via scripts/macros. And I'm honored to have a fan !

 

[sometimes99er]

The situation with one or more sprites being displaced in relation to one another is something I've been giving some thought too. This might happen more than I like to know.

I want to cram as much in each 16x16 box as I can, so that's why I often design sprites displaced like that. I don't know how much of a hassle it is to a programmer, but to an artist, it's great!

 

I guess UnderExtended does what I would do anyway, and that's using a "proper" paint program, then break it apart and convert the bits (for which I'll be using my own Grapefruit).

Yes, I've been using Paint Shop Pro 4 for many years. But then getting the hex values is usually agony for me because all my old computer can run (at least, of what I've been able to find to download) is a simple 8x8 Character Grid Converter. So I am VERY interested in trying Grapefruit, and all the other utilities you guys have made -- if I can ever tear myself away from "Old Betsy" and get my "new" (only three years old!) computer set up!

And you should. I know I would. Why limit yourself, when the hardware allows for it. It's just that my Beryl sprite designer has taken off with all the multilayered sprites in the same position. I'll give it some more thought. Having 4 more or less independent sprite layers and have them reallocate for each frame in an animation is not impossible. Do you have AnimationShop ? If one creates a new animation with width and height set at 32, custom colors set to the TI-99/4A etc. Creation and animation would be "easy". You just have to remember to limit each sprite to the size of 16x16. Then the output gif file could be sent to a analyzer for conversion. Output would be like patterns, colors, positions, frames and time. The clever reuse of layers, in different colors and/or at different positions, with or without pixels overlaying, well ... Maybe I'll be turning my face back to PSP6 again.

 

Grapefruit requires .NET. Patterns and Beryl just requires a browser. Codex's utilities requires Java. And yes, there are more utilities out there for the 9918. And then I guess someone else would convert for you in whatever project.

 

[Opry99er]

So, here's the rub.... I'm taking one of these elements at a time. First, I am

thinking about an "Attack" algorithm... What is acceptable? How do I create a meaningful set of equations using the variables I am currently tracking? I don't know exactly how to manipulate the variables to achieve a believable or useful result, so at the moment, I am just using the characters LEVEL and ATTACK statistics added together and multiplied by two. The equation is probably not efficient or even a very good way to determine the attack result. This is there just as a place filler until I figure out how to manipulate the variables. Anyone have some suggestions for this one?

[sometimes99er]

So, here's the rub.... I'm taking one of these elements at a time. First, I am

thinking about an "Attack" algorithm... What is acceptable? How do I create a meaningful set of equations using the variables I am currently tracking? I don't know exactly how to manipulate the variables to achieve a believable or useful result, so at the moment, I am just using the characters LEVEL and ATTACK statistics added together and multiplied by two. The equation is probably not efficient or even a very good way to determine the attack result. This is there just as a place filler until I figure out how to manipulate the variables. Anyone have some suggestions for this one?

Actually I have no idea.

 

Maybe "character level change" boosts Attack and Defence. Don't know if this makes it easier to handle things, if you like travel "too quickly" to the next world.

 

How about something like this:

 

Damage = Attack (50%-90%) + Magic Attack (30%-70%) - Defend (40%-90%) - Magic Defend (20%-70%)

 

Parentheses hold prediction of dice roll.

 

[Opry99er]

Thanks Karsten--- I will be "weight"ing these variables as I read more about the AD&D conventions and determine what I want for the game.... Since each type of player move is seperate (Attack, Magic Attack, Defend, etc), each move will use a different set of variables and a different set of equations to determine the desired result. As of now, you can kill the skeleton using attack and magic-- and he cannot fight back. Give me a few days, I'll have a full battle engine ready to be tested.

 

(edit)

 

and yes--- the player's Crucial stats like Attack and Defend and Magic Attack, etc, will raise incrementally with the level of said character. There are other elements as well--- like a badass sword for MARKUS will raise his attack stat even if his level does not change... That kind of thing.

Edited July 4, 2010 by Opry99er

[Opry99er]

I have been doing some research on how battle sequences are handled in other RPGs... I found some very interesting stuff on the original Final Fantasy game for the NES. I've attached the document here.... The information contained in the document is quite interesting, but the actual format of the document is amazing!!! I think I'll need to get a format like this going for my development doc soon. =)

FFvariables.zip

[Opry99er]

Well, here we go... the first real mockup for the battle screen. Worked this up in XB and the rough engine is listed above... Please enjoy, and I'd love to hear some comments/critiques. Would this be a usable battle screen? Would you like to see any different information displayed during the pre-battle sequence? In the development document I posted recently, I explain that the box on the bottom will contain many different pieces of info. You can select any of the displayed options and then that box is replaced with the selected information. Sub-menus are already designed and laid out--- so I'll do up a couple of these and post them too. =)

 

 

 

(edit)

 

Damn... left out the SPELLS option.... I'll have to re-do this thing

Edited July 5, 2010 by Opry99er

[Bill Loguidice]

Looks like a very logical layout to me. I assume you'll have a limited animation sequence when they carry out the action item, right? In other words you'll show an attack state once all the orders are entered and the statistical sequence is carried out. If so, you may wish to use that second state when the character in question is being given the order, then turn it back to the wait state when another character is being ordered. This would be a way to show which character is being ordered and you wouldn't have to do much additional programming (like putting a black bar under the character when it's the one being given the order).

[Opry99er]

Yea man... Good stuff!! The red cursor to the side of the character's name shows who is being ordered. Also, the name of the current character is displayed in the action box--- "Beryl" in this case. But I like your idea of maybe moving the character representation forward (towards the enemy) while setting the next move. . Good stuff!

[Opry99er]

Here's a better design... I like this better anyway because the box will not need to be re-sized to facilitate the item menu or the magic menu. =)

 

[Opry99er]

Here's one with the suggested change... Well, almost... here I just moved Beryl up one character position, rather than his animated self. Each character will have 2 definitions, one standard, and one "ATTACK". What you do not see yet is the arrow cursor which will be used to select which enemy you will be attacking... or 3 cursors if it's a magic which hits ALL enemies. =)

 

[Opry99er]

Just found the entire Final Fantasy 3 battle algorithm list. It's pretty intense!!! If you all have any interest, I'll post it. It's about 10 pages long. . Anyway, I'm straying away from the AD&D battle methodology, ad it's really designed around the paper and pencil RPGs with dice.... The math is bizarre!!! I'll have updated battle code soon.... With some randomization and more believable attack and magic damage. This is pretty tough stuff here--- alot more hardcore than anything else so far. But I'm learning

[Opry99er]

So... here's the equation of the day... This is the one causing me so much grief. =) This is the attack algorithm for Beryl and his crew. First, let me post in full what variables I am tracking for each character...

 

LEV--character's "level" (beginning at 1, maxing at 30)

MHP--max HP

HP---current HP

MMP--max MP

MP---current MP

A---player's "ATTACK" statistic

D---player's "DEFEND" statistic

MA-player's "Magic ATTACK" statistic

MD-player's "Madic DEFEND" statistic

 

So, what I am trying to accomplish (first) is develop a properly weighted algorithm which will determine the damage caused by this character... Here's the most basic and unweighted equation I can think of... Let's assume that YOU are player A, and player B is a skeleton.

 

DAMAGE=ALEV+AA-BD

 

All this is doing is adding your current level to your attack statistic and subtracting the skeleton's defend statistic from it. This, of course, is not adequate and is a very crappy algorithm... But you can see what I need here... perhaps a multiplier?

 

DAMAGE=(ALEV+AA)*2-BD*2

 

Anyway, this is the issue at hand. I've been studying several games and their math, trying to find a comfortable sliding scale for enemy damage... but most use many more variables than I am currently tracking... Of course I could add some variables.... I'm curious to know if there is a formula somewhere OTHER than D20 or the AD&D conventions which seem somehow inadequate in a computer RPG environment.... The Final Fantasy battle sequence (from FFIII) is extremely complex and multi-layered... but I may have to figure out how to clone it... I really like the feel of that one... Codex, is your ToDR engine up anywhere to look at? I'm quite interested to see how you handled the damage algorithms for standard ATTACK. =)

 

That's it for now.. just looking for some kind of cheap quick algorithm using my currently tracked variables to START with.... then I will massage it as I move forward... I'm also interested to know whether you all think I need to be tracking more variables, to create a more diverse/accurate battle algorith... Keep in mind that these equations do not factor in %CHANCE of a hit... This will be a seperate equation. =) Thanks in advance for your help

[Opry99er]

Here's my current issue I'm working on... A believable battle algorithm to determine "amount of damage" to your enemies. First, I'll list the variables I'm tracking for the (P)layer ©haracters.

 

LEV---Level

MHP--Max HP (Health points)

HP----HP

MMP--Max MP (Magic points)

MP---MP

ATK----Attack

D----Defend

MA--Magic Attack

MD--Magic Defend

 

So, here's a possible algorithm to determine amount of damage. First, let's state that ATK goes up once per level up, and it also goes up depending on equipment and spells, etc... We can always be assured that ATK will be higher than LEV. Now, let's also say that DEF or "D" also goes up once per level and is also modified in the same ways. This will mean that ATK and D will be similar numbers... probably not exactly the same, but close. Of course, Beryl will start with a higher ATK than Skylar, and she will start with higher "D"... But for the current example, we're just discussing three variables...

 

LEV (level)

ATK (attack)

D (defend)

 

 

Let's say you're character A, and your enemy is a skeleton... character B. How do we determine the amount of damage? Here's an idea... still very primitive.

 

DAMAGE=(ALEV*10)+(AATK*5)-BD*2

 

Let's try this out a few times.

 

1) Let's say you (player A) are at a level 5 with an attack of +10. Player B has a defense stat of 10. Assuming that you score a hit, your total damage is (50)+(50)-(20), giving you a total damage of 80.

 

2) Let's say you have a level of 10 and an attack rating of +15. (ALEV=10, AATK=15) Your enemy has a defense stat of 20 (BD=20). So, your total damage would be (100)+(45)-(40), making the damage total 105.

 

3) In this scenario, player A will have stats of ALEV=15, AATK=+25 and Player B has a defense statistic of +30 (BD=30). This equation will kick out the following numbers. (150)+(125)-(60)=215.

 

In these equations, I have intentionally weighted LEV above both ATK and DEF stats. It seems to hold up, but I'm sure there are other ways to achieve these results, and maybe more efficient ways. What do you think?

Edited July 9, 2010 by Opry99er

[+adamantyr]

Let's say you're character A, and your enemy is a skeleton... character B. How do we determine the amount of damage? Here's an idea... still very primitive.

 

DAMAGE=(ALEV*10)+(AATK*5)-BD*2

 

First question, why are you multiplying everything? You'll find in assembly language especially that every single operation is another line at least of code. And if they're not base 2 numbers, then you have to use the MPY opcode, which takes two registers and a not-insignificant number of cycles.

 

I ran into this studying both old school games and CRPG's derived from them. A love of derived figures, rather than direct ones. Everything is multiplied, averaged, etc. to get a figure, and almost none use the base values, which were typically ability scores.

 

Why? I think it's because there was a real drive to "simulate" reality as much as possible. The ability to hit something has a lot of potential abstractions, and they just couldn't accept the idea of a static number. No no, not realistic at all! Ability to hit has to be a measure of strength, coordination, and skill! And thus we get these over-complicated formulas.

 

Your base idea on the algorithm is sound, it's this: DAMAGE = (LEVEL + ATTACK) - TARGET_DEFENSE

 

So, what you want to do is, look at how you want the numbers to progress to keep this in a suitable area.

 

Level is pretty constant, you'll want to check figures at first level, maximum level, and somewhere in-between. Do monsters have levels? Do they NEED them? Unless you can fight level 1 or level 5 goblins, you can just have a single attack value for monsters.

 

Attack varies by the weapon and party member, I assume, so this is where you differentiate between the different players.

 

Finally, you should consider what happens when calculated damage is below zero, will you cap it at 1 point minimum or 0?

 

Adamantyr

[Opry99er]

I have thought a bit about this--- and it will not happen much, if at all, from PC to enemy... Enemy attacks on the PC may end up as a negative number, and I will cap that at "0". I weighted these varaibles partly to prevent this issue. There are other reasons as well, but you know a hell of alot more about RPGs and battle engines than I do. Question for you, though--- is the loss of cycles really a big deal? How much time are we talking about? 8th of a second? Quarter second? Much less? Much more? I'm wondering if the speed loss is enough to change the simplicity of the formula. MPY.... Will it slow my game

down enough for it to matter in a loop

of a KSCAN read, a couple "LI"s, an MPY and a VDP write? I just don't know... I'm legitimately curious. I look forward to hearing your response, and thanks for responding.

Edited July 10, 2010 by Opry99er

[+adamantyr]

I have thought a bit about this--- and it will not happen much, if at all, from PC to enemy... Enemy attacks on the PC may end up as a negative number, and I will cap that at "0". I weighted these varaibles partly to prevent this issue. There are other reasons as well, but you know a hell of alot more about RPGs and battle engines than I do. Question for you, though--- is the loss of cycles really a big deal? How much time are we talking about? 8th of a second? Quarter second? Much less? Much more? I'm wondering if the speed loss is enough to change the simplicity of the formula. MPY.... Will it slow my game

down enough for it to matter in a loop

of a KSCAN read, a couple "LI"s, an MPY and a VDP write? I just don't know... I'm legitimately curious. I look forward to hearing your response, and thanks for responding.

 

It's not so much the cycle cost as the memory. Coming from Extended BASIC and languages like C/C++, you don't think much about formulas with parenthesis and multiple operations going on. But in assembly... you got to do them ALL.

 

As for how fast cycles are, you'd have to do several hundred MPY's before you start breaking the 1/60 mark. None of the attack/defense code here is going to even be noticeable from a human speed perspective.

 

The idea here is economy of numbers. If you never do anything with a given value other than multiply it before adding it to something else, why not just store it at the value so no operation is needed at all?

 

Adamantyr

[Opry99er]

That makes sense for ATK and DEF, but what about level? The character cannot start at a level 10 and then be at a level 20 upon level up.... If I use "1" for level and then add it to an ever-growing ATK stat, then level really won't matter un battle. I suppose that ATK could simply go up on a grand scale each level up.... For instance

 

IF LEV=1 THEN ATK=60 :: IF LEV=2 THEN ATK=90 :: IF LEV=3 THEN ATK=110
.
.
.
.
DAMAGE=AATK-BDEF

 

this takel level completely out of the equation, but it may simulate what would happen if I WAS using it. Then it's just ATK-DEF essentially. It takes a certain dynamic out of the formula though. You're correct about the difficulty of each parenthetical segment of the algorithm.... In assembly, there is no way to do it easily.... But once the formula is written, it needs only to be JMPed to or BLed. I imagine that older RPGs which were written in assembly (like Ultima for the C64) used this style of algorithm.... When you search for examples of battle engines, 90% of them use an engine which works this way. As you said, it is probably to simulate "reality." Well, in my CRPG playing experience, that is how I typically gauge a good battle engine.... When an attribute is increased, it should dynamically and infallably be reflected in several areas of the game, DAMAGE being one of them. I agree with you that a simple static formula (no MPY to determine DAMAGE) would be simple and efficient.... But to achieve the kind of results we see in, say, the Final Fantasy series or "Elven Chronicles," I don't see how to do it without a formula which does something similar to this one. I'm not saying my equation is great, or even good.... But I still want the battles in this game to feel "right." And "right" to me may be totally different from "right" to a paper and pencil player, or even someone who played the Gold Box games. Perhaps you could help make this clearer to me... I'm very green with this stuff, and I may be missing a larger point here. I don't mind the work to achieve my desired results, but if there is a better way to get to "point B", then I am eager to learn. Thanks again for lending me your expertise.

[+adamantyr]

That makes sense for ATK and DEF, but what about level? The character cannot start at a level 10 and then be at a level 20 upon level up.... If I use "1" for level and then add it to an ever-growing ATK stat, then level really won't matter un battle.

 

Well, is level EVER used as its straight value, other than the display to indicate the level of the character? You could just store it as 10, 20, etc. and divide by 10 before displaying it on screen. Also, where do weapons come into the picture? Are they a straight addition to the attack value? What about the character class, does he have a base ability, or does he go up faster or slower than other classes? Finally, why are attack/defense so high? Why not make them 1, 2, etc.?

 

As for the interplay of attributes, keep in mind that a set of abilities that have a synergistic effect becomes harder to test, and also more likely to produce unexpected results. Also, keep in mind that for many players, these effects will not be easily discernible unless the difference is significant.

 

Here's an issue with CRPG's that can be tricky to solve: the effect of armor on attacks and damage. Does armor just make it more likely for the attack to miss, like in D&D, or does it actually reduce the amount of damage taken, like in Rolemaster? WoW uses a VERY complicated formula to calculate a ratio based upon the level of the attacker and the level of the defender, which is why high-level cloth-wearers don't get slaughtered by low level monsters, even though their armor value is low. The problem with straight "armor reduces damage by N" formula is that it means characters with high armor, like fighters, take really minuscule damage and low armor characters get pasted no matter how advanced they are. Unless you include level into it, of course.

 

The important thing is to use a tool like a spreadsheet and plot out your number curves based on your formulas. Get a good idea of how YOU want the party to progress in power. Remember that monsters have way more attacks than players, so if you make it a level playing field, it's much more difficult.

 

Adamantyr

[Opry99er]

Great questions, and quite stimulating, actually. I approached each of your questions one by one, but these aren't in order.

 

1) Armor... Armor will have no effect on whether an attack is successful or not... hits will happen based on level, experience, agility, etc... AGI and EXP have no place in the damage equation. In real life combat, if you swing your weapon at an enemy with awesome armor, the chance of "hit or not" doesn't change. You might do zero damage, but you still achieve a hit.

 

2) Classes... I've thought about this and (even though hardcore RPGers would hate me for this) I don't think setting up different equations for each "class" is necessary. Markus (for example) is a "Fighter," so his base ATK and DEF are high, but MAG is quite low. Their increases that happen by LEV increase will be uniform for each character, but their BASE numbers are different. This way, I can "set it and forget it," so to speak. If this doesn't make sense, let me know and I'll try to be a bit more specific

 

3) Weapons... a higher level weapon will increase ATK and in some cases, AGI. A super badass heavy steel sword will increase ATK, but might decrease AGI.... If I was doing this in a higher level language, I would have pages and pages of code dealing with all this stuff... having read the extensive battle/item document from Final Fantasy III. Here, though... it'll just have to depend on what's left over, "space-wise" when the majority of the battle engine gets closer to complete...

 

4) Higher numbers... Well, if we go with a straight number thing... DAMAGE=ALEV+AATK-BDEF, your inflicted damage will be like "6" or "7". I'm not cool with that. Larger numbers allow for more differentiation between individual attacks, you see. However... from your last post, I've been doing some contemplating and I have a question for you...

 

 

 

First, if we keep all the numbers HIGH and then divide to show on the screen, then high numbers are necessary. If we keep "DAMAGE" numbers low and then multiply them for the character to see, then we always have even numbers... (6 becomes 600 or 5 becomes 500)... This isn't a HUGE deal, but it isn't what I'm looking for. So, I can do my original thing and multiply LOWER numbers to achieve a higher number... or I can keep LEV high (like 20, 30, 40) but divide it for screen display. Then, as far as ATK and DEF, they will have to be incremented at a similar pace to one another to keep things copacetic. So, here is an example of each method

 

*Let's say we keep the stats LOW:

 

ALEV=1, AATK=5, BDEF=6

 

Direct use of the low nuber equation::

ALEV+AATK-BDEF=DAMAGE  (1+5-6=0) 

 

Original idea (internal multiplication) equation::

(ALEV*10)+(AATK*5)-(BDEF*2)=DAMAGE	(10+25-12=23) 

 

*What if the stats are high to start with and we simply DIV the LEV to display it on screen

 

ALEV=20, AATK=AATK=30, BDEF=40

 

Direct use of the high number equation::

ALEV+AATK-BDEF=DAMAGE (20+30-40=10) 

 

So... we can do ALL of these, technically... but without weighting DEF and ATK differently, you'll get alot of "zero" or "negative" DAMAGE... By weighting AATK by multiplying it by 5 and BDEF by multiplying by 2, you can just about guarantee that IF there is a hit, it will be a positive number, and typically an average percentage of HP... This can... of course, be achieved simply by incrementing these variables in memory as I go... and not at the point of battle. If one goes from a level 2 to a level 3, then their attack doesn't go from 5 to 6... It will go from 25 to 30. I'll just have to increase the ATK levels more rapidly than the DEFs. Great points there, man.

 

Each enemy will have HP, MP, ATK, DEF, MATK, and MDEF pre-determined for them before the game is even turned on, so THAT coupled with WHERE and WHEN they are going to be encountered throughout the course of the game should give me a pretty steady engine... But, I may be totally talking out of my ass. Your points are very valid and I'm currently re-thinking the methodology here. Thanks!

Edited July 11, 2010 by Opry99er

[+adamantyr]

1) Armor... Armor will have no effect on whether an attack is successful or not... hits will happen based on level, experience, agility, etc... AGI and EXP have no place in the damage equation. In real life combat, if you swing your weapon at an enemy with awesome armor, the chance of "hit or not" doesn't change. You might do zero damage, but you still achieve a hit.

 

So armor is basically damage reduction, that's fine. The old 3rd edition of GURPS had armor with two ratings, Damage Resistance (DR) and Passive Defense (PD). Your PD would add to your active defenses, and DR would be subtracted from any damage suffered. Rolemaster does this as well, although heavier armors start impacting speed in initiative, ranged weapon attacks, etc.

 

2) Classes... I've thought about this and (even though hardcore RPGers would hate me for this) I don't think setting up different equations for each "class" is necessary. Markus (for example) is a "Fighter," so his base ATK and DEF are high, but MAG is quite low. Their increases that happen by LEV increase will be uniform for each character, but their BASE numbers are different. This way, I can "set it and forget it," so to speak. If this doesn't make sense, let me know and I'll try to be a bit more specific

 

That works out fine. In fact, it's way easier if classes are only differentiated by different base values. Then you don't have to do any special programming to track things, everybody uses the same advancement system. However, be sure that at the max level, the different base values are still significant. If a fighter has a +10 ATK bonus over a magic-user, but level*10 is added each level, then does 200 vs. 210 really matter?

 

3) Weapons... a higher level weapon will increase ATK and in some cases, AGI. A super badass heavy steel sword will increase ATK, but might decrease AGI.... If I was doing this in a higher level language, I would have pages and pages of code dealing with all this stuff... having read the extensive battle/item document from Final Fantasy III. Here, though... it'll just have to depend on what's left over, "space-wise" when the majority of the battle engine gets closer to complete...

 

Ah ha... see, this is one of those sticky situations I was talking about. If AGI adds to your ability to hit, and a weapon can potentially reduce your AGI, you create a situation in which it's possible for a weapon to actually make it HARDER to hit.

 

Also, keep in mind that if you're planning on having the attributes be recalculated for every hit, you'll have to track all temporary changes as well as permanent. For games in assembly, a good solution to reducing the amount of calculations is to store adjusted values as well as base ones for quicker fetching. If a character's AGI is reduced by a weapon, you only have to do that change WHEN he equips the weapon, or removes it.

 

Another example of the system creating an unexpected problem is in classic AD&D with the fighter and cleric classes. Fighters level advancement started at 2,000 per level, where the cleric was 1,500 per level. If two players played the same amount of time and got the same XP, the cleric would reach 3rd level by the time the fighter reached 2nd, and have a HIGHER attack bonus as a result. It's one of those things that only comes up if you actually test through the numbers.

 

First, if we keep all the numbers HIGH and then divide to show on the screen, then high numbers are necessary. If we keep "DAMAGE" numbers low and then multiply them for the character to see, then we always have even numbers... (6 becomes 600 or 5 becomes 500)... This isn't a HUGE deal, but it isn't what I'm looking for. So, I can do my original thing and multiply LOWER numbers to achieve a higher number... or I can keep LEV high (like 20, 30, 40) but divide it for screen display. Then, as far as ATK and DEF, they will have to be incremented at a similar pace to one another to keep things copacetic. So, here is an example of each method

 

*Let's say we keep the stats LOW:

 

ALEV=1, AATK=5, BDEF=6

 

Direct use of the low nuber equation::

ALEV+AATK-BDEF=DAMAGE  (1+5-6=0) 

 

Original idea (internal multiplication) equation::

(ALEV*10)+(AATK*5)-(BDEF*2)=DAMAGE	(10+25-12=23) 

 

*What if the stats are high to start with and we simply DIV the LEV to display it on screen

 

ALEV=20, AATK=AATK=30, BDEF=40

 

Direct use of the high number equation::

ALEV+AATK-BDEF=DAMAGE (20+30-40=10) 

 

So... we can do ALL of these, technically... but without weighting DEF and ATK differently, you'll get alot of "zero" or "negative" DAMAGE... By weighting AATK by multiplying it by 5 and BDEF by multiplying by 2, you can just about guarantee that IF there is a hit, it will be a positive number, and typically an average percentage of HP... This can... of course, be achieved simply by incrementing these variables in memory as I go... and not at the point of battle. If one goes from a level 2 to a level 3, then their attack doesn't go from 5 to 6... It will go from 25 to 30. I'll just have to increase the ATK levels more rapidly than the DEFs. Great points there, man.

 

Each enemy will have HP, MP, ATK, DEF, MATK, and MDEF pre-determined for them before the game is even turned on, so THAT coupled with WHERE and WHEN they are going to be encountered throughout the course of the game should give me a pretty steady engine... But, I may be totally talking out of my ass. Your points are very valid and I'm currently re-thinking the methodology here. Thanks!

 

Have you ever played a classic pinball game? If so, you may have noted that scores on pinball machines tend to be... very high. You usually score points in the millions with one ball, and bonus lives and games are offered in the hundreds of millions ranges. A crappy score is under a million. This is because people really get excited about big numbers... if you were getting scores of a few dozen points, it's like, meh. Who cares?

 

However, with games, it's really important to understand that only significant differences matter. You have a fair amount of numbers to play with in a 16-bit register (0 to 65535) but before you start breaking overflows and storing stuff in 4 bytes, think about if you REALLY need big values. Floating point numbers, for example, never store LITERAL values on a computer. They only store the significant digits that are viewable. On the TI-99/4a, for example, you can store up to 14 digits, and a power value to indicate where the decimal point is.

 

Concerning your formula differences, the trick there is that IF the ratio you want means attack should be 5 times larger, and defense 2 times larger, then why not have them that high to start? Why do you need them at their original size at all? Will they ever get used anywhere else?

 

Let's start afresh here... post a list of the primary attributes you want in the game. These are attributes all characters will have, and are inherent.

 

Then, post a list of your secondary attributes, these are the values you derive from a combination of the primaries and other external factors.

 

Adamantyr

[Opry99er]

I did this in the example XB code I posted, but not to the specificity you are asking for... so, let's begin at the beginning to give everyone (especially myself) a clearer understanding of what's up with this battle algorithm. This post will deal with the primary attributes only.

 

MAIN PARTY CHARACTERS:

Primary attributes:

 

LEV (level)

MHP (max hp)

HP

MMP (max mp)

MP

XP (experience points)

ATK

DEF

AGI

MATK (magic attack)

MDEF (magic defend)

 

ENEMIES:

Primary attributes:

 

LEV (yes, an enemy level... I will use this to make sure parity occurs between your party and the enemies)

MHP (max HP)

HP

ATK

DEF

MATK

MDEF

 

WEAPONS:

ATK

HVY

 

With these primary attributes, I think we have enough to go by... Of course it's possible I missed a crucial element. It's late and I'm tired. =) Look okay to you Adam? Perhaps you could help me with the secondary attributes--- what they are, how to handle them. Thanks again, man

Edited July 11, 2010 by Opry99er