PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Tue Oct 17, 2017 6:36 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Sat Oct 22, 2016 11:19 am 
Offline
Forum Newbie

Joined: Sat Oct 22, 2016 10:42 am
Posts: 17
I'm currently working on a text-based combat system, and even though I have told myself the key point at this stage is only to allow killing animals and gain resources from them, I would later want to use the same system for combat between humans, so I wouldn't want to end up in a situation where I have to do a major rewrite just because the original system wasn't flexible enough.

Instead of hitpoints, my system keeps track of how much blood is in the character's (or animal's) body. If you lose enough blood due to external or internal bleeding, you eventually die. It's also possible to become incapacitated due to broken bones or pain, maybe even fear in the future. So if you get hit in the leg, it likely won't kill you, but the hampered movement is giving you a disadvantage.

Here I'm concentrating on the body modeling. I had an idea of numbering the body parts first by major part (1 head/2 neck/3 torso/4,5 arms/6,7 legs) and gradually adding sub-areas (for example 12 face, 122 right eye, 1222 right eyeball). At deepest there are currently four levels. When the game rolls for which area it hits, either if you roll high enough, it will go deeper in the tree, or it will roll repeatedly to define does it stop on this level or go deeper. Some of the areas are bones and some are major arteries. But - I should make it so that some targets are smaller than others and have a smaller chance of being hit. If you or the enemy manages to hit a major artery, it's instant death for the wounded party, so at least when it comes to the player character, that should be rare. I'm thinking of possibly mapping the body as a multidimensional array.

It should also be possible to target certain areas based on intention:

defend self - refrain from attacking, concentrate on protecting yourself
play - use only light force, avoid causing injuries
practice - mainly arms and shoulders, refrain from deep injuries
punish - non-lethal areas, mainly butt and back, back of the thighs, aim to cause pain but no harm
disarm - aim for weapon hand
incapacitate - aim for limbs, aim to cripple
quick kill - aim for head, neck, heart, groin arteries
slow death - aim for stomach, lungs, throat
torture - aim to cause maximum pain, likely to cause non-lethal damage too
blind - aim for eyes

In the case of an aimed shot, there should be a possibility of hitting a neighboring area if you miss the intended target. BUT - that requires knowing which areas are next to each other. My numbering system doesn't take that into account.

One thing I considered briefly was making an image file where each potential target area is in a different color, then picking random x,y and checking the color of the pixel in that spot. If it's the background color, it's a complete miss. The benefit of that system would be that it enables starting with a bias, and that allows aiming. But, the body isn't a still target. If you're standing with your hands by your sides, if someone aims for your fingers, they can accidentally hit your hip instead. But if you have your hands up defensively, then a missed hit should land at your shoulder or chest, not your hip. So if I used this system, should I have multiple pictures for different scenarios? And what to do with three-dimensionality? Should there also be a z axle? Technically it would be possible to have an x,y grid solely written as an if-based set of conditions, but it might be harder to visualize than a picture.

Also, should I take into account if the attacker is approaching from behind, from the front or from the side? In a completely random system you can end up hitting the bottom just as likely as the chest. But it wouldn't make any sense that you could accidentally hit someone in the ass when you were aiming for their face. So a completely random system is out of the question.


Top
 Profile  
 
PostPosted: Sat Oct 22, 2016 11:53 am 
Offline
Spammer :|
User avatar

Joined: Wed Oct 15, 2008 2:35 am
Posts: 6571
Location: WA, USA
Seeeks wrote:
Here I'm concentrating on the body modeling. I had an idea of numbering the body parts first by major part (1 head/2 neck/3 torso/4,5 arms/6,7 legs) and gradually adding sub-areas (for example 12 face, 122 right eye, 1222 right eyeball). At deepest there are currently four levels. When the game rolls for which area it hits, either if you roll high enough, it will go deeper in the tree, or it will roll repeatedly to define does it stop on this level or go deeper.

That doesn't make sense to me. If you're subdividing the (eg) face into mouth and eyes and so on, when the "face" gets hit it must have been on a particular part. Like, there's no way to hit a person's face without hitting some particular part of it.

Seeeks wrote:
Some of the areas are bones and some are major arteries.

Aren't those really more attributes of particular parts? If I poke your nose then that's +0 damage to the nose with no collateral effect, but if I punch you in the nose that's +X damage to the nose with the additional possible effect of breaking it: the nose area has a sort of "destructible" attribute (since it's not bone). If I push you in the ribcage then that's +0 damage, but if I punch you then there's +Y damage with the possible effect of breaking one or more ribs: the damage is actually done to one or more particular "rib" subdivisions, if you decided to model it that way, and those ribs all have a "bone" attribute which in turn implies they can be broken.

Seeeks wrote:
But - I should make it so that some targets are smaller than others and have a smaller chance of being hit. If you or the enemy manages to hit a major artery, it's instant death for the wounded party, so at least when it comes to the player character, that should be rare. I'm thinking of possibly mapping the body as a multidimensional array.

