adamantyr
-
Content Count
1,852 -
Joined
-
Last visited
Posts posted by adamantyr
-
-
Hey adamantyr, question for you. How "complex" a game was TI-TREK? This current game I'm working on is pretty simple--- I imagine once the font is in and the treasure chests--- the multiple levels, etc., I imagine the game will be twice this size. However since level changes won't be much more than a difference in water height, water color, enemy graphics, and speed, they won't add much complexity. Arcade games are easier to design than other types of games, I've learned....
TI-Trek was a great example of very bad BASIC programming, actually.
A great deal of the program was haphazardly organized. Maybe the original writer had some grand overarching scheme to his placement of code, but if it was there, I couldn't see it. I just saw a lot of spaghetti logic and GOTO's where there was no real call for it.
Converting the graphics was easy... practically a copy and paste job. The sounds were a little more difficult to replicate, because some of them were using loops and decimal mathematics to determine the sound to play. Assembly language is better with iterative sound lists, so I ended up "faking" it a bit.
The parser for entering commands and directions was probably the most complicated bit of code, as most parsers are. That's one reason I decided not to use any parsers at all in my CRPG; way too much error-checking. Utilizing the mathematical functions wasn't too bad, the process is fairly clear in the E/A manual. These days, I'd have found a way to use integers instead, because mathematical accuracy isn't necessary for the scope of the game.
Adamantyr
-
Code has been broken down even further into very small chunks, mostly 2-3 instructions per REM statement. I am beginning to see how simple this could really be in assembly. =) Register usage makes so much sense... I just need to get this darn XB game done so I can start having fun. =)
Again, I haven't tested this new code--- the broken down code. I have kept a version in multiple-statement lines and without most of the REMs... but I'm pretty sure this new code works. No reason for it not to. =)
Yeah, implementing an XB program in assembly is a great way to learn how to do it.
I did it myself with TI-Trek. That one was tricky because I decided to re-utilize the mathematical functions... which meant using XMLLNK and GPLLNK. Not so bad for tagged code, but a pain in the butt to implement with memory images.
You can see my source code and download the disk here: http://www.adamantyr.com/misc/titrek.html
Adamantyr
-
So, I just bought one of these devices. I guess I didn't look/read enough/understand enough about it. Apparently, once it's in place, you can't use the PEB?!? How does one get files off of their disks, then????
I thought a main purpose for the thing, and what I wanted, was to copy my TI
files easily to the device and then just take that memory card to the PC for
easy-usage with a TI emulator.
Maybe I'm just missing something. I guess, if needed, I could try and locate an
external 5 1/4 drive that would work on the TI without the PEB...hope I don't
have to.
Anyway, if I can't get this to do what I want and I goofed up, I guess that I'll
be parting with it someday.
Are there any videos of folks using the device? Where's the best information or
a review?
Unfortunately, the CF7 is not a quick and easy way to port your software.
I ported my stuff over a few years back, and I had to do it using TI99-PC, a DOS software utility, with a 5 1/4" drive on the PC to do the reading.
Actually, I also had to set up a DOS PC to do the work, because any Windows OS past 95 doesn't allow the low-level routines necessary to read old disk formats. Which also meant I had to copy the finished files to a 3 1/2" disk to get to my actual PC.
Fortunately, I only had to do it once.I also found that the menu systems in TI99-PC were a little problematic, so I ended up just executing his utilities directly from the command line to do the conversion work.
The CF7 works very well for testing software written in emulation like Classic99. You can use TI99-Dir to copy files onto disk images quite easily. Just be careful because your modern PC will consider the CF card "unformatted" and may prompt you to format it.
Adamantyr
-
I read my post again and wasn't completely happy with the clarity so thought an example might be better. Obviously this example is missing much of the backbone and won't work when typed in, but most XB users should be able to get the gist of it. Just going from memory here.. Hope there are no silly mistakes.
10 READ S(1),S(2), S(3), S(4)
100 A=S(2) :: GOSUB 500
110 BLAH BLAH BLAH
120 A=S(1) :: GOSUB 500
130 BLAH BLAH BLAH
140 FOR X=1 TO 4:: A=S(X)::GOSUB 500::NEXT X
150 END
500 A$=STR$(A)
510 B=VAL(SEG$(A$,1,4))-1000 !DEFINE STARTING REC NUMBER
510 C=VAL(SEG$(A$,5,2)) !DEFINE NUMBER OF LINES TO READ
520 D=VAL(SEG$(A$,7,2)) !DEFINE STARTING ROW FOR DISPLAY
530 E=VAL(SEG$(A$,9,1)) !DEFINE SOUND
540 F=VAL(SEG$(A$,10,1)) !DEFINE DELAY
550 FOR I=B TO B+C :: INPUT #1, REC I:B$ :: CALL HPUT(D+G,1,SEG$(B$,1,32)):: G=G+1 :: NEXT I
560 IF E=1 THEN CALL HONK ELSE IF E=2 THEN CALL BEEP
570 FOR I=1 TO F*320::NEXT I
580 G=0 :: RETURN
1000 DATA 1050320100, 1120101019, 1350051200, 1240012419
* REC I contains screen data to be displayed on each line
Okay, so the array represents data. Why not store the values as straight characters, and use the ASC function to convert them back to numerals?
The only limitation there is the 0-255 limit, but otherwise, it works fine.
Part of the advantage there is that then you use stack space to store the data arrays, which is generally not in high usage in Extended BASIC. (No high-res graphic mode to use)
Adamantyr
-
Research and back-ground work continues on my LGB project (which BTW is quickly growing out of hand!).
Right now I am working on some of the repetitive subroutines that will be used during the game. One routine in particular is required many times during the game and will be called from a lot of different program line numbers, in fact - it is used everytime a line of text is displayed. This particular subroutine is responsible for reading a text string from DSK1, deciding where to display it, actually displaying the string on the screen (using the CALL HPUT command from RXB), beeping, honking, plus a few other cool functions which also include importing basic graphics to the displayed line when required. Everything is controlled by a single 10 digit variable. A typical example of a variable used would be: S(100)=-1010071012
The logical choice was to use a custom SUB routine which I had defined as "CALL T" and used a single parameter list. An example of this would be;
CALL T(S(100))
After fooling around with this idea and improving the routine a few times, it became desirable for my SUB routine to also be able to access existing string variables which were used outside of the SUBroutine in the main program (which is not possible without complicating the subroutine with additional parameters and having to specify each everytime CALL T was used OR I found myself in a situation where I was "double handling" information to get around the problem which just slows things down too much). For this reason I have no real choice but to flick my subroutine and call the entire routine using a GOSUB command - which is more freindly when wanting to use variables specified elsewhere in the main program.
My main concern with using a GOSUB command in leu of a SUB routine was the additional program space this would incur - especially when it is being repeated many many times during the program. So to get a feel of how much program space I would loose/waste using this method I did the following basic test;
100 CALL T(S(100))
Using a SIZE command advised this program line used a total of 21 bytes of program space
The alternative GOSUB command would need to be specified as follows;
100 A=S(100) : : GOSUB 1000
When listing and compared on screen, the program line with the GOSUB command seems to occupy an 8 additional spaces over the SUBroutine (by spaces I actually mean 8 additional characters). However, when checking this expectation using the CALL SIZE command I was pleasantly surprised to discover that the GOSUB line actually only occupied 1 additional byte of program space.
This is really good news for what I need the GOSUB command to do as I am struggling to save every single byte, but it begs the question of what is going on? Why only 1 byte difference between the two lines of code? Obviously my very basic understanding of how the TI stores program data is flawed but I just can't make sense of how two vastly different length lines of program data occupy roughly the same program space.
100 A=S(100) :: GOSUB 1000
100 CALL T(S(100))12345678
BASIC is tokenized into 8-bit tokens. The GOSUB command only occupies a single token. Don't go by the number of characters you see in the listing, trust the size command to know what it's doing.
100 characters of parameters? That's a lot of overhead to pass every single time.
Keep in mind also that there's some differences in performance using custom subroutines compared to a single GOSUB.
Adamantyr
-
In standard mode we can have 3 sets of 256 characters for a total of 768 characters?
We can write all 768 characters to the screen?
No, there's only a maximum of 256 characters in standard mode.
In bitmap mode, you do have 768 characters, but each set is restricted to 1/3 of the screen, so you technically only have 256 characters, you can just have them vary between the three screen sections.
Adamantyr
-
As for sounding like the MSX, the MSX computers use the AY-3-8910, which is very similar in functionality to the 9919 (SN76489 / SN76496). The main difference is that the 8910 has an envelope generator that can do a saw-tooth and triangle waveform, where the 9919 can only generate a square wave.
Yeah, got any ideas on how you could turn the square wave into a saw-tooth or triangle on the TI via software?
Adamantyr
-
Yes, I set it up to randomly load monsters, I have about two dozen for the Demo version. The full game will support up to 255. Whether or not I use the full capacity remains to be seen...
I fixed my text offsetting issue by, ironically, converting it to use null-terminated strings instead. Normally I avoid these since they're prime targets for buffer overruns. In this case, it was the cleanest way to display text that shifts down a line if it hits a width threshold.
Looking over my code, I discovered that I did have all my code wired up to determine attack results... but I've no way of knowing what's going on during the fight. So right now I'm wiring up "combat announcements", and I may implement a little FX of melee attacks. Since none of my attack code has actually been ran through, I suspect there's going to be a lot of debugging going on there.
Adamantyr
-
I changed the width to >8357 because the new map width is 87 instead of 84 as before.... The heights is curious to me though, because I don't think the map was 86 characters high... of course, that matters less than the width. I'm curious as to whether there is another label I need to modify like an offset or something to match this. I'll keep reading
The Equates aren't values, they're addresses on the computer. In fact, those are all in the scratchpad RAM, from >8300 to >83FF. They're pointers or storage locations for values. So at >8354 is a word-length value that stores the map width.
Adamantyr
-
-
In looking at the Grandia video from the previous post, would a turnbased/realtime engine be possible on the TI? I know the indicator on the Dreamcast is pretty freaking cool, but I don't know that it would be do-able on the TI. Perhaps a SPRITE for each character representation just like in the Grandia video--- perhaps SPRITE movement tied to a routine which accesses the interrupt routine and creates the proper "timing" based on move selected and the player's speed/agility or whatever... I mean, it's possible, is it not?
I have talked for a while about a realtime/turnbased battle engine... and it's Final Fantasy III and Grandia II that opened my eyes to that particular style of combat. It's fascinating... Not a "fighting game" but not a rigid D&D turn-based system either. It's these console RPGs that really get the battle engines "right" as far as my personal taste is concerned. If it's possible in assembly, then I need to add some new stat categories to my spreadsheet. =)
Anything is possible in assembly. It's mainly a design issue of having a clock that "counts down" even while processing other things, and listening for player input. You just need to consider all your edge cases and how they'll be handled.
Adamantyr
-
Tell you what, man---I've been in the studio every day for the last week working on the album. It's been unbelievably exhausting, but rewarding at the same time. =) I'll post links to the tunes on here somewhere when they're closer to done. Tonight is my last night in the studio for the next month, because I'll be playing in Florida for 3 weeks and then Georgia for a week. Life gets crazy sometimes. What are ya gonna do? =)
Real-life always intrudes. It's cool.
As for Beryl Reichardt updates, I have nothing new... It's sad, but I kind of rely on input to keep going. I'm so green in Assembly and this whole thing is so daunting... I've been plugging away at my document, and I've started a couple spreadsheets for battle stats, but I have nothing new to show visually. I kind of got a kick in the face a couple weeks ago on this project. I posted the game project on a couple of RPG forums and it developed a bit of excitement briefly. Then the threads became discussions about why the hell I would write a game for a vintage system in assembly--- A bunch of "You're wasting time and you won't finish it," "Why would you put such shitty restrictions on yourself" and so on and so forth. Then all posts on the game ceased. It didn't mortally wound me or anything, but it just kinda gave me a bad taste in my mouth. I know HERE people GET IT... But other stuff has kind of taken over the life for a brief period. I will try to be a bit more active--- This past week has just been so insanely BUSY!!!
Assembly is very daunting to write in. Working on design is a good way to flesh out exactly what you want to accomplish in assembly. I can send you some of my spreadsheets sometime if you want to see how I put them together.
Yeah, retro-boards are what you want to stick with... modern development boards are full of jerks who have nothing better to do than to rip down other people's work because it's not in the flavor of their choice. I find the TI board here to be very invigorating and encouraging... and let's keep that going!
BTW, I have just discovered the magnificent SNES game FFII!! I knew about the game, but never played it before. It's technically the fourth game in the series, but FFII for SNES has probably the coolest story of any of the console RPGs I've played. =)
Yes, that is a very fun CRPG. The third one (FF3 on the SNES) is also pretty good, if you can find a copy.
Adamantyr
-
Hey Owen, where you at? The board goes really quiet when you're gone.
Adam
-
-
Well definitely the intro sequence will be a totally separate program. =) I'll have to do a bunch of figuring to do for my game... I need to balance story and gameplay, but without storing all the NPC dialogue in RAM, I'll have to access it via diskette, and I have NO idea what kind of realtime lag that will bring on. That's another discussion for another thread.
In any case, for "Realms," are you planning on having the entire game on one disk (aside from the save disk) or will it be spread over multiple disks? I'm interested in this subject and I couldn't find the answers on your blog. If you've addressed disk access in your blog and I've missed it, please link it here so I can read. =) Your blog is a freakin' roadmap--- truly informative and a blast to read.
It's one game disk, one start disk, and four data disks, all 180k. So you need at least two floppy disk drives to play.
Adamantyr
-
Handling a large amount of text... That's something I had been contemplating too... Do we use the text directive? I assume this is the way to go--- but I hear it's expensive. I had done a mockup of several pages of story/instructions but just used entire screens. Obviously unnecessary, but it showed me how much space all this text takes up!!!! I may have to look at a two disk system here.
Oh yeah. On vintage systems, text takes up the equivalent space to graphics. Bizarre!
I am compressing the narrative text in the game using a simplified technique that crunches it 20-30%. Functional text like spell names are just stored in indexed files uncompressed.
You should consider pushing text to disk, rather than storing it in RAM. I mean, if it's only displayed at one instance of the game, do you need it taking up space?
Adamantyr
-
Adam... do you have a storyline for the game you could share?
That would be telling...
How do you plan to implement it? In games like Final Fantasy I,II,III, etc, there is typically an extended intro sequence where you get the storyline, the background of the characters, and a hook... to draw you in...
I'll have an intro sequence on the character creation disk after you've made a new game disk. The actual game disk will just launch into the game. There will probably be an end sequence as well.
I'm curious as to what the TI is capable of. Could an intro be done in bitmap mode and then the actual gameplay be in standard mode? This would allow very detailed screenshots while music plays and text is displayed at the bottom of the screen.
Of course. I would advise, though, that the "intro sequence" be a completely separate program from the game itself. You don't want to waste those resources when you could just push them to disk. Keep in mind, though, that music playing while disk accesses are going on are TRICKY to implement... I haven't tried it myself yet, it's possible, but would require you to have your code do it's own interrupt management ("Play some music, load some data, back to music, back to data, etc.")
Also, keep in mind a full bitmap image on the TI takes up about 12k of disk space, uncompressed. So you'd only have room for a handful of unique images. Coming up with an effective compression technique may help, but it would be hard to do on the TI's bitmap implementation...
It's not a pressing priority right now, but I'm starting to think about graphics and gameplay quite a bit lately. It keeps my mind sane while I battle it out with my battle engine. In any case, I was curious as to how YOU were planning on implementing your story... Story is so important to an RPG and if you under-do your story, you're doing the game a disservice. I know absolutely nothing about your storyline, but I was curious as to how often your story would interact with your gameplay. How do NPCs play a role? Just curous. =)
A lot of text. Story and game-play are intertwined, and players actions make visible differences. NPC's I'm still working details out on.
Adamantyr
-
Sorry if I'm making to much out of this, I am really the wrong person to discuss RPGs with. I've been making one for 18yrs, lol. Not the same game but a series of games that all get to a playable state and then I start over and improve on the engine. And world editors, man no that is my favorite thing. Currently making random map generators of course this goes crazy with me to. I make one to make the world with height maps so you have water land and mountains. Then I add beach and levels of terrain so it becomes something like,
deep water
shallow water
swamps
beach
grasslands
hills
highland
mountains.
Then still not happy I decide I want it to auto place cities and encounters so when I play it I have a unknown factor still. And when you auto add cities then you have to random generate city lay outs, services available, ect.
I call it the RPGPS.
Role Playing Game Programming Syndrome - the illness of never being able to finish a game because you always want to add more. It spreads to other program types to. Like my Worm Wars, I just wanted a classic Wormy game for the TI. simple did it - done, wait why not add other game types - should be easy. Then I end up having 5 game types and a game that that's way longer to make then it should.
Maybe I should just stay out of this thread before my RPGPS spreads to you.
Don't worry, John, it's a condition a lot of software developers suffer from.
I just took a design pattern class where the instructor talked about how he met an artist, and asked him how he did his sculptures. And he described his process as doing it as an overall job, as complete as possible, but to get it done. Then, if he had time, to start over and go over the whole thing again, and improve it. The idea being that he didn't spend an inordinate amount of time making the eyes perfect, because if he focused on one aspect and nothing else, the whole thing would be unfinished.
I think with your Wormy game, you did well. You got it done! Now you're like "I want to make it better". So do another iteration of it, and make a better version 2.0. And so forth.
Adamantyr
-
I was assuming you are making it a cartridge? If it's disk base then I guess they would have a disk to save it on, lol.
No, wasn't planning on a cartridge, so yes, could just save games to disk.
It's not possible to really do what I want with the game in only 256 bytes of RAM easily, and if I have to require 32k, may as well require the disk system too.Adamantyr
-
Hey Adamantyr,
I'ld like to make a suggestion that you use save codes on this game, not disk saves so people can play it even if they don't have a disk expansion.
John
It's possible to do. Save codes are just an encryption key, would be a bit of fun to put one together.
Adamantyr
-
This is pretty much what I had in mind... however, if fire is opposite water, and air is opposite to earth, then (I think I gather from what you're saying) Fire elemental spells have no special added damage bonus on Air elemental enemies, correct? This COULD also mean that SOME weapons have an element associated with them. Perhaps "element" should be a part of each character's player stats, each weapon's stats, each piece of armor's stats, each enemy, etc... Sometimes the value (as you stated) would be 0--- meaning no element... but if that's not the case, then we need to think about monster stats like this....
LEV (2) MHP (200) HP (200) ELEM (2) ATK (20) DEF (15) MATK (30) MDEF (25)
This would indicate a low level water elemental monster with full health. Now... how do we check for the elemental flag during battle? Sure, in XB it would be slow, but easy to do... in assembly... I just don't know. Should it even be stored this way? What about FMDEF (fire magic defense)? I'm sure it's not all that complex, but it's something that immediately sticks out at me.
I looked at doing attack types for awhile in my game... I had slashing, piercing, and crushing damage types, as well as spell damage types (fire, ice, etc.) but I ended up jettisoning it when I realized how much code space it would burn up to figure it all out.
It's actually really easy to store data like this in assembly... in fact, it's not so much storing the data that is a problem as much as processing it. What you would do is store them as bit flags in a byte, like so:
00001010
||||||||
|||||||>Fire
||||||>Water
|||||>Air
||||>Earth
|||>Crush
||>Pierce
|>Slash
>(null)
Then you can just do AND/OR operations to determine elemental types. It has the added advantage of also letting you combine states, and also abstracts the type. The only thing missing here is the correlation between elemental types being more vulnerable to some attack forms.
Of course, you don't have to use single states, you could use two-bits and get four different states. So you could have your four elements and then have:
0 = no affiliation
1 = does damage of this type
2 = vulnerable to damage of this type
3 = ?
Adamantyr
-
**As far as AGI, I had it planned to be an "invisible" stat that the user will see.... Re-thinking that too. But it was specifically going to apply to whether the user gets hit or not and whether a hit occurs on that player.
Aren't those the same thing? If AGI is both a defense boost and an attack boost, then why have it at all? You could just increase attack and defense bonuses for a given player/monster.
**On the monster's Max HP, yes, some monsters have "HEAL" and could simply continue to re-generate every turn and become a super-HP monster... Unkillable. That's why I want to cap it. In any case, that's why I had that in there... I bet there's a better way than to track another variable. =) I'll be looking into that as well.
Easiest thing is to just store the monster HP at the start into a temp location. Then you don't have to waste disk/data space on it.
I would really like to track other variables and stats like STR, INT, and a few others, but I REALLY have no idea how to use those in my formulae... As of right now, this thing is stripped down to bare-assed minimum, not because I'm trying to be clever or minimalistic, but because I simply DO NOT KNOW how to use these stats. I know what they do (or rather: "Higher is good... so get strong and smart by eating your Wheaties and killing dragons") but adding them into the formula at this point would be pointless, since I do not know how to handle them.
The best way to start very simple... ask yourself what metrics you need.
For example, you need an abstract representation of attack power and defense power. You have this already, so that's good. You also have magical attack/defense values, so that works out, someone may be very good at martial attacks and defense but be mostly helpless against spells.
Level of experience is really just a tracking system for power. And here's a point, why add level*10 for each attack calculation when you could just add 10 to attack power every time a character levels up?
Hit points and magic points are definitely needed, the question is how they advance per level. I'd go so far in this case to have them go up a static value per character class, which you can burn a few bytes to store somewhere. Complicated formulas here can really run away from you.
This brings me to the next issue--- I have the battle engine mockup in XB done, and I have the battle screenshots ready to go... I would like to slap them together with the formula we're creating right now and see if the engine holds up... It would be a nice way to test theories and different values. Maybe get a little better sense of how things look "in-game." I'll be messing with that sometime soon so I can make a YouTube video for it... In the meantime, please feel free to "adjust" my thought process... I've learned that by listening to others, you save yourself 50% or more time on a project, just by cutting out a bit of trial and error. =)
Again... if you've never used spreadsheets before, this is the time to use one.
A mock battle simulator is fine, but you can do a lot to test out formulas by just plotting out things on a spreadsheet. I did this, for example, to determine how I wanted hit points spread to change over levels. Before I ditched levels entirely, anyway.Adamantyr
-
MAIN PARTY CHARACTERS:
Primary attributes:
LEV (level)
MHP (max hp)
HP
MMP (max mp)
MP
XP (experience points)
ATK
DEF
MATK (magic attack power)
AGI
MATK (magic attack)
MDEF (magic defend)
I think you have MATK in there twice...
I see AGI, which I assume is agility, on the players, but not on the monsters? So no strength, intelligence, or anything? Just agility? Seems to stick out a bit.
Also, do you NEED to have max HP on the monsters? Are there situations where they self-heal that you have to check?
Actually, the attack/defense are usually considered secondary attributes, because they're derived from other sources. A lot of games usually use a target's defense as a threshold number for the attacker to equal or exceed on a random roll. This has the advantage that the external factors (monster defense, terrain conditions, etc.) are only applied on one side. For example, if the to-hit required you to know the armor type of the opponent, you couldn't pre-calc anything, since it's dependent upon knowing certain conditions.
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Calimari Carl (unfinished SSGC game)
in TI-99/4A Development
Posted
Either will do. Keep in mind these tables are relocatable by manipulating the VDP registers, so hardcoding them isn't probably a good idea.
I usually use EQUate labels for most of my VDP references, so I can keep them all in one place but have the compiler replace them with literals later.
Adamantyr