adamantyr

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

Real-life always intrudes. It's cool. 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! 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

Also, new blog post today: http://www.adamantyr.com/blog

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

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

That would be telling... 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. 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... 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

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

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

It's possible to do. Save codes are just an encryption key, would be a bit of fun to put one together. Adamantyr

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

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. 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. 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. 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

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

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. 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? 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. 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

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

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

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

That's right. If you have a very small map area, you don't really need "random" turns much because you'll be hitting borders frequently, and the connections will just make themselves. For the most part, the design above is a "Dig out a corridor until you hit another chamber" algorithm. It won't, for example, create T-sections, four ways, etc. except by accident. One algorithm you can take a look at is the original random dungeon generator in the 1st Edition Advanced Dungeons & Dragons Dungeon Master's Guide. It was later reprinted in the 3rd Edition DMG as well. Not everything there could be used (and what is there does need a little common sense to make work), but it would generate a random dungeon for you in a slightly different way. Adamantyr

You can look at "Dark Maze" to see a very simple maze algorithm at work. Here's how the design works: Start with a blank map of nothing but walls Plot random chambers on the map You can either make them fixed sizes or slightly random in height/width Overlapping is okay if you don't mind that, but it can make oddball shaped chambers [*]From each chamber, plot a corridor from the center Plot anywhere from 1-4 cardinal directions from the center Don't start plotting until you hit the edge If a border is reached, change direction You'll need some logic for direction random changes, otherwise you may just backtrack on your path and end early If another empty chamber or corridor is struck, end the plotting for that direction [*]Populate items, monsters, etc. in the maze, either totally random or use the center coordinates of chambers as guides Adamantyr

Here's a bounce sound: FOR I=1 TO 4 CALL SOUND(-20,330+15*(2^I),4+I) NEXT I And here's a nice thud: FOR I=1 TO 3 CALL SOUND(-20,110,30,110,30,800+200*(I^4),30,-8,2) NEXT I Adamantyr

Very nice, a multi-color sprite creator for the TI would be useful indeed. One request, though, a page without the music please. Not safe for work if it makes too much noise... Adamantyr

You may want to flowchart out all potential actions per menu screen. This is what I mean by design. You don't have to run out and buy a Flowchart template or anything, just write out all potential player actions, and the keystrokes that need to be tracked, for each menu, and what their effect is. For example: Party Menu (State: Selection) ---------------------- Keys: Up - Move selector up Down - Move selector down Enter/Fire - Goto Character Menu R - Go to State: Reorder X - Exit party menu Okay... one thing, X on the TI keyboard is also "down" for most games. Function-X is the real "down" keystroke, which can be supported so that expanded keyboards with separate arrow keys work. Or are you planning to use the joystick for this? So in assembly, are you going to construct a different SCAN loop for every menu? I get a lot of mileage myself by storing the accepted keystrokes in an array and processing in a general subroutine. As you can see, dig into the logic a little and things aren't as simple as you thought. Adamantyr

I'll be interested to see how my routine does with the "coin toss"... it will likely require a very large sample size (tens of thousands of flips) to flatten the data curve out. If you roll dice in the real world, you see patterns like that. I just KNEW you'd bring up the DIV and MPY slowness argument... As I said, different uses for random numbers. For filling a screen with pixels, the XOR/Shift technique with a logical progression is very good because it will eventually hit every value. That means you could use it to do a screen "wipe" effect in bitmap... For my purposes, the randomness needed to be very random like rolling a die, and fortunately I don't need it too fast. For the record, in my CRPG I actually use the VDP counter even/odd state for a lot of quickly needed "true/false" decisions, or even for direction determination. No need to call an expensive subroutine when just a MOV/ANDI will do in a pitch. Adamantyr

Ah, I see you've discovered that menus and displays can really chew up memory. It's a rather surprising and unwelcome revelation, isn't it? There's a few techniques for menu-driven interfaces on the TI that minimize the footprint: - Use a basic "menu template" that is identical for all usage, and just alter the text - Create routines to auto-generate the various menu elements, including text and the bounding boxes - Store your menus as image files on disk and load them as needed directly into the screen buffer. Each takes up around 1k on the disk (768 bytes/3 sectors of screen, plus an additional sector/256 bytes for the file header) For example, I wrote a short routine in my CRPG to generate the bounding boxes, with registers used to pass the starting location, width, and height. That can be reused on a blank screen easily enough. Text placement still requires you to store the text somewhere and then write it out to screen. Probably the largest issue to overcome is minimizing your interaction model. Basically, you want to figure out everything you want menus to do, and then find the most cost-effective way to do it in code that doesn't require a lot of special casing. For example, having the same option in the same place on multiple screens can really help cut down on the need for dynamic processing. Generally with game programming, you're either trading off data-space for faster performance, or code-space for reduced resources. And menu generation is a great example case for both methods. Adamantyr

Yep, it's a detour of sorts. I really need to figure out how to use sprites effectively and efficiently in assembly language, and a more action-oriented game lets me figure that out. Then I can leverage it into my CRPG work. Also, was playing Zelda and thinking 'I could write a TI original title based around this style of gameplay.' Adamantyr