[Unknown]

In a rpg how do you keep track of what each player/npc is able to do as far as attacks/spells ect....

This is some simple pseudocode that I came up with...

[LeoDraco]

Say what you will about the non-applicability of a given tool (in this case of this advocacy message, object oriented design) to all problem domains, but that pseudocode, notably for its lack of design, makes my brain explode in pain. I believe JonA over at GDR said it best when he expressed bafflement at (modern-day) programmers equating programming with tedious chores, at least as far as the fruits of their efforts portrayed their capability for design.

Now, I thought about offering an alternative using that most sexy of OOPLs, Ruby, but that would require me to actually grok what it is you are attempting to do here.

Knowns: you seem to be calculating hit percentages, or, to be slightly more precise, the probability that a given attack would hit. This supposition seems vindicated by the last line of code which does anything.

Unknowns: probability is, ipso facto, something inherently calculable for a given domain, so what's with the looping and the percentage array?

Alternative: while the following will, more than likely, be way off of what you implemented (this follows from the fact that you do not provide a hard specification for what your code does), it falls within the realm of possibility that it does approximate your code.

[Nodtveidt]

[Unknown]

LOL!!! well hello Draco ^_^ ...

[LeoDraco]

[Nodtveidt]

[LeoDraco]

[Nephilim]

Yeah, I've gotta go with LeoDraco on this one. Object-oriented design is particularly well-suited to modeling characters and objects and their interactions, especially when you have a lot of them.

For Sacraments, I had a generic "living creature" object which served as the basis for all living creatures that you could encounter during the game, from the player characters to the monsters. This base object class had many of the game system rules built into it, so that every living creature knew how to apply damage to itself, how to heal itself, how to defend and attack, how to report and modify its stats, how to equip and unequip objects and spells, how to save and load itself, how to display itself in the combat screen, etc.

Once you have that system set up, defining characters is as simple as setting their properties - what's their strength, what's in their spellbook, what sprite sheet do they use, etc., and the game system knows how to deal with each character.

And if you have a special character that needs to overrule the game rules, you just override that method in the object. For instance, boss monsters in Sacraments are handled just like any other monster (with better stats, of course), except that they draw themselves differently because they use a larger sprite sheet. So I created a "boss monster" class that inherited the "living creature" class and overrode the code that draws the character to the screen. Then, boss monsters knew how to draw themselves.

As a result, my "combat screen" code was very clean and wasn't bogged down with a bunch of special cases because all it did was tell all combatants to render themselves into the combat screen. The specialized code for drawing bosses was stored where it belongs - with the specialized type of character.

Another example is items and equipment. I wrote a generic "satchel" and "equipment" class that contains all the rules for inventory management - browsing, selecting, using, and selling objects. Then, to create objects for the game, I merely had to define new objects that extended those base classes, which was really easy and clean because each object only needed the code relevant for that object. For instance, the "Tanis Leaf" code just has a block of code that defines its core characteristics - it's value, when it can be used, the type of target it may be used on, etc. - and a method that gets called when the Tanis Leaf is used on a character. The only code I write for each object is code specific to that object, and the code for making inventory browsers and such may be kept very simple. This approach really allowed me to flex my creativity, because I could easily add new object types without much hassle, but they'd be flexible enough (since they call methods) that new objects could do just about anything I would want them to do.

In truth, practically everything in Sacraments is handled using an object-oriented design. Every view into the game world, every dialog box, every spell, every character, etc., are all objects. As such, I could easily mix, match, extend, and replace any part of my game from the fundamental camera view of the game world to the interplay between a particular weapon and suit of armor. Using an object-oriented design allowed me to easily modify the way my game world worked, and to quickly add content that I dreamed up, and all the relevant code stayed with the object that it related to - for instance, the special behavior of a flaming sword was kept with the flaming sword object; there was no special code to handle that special case in the combat code. This made my code easy to manage and navigate, which paid dividends for maintenance and bug hunting.

If you haven't looked into it, I *highly* recommend looking into object oriented design. It's not a silver bullet for every single application of programming practices, but it makes certain types of applications very easy to write, and one of those types of applications is the RPG, where you need to model lots of things that behave in similar ways but which still require significant variation (players, monsters, spells, attacks, weapons, armor, potions, etc.).
_________________
Visit the Sacraments web site to play the game and read articles about its development.

[Tenshi]

- The only way I can explain mine concisely is to say that Players and Enemies are Characters. All characters can perform particular actions. The "User" can interact with each Player set their behavior, and scripts (and FSM's) dictate enemy behavior. From there, all actions are fundamentally Character based. Everything is based on Active Time.
_________________
- Jaeda