The chance to hit is easy to model as exactly that: a chance to hit. If the face is composed of the forehead, two eyes, nose, mouth, and two cheeks, you could assign them chances of 30%, 5% per, 10%, 10%, and 20% per. Then it's just rolling dice.


I could keep replying to pieces, but

Have you ever played D&D? You should find a few DM and player guides. They have all sorts of logistics worked out already that you can take inspiration from.


Top
 Profile  
 
PostPosted: Sat Oct 22, 2016 2:13 pm 
Offline
Forum Newbie

Joined: Sat Oct 22, 2016 10:42 am
Posts: 17
Thanks for replying.

If I did go and define every part of a face in sub parts, then it would always hit one of them. However, if I decide for example not to make cheeks or temples their own sub parts, then one can assume that one of those was hit instead of something more critical like the eyes. Likewise, if you hit someone in the eye but miss the eyeball itself, you can assume that the injury is in the surrounding tissues or eyelid. Generally if you hit the main area, you're injuring the skin, and the actual position of the wound is non-critical. I should only include the body parts that pay a particular significance in that they either cause significant bleeding or can break or cause more than usual pain.

I haven't played much DnD but I have tried it. I don't remember it handling body parts, though. I have one rule book at home for Rolemaster, so I could take a look at that. I remember that uses a percentage based system with a chance for rolling again if you hit 1 or 100.

It's a very good idea about having a bone attribute attached to certain body parts instead of all. In my test system, every body part on the list is associated with a bone, but if I went to include for example internal organs, there wouldn't be enough bones to assign one to each.

While waiting for replies I went and drew an x,y graph of a body, where every body part is a rectangle and the corner coordinates are pretty rough, usually divisible by 10 and always by 5. Based on that, I wrote a script that aims for the upper left arm, and you can give it a falter range. If it's 10 then you most likely hit the target, if it's 100 then you're more likely to hit the chest or miss. It can be expanded so that you can for example target specific critical areas. The benefit of an x,y map is that you can have taller enemies aim for the upper body, while small ones aim for the feet. Also you can switch sides based on if the attacker is right-handed or left-handed.


Top
 Profile  
 
PostPosted: Sat Oct 22, 2016 3:28 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13434
Location: New York, NY, US
It see like you want to have relations for location of everything plus the hierarchy. This could be a set of linked PHP objects ultimately, but could be read from a database. For example:

Humanoid
Head relation: parent=Humanoid
Head relation: below=Torso
Torso relation: parent=Humanoid
Torso relation: above=Head
Torso relation: right=Right Arm
Torso relation: left=Left Arm
Left Arm relation: parent=Humanoid
Left Arm relation: right=Torso
Right Arm relation: parent=Humanoid
Right Arm relation: left=Torso
Face relation: parent=Head
Skull relation: parent=Head
Eyes relation: parent=Face
...

Other types of creatures might be different.

Quadruped
Head relation: parent=Quadruped
Head relation: behind=Torso
Torso relation: parent=Quadruped
Torso relation: front=Head
Torso relation: below=Right Front Leg
Torso relation: below=Left Front Leg
...

Not sure if any of that makes sense...

_________________
(#10850)


Top
 Profile  
 
PostPosted: Sun Oct 23, 2016 4:36 am 
Offline
Forum Newbie

Joined: Sat Oct 22, 2016 10:42 am
Posts: 17
It does make sense. If they were in the database, the relations would probably go by id number rather than name strings. The problem with id numbers is that if I just enter parts in the database in the order I come to think of them, the numbers bear no relation to which body part they're associated with and it's hard to spot typos. It would be possible to have a map that is solely linked by keywords but with the number of letters increasing, the chance of making a typo grows.

My x,y system covers the vicinity part but because arms are mapped in a defensive position, it might be hard to define with just x,y which parts should be amputated if the arm is severed at a certain point. With the legs it's more simple because you can say that everything that goes beyond this point will be gone. If I bring in a z axle as well then I can define if a hit reaches internal organs.


Top
 Profile  
 
PostPosted: Sun Oct 23, 2016 12:37 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13434
Location: New York, NY, US
Seeeks wrote:
It does make sense. If they were in the database, the relations would probably go by id number rather than name strings. The problem with id numbers is that if I just enter parts in the database in the order I come to think of them, the numbers bear no relation to which body part they're associated with and it's hard to spot typos. It would be possible to have a map that is solely linked by keywords but with the number of letters increasing, the chance of making a typo grows.
I would not worry about id numbers being meaningful. That seems difficult to maintain and ultimately limiting. Just use an autoincrement value. It is the parent and the relation that matters. You can verify the data sets by outputting them is some labeled debug format. Once they are right it doesn't matter what the id numbers are.

Seeeks wrote:
My x,y system covers the vicinity part but because arms are mapped in a defensive position, it might be hard to define with just x,y which parts should be amputated if the arm is severed at a certain point. With the legs it's more simple because you can say that everything that goes beyond this point will be gone. If I bring in a z axle as well then I can define if a hit reaches internal organs.
You might as well go to a 3D system and track collisions. There is plenty of open source code around that you could use to do that.

_________________
(#10850)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group