Okay, last year, I posted about an idea I had involving programming a small dungeon crawl without using any variables other than bools, pointers to bools, or structs/classes/arrays comprised of those. This really didn't go anywhere but it gave me some interesting ideas: * Eliminate HP, and replace it with a system where the player and the enemies have a number of body parts, and to kill or be killed, a body part that's flagged as "critical" (head or torso) must be destroyed. Legs and arms grant defense and attack penalties when destroyed. * Skills do not level up. You either have a skill or don't have a skill. * There are no experience levels. You get new skills by completing quests for the Shrines found in the dungeon. There are sixteen skills in total, although you can only get eight in a single playthrough. * New idea courtesy of someone from TIG, but puzzles in the game are based around boolean logic gates. I wrote a circuit simulator a few weeks ago, so I'll probably be basing this aspect off of that, sort of. Anyway, I've hit a bit of a snag, here. I had a battle system planned out, but the more I looked at it, the more it looked needlessly complex, rather hands off, and... well, boring. The initial idea is that each bodypart had four damage states: injured, bleeding, pierced, and destroyed. How it worked was that, if a bodypart got attacked, it was set to injured. Getting attacked again would set it to pierced or bleeding, both of which had different rules for determining if the bodypart in question automatically got flagged as destroyed next turn. Certain weapons could bypass the injured phase and immediately set a part to bleeding/pierced. Armore was also in place, as a system that would block a single attack per battle against a body part. Again, certain weapons could bypass this. The basic goal of combat, though, was to maximize the number of attack and defend opportunities. Essentially, if your attacked missed, you'd get another attack as long as you had certain skills or weapon-properties giving you extra attacks opportunities. Hitting armor would also count as a miss here. Mind, you only got to get one hit in per turn, but this changed the odds of getting a hit in. Did that description make any sense? I kind of doubt it. Do you see why I'm doubting the quality of this system now? I want strategy in place here. I want active control on the part of the player. So, my first idea was to simplify the damage system. If a body part gets hit, one of two things happens: If it's armored, no damage occurs and the armor is deactivated on that body part. If it's not armored, it's immediately destroyed. Likewise, I've limitted it to head, torso, arms, and legs. Originally I was doing both arms and both legs seperate. So, the new focus in combat needs to be on finding ways to defend yourself while still being able to attack effectively. Some ideas: Boolean RPG Battle System Ideas: (Note to self: Maybe torsos should need two hits to be destroyed.) 1.Manually pick a body part to defend. Depending on which you defend, you get varying attack penalties. For instance, if you shield your head, your safe from getting killed via headshot, but you can't see over your shield/arm/whatever you're shielding yourself with and your attacks are incredibly likely to miss. 2.Do something with defense stances. 3.Manually select body parts, but incorporate boolean logic here. For instance, you can defend the head and the torso, the head or the torso, or the head xor the torso. In the case of and, it's a 50 percent success rate to defend when either part is attacked. With or, the first bodypart selected has a 75% defend success chance, and the second only 25%. With xor, you pick a single body part with a 100% defend chance. 4.Use boolean logic again, but instead of selecting body parts, related it to whether the player attacks or defends. If the player attacks and defends, the success rate for both is halved. If the player attacks or defends, both events may occur, but the second will have a drastically reduced rate of success. Xor is a normal stance: You give priority to one of the two to fire assuming you go first; otherwise, an appropriate action is taken based on what the enemy does. Xor could potentially kill the enemy fastest but it's also the biggest gamble. 5.Some fusion of 3 and 4. 6.Some fusion of 4 and 1. 7.4, but also have a system in place where there are four or eight different weapon classes, with a sort of circular arrangement for determining which attacks first (Sword goes before spear, spear before bow, bow before sword, etc.) for use with the XOR stance to make it less random. 8.System for generally defending any body part with a lower chance of success, or concentrating defense on a single body part with a huge chance of success. So, anyone else have any ideas?

Quote:

Original post by MeshGearFox Okay, last year, I posted about an idea I had involving programming a small dungeon crawl without using any variables other than bools, pointers to bools, or structs/classes/arrays comprised of those.

I may be missing something here, but surely any numeric system can be implemented in base 2? So it may be that restricting yourself to boolean variables is only causing you to think about the complexity of your system a lot more, without really providing any kind of logical boundaries.

Presumably emulating numeric types using arrays of bools is banned as part of the challenge, or it wouldn't be much of a challenge.

Encoding other numeric systems in base 2 using boolean values also defeats the purpose of getting away from using HP. That's part of the reason why I'm redoing the battle system anyway: the first system basically ended up meaning that each bodypart had 4 HP, and total HP was based on total number of body parts, and my design just got kind of idiotic and unmanagable.

One hit per body part (unless armored, with one hit per armor) is what I want. My *main* problem is making this interactive and strategic and not "Whoops enemy hit your head on the first turn. Game over :("

Well what I was trying to convey is that in creating a sufficiently complex and interesting system of booleans, it is very easy to have inadvertently "cheated" and have encoded greater values within the complex system - as MeshGear noted, his original system effectively encoded a small number of hit points. And things can get much trickier to spot than that. I know this because I spent a bit of time decomposing more complex systems into flags, and the middle ground is very muddy.

So I was wondering whether there was perhaps a better way to structure the rule. Of course, if the above doesn't bother you, then you don't have a problem at all. And I do like the sound of your proposed battle system in any case.