Messages

46

Programming / Re: Damage displays

« on: October 22, 2009, 07:16:07 AM »

Showing, how much damage you do to a certain enemy is mostly irrelevant for the player.

It's a lot easier to count, how often you need to hit a certain anemy with a certain weapon and extrapolate from there. Then the damage per hit is even more accurate, because you will connect it to the monster at hand directly, regardless of how many hitpoints it has - so you won't have to find that out.

47

Programming / Re: Limb-oriented skill system - You see any pitfalls?

« on: October 16, 2009, 02:23:00 PM »

Yeah, this might be really a little bit hard on a first project. But it shoull stay extensible either way with a little bit of planning. Will have to pick out crucial features first and see.

48

Programming / Re: Limb-oriented skill system - You see any pitfalls?

« on: October 16, 2009, 02:12:28 PM »

Now that finally make the race "amorphous blob" playable. A creature that can shape it's body depending on the requirements of the situation, but needs time to shift shapes successfully. Such a system is interesting because it provides a high number of combinations to explore, and if done right, there is no single "best" configuration, but a lot that excel at different tasks.

Thus we arrive at a skill system above the one described before: One to measure the abilities of mutating in certain sections. How good are you at using different materials to alter yourself? Are you doing it fast, are you doing it reliable? What are the kinds of mutations you do? Additional Limbs, natural weapons, brain-extensions?

Maybe the player does no polymorph himself, but can summon helpers, and in the process he also creates the body structure for his summons?

I think with this idea I would stick to some dystopical post-apocalypse setting. Thus you would use radioactive substances to do mutation. The concentration system (see details below) could be used to handle wanted and casual mutation: When you concentrate on mutating yourself (when you eat mutagenic stuff willingly), you will have more detailed options in describing the mutations you want to have, while the detail in casual mutation (caused through background-radiation maybe) will most likely be a little bit lower.

Damage usually is the result of impact, that is speed multiplied by mass. Many martial arts people try to maximize speed over mass, and are successful with that.

This is actually a really nice idea, but I don't see how I could model it right now. I'm open for suggestions.

Also, animals have horns/rams, claws, spikes and teeth to fight. You might want to equip the creature(s) with such, too.

Attributes like "pointy" or "sharp" should be implemented as tags - the could modify the damage rating.
Another advantage of those bodyparts would be, that they are not normally connected to the bloodsystem, so you've got not this much risk in them being hit - they may shatter, but this won't eat away on the rest of your body, because you won't loose any blood.

Add an "internal structure" attribute, that will serve two purposes: Once it determines how much mass outer limbs can have, until this limb fails to function. And in battle, internal structure will be a measure for the functionality for the limb chain. (E.g. if it's an arm, internal structure is the bones, and a broken bone renders an arm very much useless).

This sounds nice.
"Internal structure" could be even done through bodyparts consiting of more than one material, one describing structure, the other describing ability.

I feel uncertain about the concentration idea. Our brain handles a lot of tasks automatically for us, not only the low level stuff like heart beats, and breathing, the middle level stuff like walking or throwing, but it also filters a lot of sensoric input, and only the things that classify as "important" reach our conscious thinking. I think we can handle a lot of different input. What we are bad at, is trying to perform more than one task or activity at a time. In such cases our success rate at each drops quite a bit.

This sounds good.
But remember: We're not talking about normal usage of your senses, this is using 3D-hearing with construction of environment in your conciousness just by sound. Doing this with sound and eyes and smell at the same time should be nearly impossible. When using up concentration the system shouldn't consider normal use for alertion in emergency, just for concentrated use, like really determining an objects position solely on sound.

Thus instead of limiting input, I'd limit control. A human brain in a octopus shaped body will have troubles to control 8 tentacles in a sensible way. So maybe the more limbs there are to be controlled, or the more limbs are involved in an activity, the lower the rate of success becomes?

Sounds nice. The more bodyparts involved in an action (whether it is input or output, see above) the lower the success of this action (statistically).

Also, a semi-fluid body at times will allow to pass through small openings, but at the price of loosing all equipment. Lots of ideas to explore there for sure.

This will get hard. Influencing the flow of a liquid (maybe based on where the temperature is between melting and boiling point) by an AI or the player sounds nice.
A high ability to change the aggregate state of your body (which had to be surely highly homogenous) would make nice shapeshifters.

49

Programming / Re: Limb-oriented skill system - You see any pitfalls?

« on: October 16, 2009, 12:41:43 PM »

Wow, whole lotta posts!

Would like to answer directly to you, but this would disrupt train of thought I had while thinking about your posts.

Bodyparts actually get an additional mass or volume and a material (the material would have density and thus you wouldn't have to store mass and volume). The damage rating wouldn't be calculated in terms of strength alone, but in strength' percentage of mass. Defense would be calculated by dexteritie's percentage of volume (in some way similar as described in my first post).
You could alter bodyparts now in two ways: Changing mass/volume or the material. An example for this: muscles way more then fat, so muscles provide more actual strength then fat.
Now any bodypart has to carry all the bodyparts below it, so the more mass outer bodyparts have the more the inner have to carry. This would eat away at the strength and maybe dexterity of those bodyparts (because they have to be used to manage swinging those big limbs). This would prevent overuse of massive limbs. Adding limbs in processs of mutation wouldn't be a nobrainer.
At the same time big organisms would become more dangerous to small creatures. On the other side they most likely will be slower when not very much thought has been put into them.
So one ressource to handle would be mass.

Another idea is to use concentration - your brain can only handle this much things at a time, so you wouldn't be able to get everything out of your resolution-enhanced eyes and your bat-like ears, because your brain cannot handle this much at a time. Usage of some bodypart (wether it is for input or output) would enhance the ability to use this bodypart (while eating away on the ability of things you didn't use in a long time).
The player could create sets of actions to concentrate on at a time. This way he could switch from one use of his abilities to another at the appropriate times. Smelling and listening for searching, sight and your big arm in your belly for battle.
I think the game should be playable without using those sets - they would make things easier, but shouldn't be absolutely required to survive.
Next ressource to handle: concentration.

To keep the mass and functionality of your bodyparts intact, you have to eat. Mechanical bodyparts could be cept intact through other means: oil, an electric energy source, something like this.
The bigger and stronger you get, the more food you need to stay this way. You will need it to grow. With the concept of materials we even get "You are what you eat".

This system should heavily depend on learning by doing. Player choices would be made on strategics, what to eat and at which mutations you aim. Frankenstein-style would be nice. There should be a difference to "normal" mutations, though. Maybe faster to get but eating more concentration? Any ideas?

Handling attacks: Hajos idea seems appropriate. Maybe we could expand this a bit (with optionality to the game in mind): Let users write behaviour-scripts for his game. "No go explore (use this pattern) until something unexpected happens (soething, thats not handled in the pattern)." Crawl comes into mind.

Opinions on this?

50

Programming / Re: Limb-oriented skill system - You see any pitfalls?

« on: October 14, 2009, 02:48:34 PM »

It doesn't matter how you implement something, but it better be good in the gameplay. Some things may feel like great ideas in theory, but they just don't function properly in the game. I hope it will be fine.

Thats my question exactly - is it worth considering as actually good gameplay or is it just an idea-blob among many others?

@Hajo:
I am using Common Lisp, this should make bugtesting really easy for rule-systems that can be modeled functional. And this idea seems to be born to be implementet in functional style.

If you go IVAN++ then definitely, go for it. But unless your game makes really heavy use of the limb structure, it will first of all just slow down development, and will make all tasks involving creature bodies a bit harder. Make sure the gains in gameplay outweight the drawbacks.

The limb-structure was intended to be used heavily. I even had the idea of managing mutations in this manner, maybe even involving such things as blood-systems (for humans this might be just one system that is attached to all bodyparts, but more fantastic creatures may use more), nervous systems (for distributing pain through the body onto several limbs when only one is hit, which may be positive or negative in effect) and such things, but those are most likely to be overkill anyway.
On the other side this could get some kind of mutant-centered game, where you build up your body by yourself (at least partially), so character development would be on a completely different level. This way I could cut out anything that cannot be modelled throught the limb-system and is not absolutely crucial for the character concept to work.

I forgot to say in my last message that I found, there are only a few body structures which are commonly used:

- No limbs (snakes, worms, some fish)
- Naga type (2 arms, no legs)
- Humanoid (2/4 arms, 2 legs)
- Centauroids (2 arms, 4 legs)
- 4/6/8 legged creatures.

If you want to separate wings/tentacles from arms, you get a few more, but it doesn't bring something substantially new.

It's really difficult to work out a benefit of a tree structure over a list structure, or just a few sets of flags. The only real advantage that I see, is that a tree-structure can also implement joints, which list or set structures don't naturally keep track of.

When I actually go the way described above a list wouldn't be enough.
The difference between different forms of bodyparts I wanted to model through tags. This way the system would be easely extensible. This way feet could be tagged as "move", hands as "grab", tentacles as "move" and "grab", the head as "crucial to survival", the heart as "at-least-one" and so on...

51

Programming / Limb-oriented skill system - You see any pitfalls?

« on: October 14, 2009, 02:11:40 PM »

I am working on the design for my first roguelike right now.
So I had the idea to make a limb-based skill system that takes into account the physical composition of a creature. This should go beyond what's DF is doing but it should be easy to understand in principle, although it might be complex under the hood.

So far I've got only a system that may be appropriate for battle-related skills (because those should use the whole body).

The basic idea is to have limbs attached to each other in a hierarchical order, like a non-binary tree. The root of this tree should be the center of mass (one hand below your belly-button if you are a human). The nodes of this root are the different bodyparts where the connections between this nodes are joints which have a certain degree of freedom (between 0 inclusive and 100 exclusive in percent) - the joint to my upper arm is way more flexible then my elbow.
For every bodypart there now is a dextirity and a strength expressed through a number between -100 and 100 exclusive in percentages (so actually its between -1 and 1). Every attack is done through a special limb - a punch is delivered through your hand, a kick is done with your foot while you can choke someone with your upper or lower arm.
The chance-to-hit for an attack is calculated thorugh the limb you use to deliver the attack. The basic chance-to-hit is the dextirity of that limb. This chance is modified by the following rules:
Go one limb up, multiply the chance-to-hit with the joint rating between the bodyparts. If this is positive, this is the percentage that the original rating is moved into the direction of 100%. When this is negative, it's the percentage the chance-to-hit is moved into the direction of -100%.
This is done recursively to the center of mass.
The damage dealt through an attack is calculated similarly, except that the chance-to-hit of the next-upper bodypart is multiplied with (1 - joint-flexibility) instead of the joint-flexibility.

This seems calculation-intensive on first sight, but the calculated stats for the different bodyparts only change, when the strength or dexterity of a bodypart above the bodypart in question change or when the joint-flexibility of a joint above the bodypart in question change.

This system allows for different fighting styles which use different bodyparts in their attacks. You could even see weapons as just additional limbs with their own joint-flexibility, strength and dextirity. The negative ratings for strength and dexterity could be used to model pain or blockades.


Now this looks all shiny and nice to me, but there surely are some really nasty implications which I overlooked.
Some opinions on this?

52

Programming / Re: Ideas for AI partners

« on: October 11, 2009, 04:20:55 PM »

You could make the AI very customizable through a strategy interface. The game wouldn't be so much about hack and slay anymore, it would be a little bit closer to all those bot-programming games, just a little bit less complicated. Writing scripts of how to behave combined with keyboard makros (first hit a special key to mark the next one as command to your ally) to switch between different script (some could be provided from the very beginning) could make the game accessible to more players and the system more flexible.
"Seems Plan A doesn't work right, switch to Plan B!"

Friendly fire should at all means be included, I think. There is so much space for additional gameplay. Why cut out the challenge? With the system as described above this would be even more crucial: You wouldn't have to take care that you don't hurt your ally, you would have to take care that he won't blast you into pieces accidentally.

Of course this wouldn't be really newbie-friendly.