greetings
i have been building a pbbg in ASPX.NET with c# and i would like some opinions on the combat formulas, equip system and shop system
right now i only have simple combat implemented ((physical damage * strength) * (5 / player Resistance));
i can show what i have equiped but i don't have a way of the player equip the character
and i dont have a shop system implemented
[web] text based game
Ahh, a project that I can really sink my teeth in. Excellent!
Ok, so my first question is not about combat, equipment, or shop. It's how do you represent a player and NPC in the game (in terms of game objects). Do you have objects that have a body? Is it classical class-based hierarchy or component based entities? Google Component-Based Entity game development and you'll find a bunch of good articles on why component-based entities.
Now a broad answer that may not really help you since I don't know your exact setup, but could provide some insight.
When I did MUD development, every living thing inherited from a Race class that defined the body layout (based on a configuration file for that race) from the type of skin, to torso and and number of limbs, down to the number of fingers per hand. Equipment had a property that defined what type of limb it goes with (i.e. hand, arm, leg, foot, etc).
When you equipt an item, the system first checked the type of limb that is needed. It then checked the body to see if there was anything already on that limb. If not, then it basically set the item state to Equipt and which limb it was on. It also set on the limb the equipment that was tied to it.
Now with regards to combat, the actual formula got really complex. I'm going to try to recall how we did it, but it's kind of foggy right now.
The skill system the MUD used had an offensive and defensive version of a particular type of attack (based on the weapon type). Someone could really be proficient in sword-based attacks but horrible at blunt-based attacks. That person could also be really good at defending/avoiding projectile type attacks. The skill level indicated the success rate from 1 to 100. We then took a random number between the attacker's offense skill + luck and also a random number between the defender's defense skill + luck. The difference between the number indicated not only if the attack was successful, but what % of the weapons maximum damage the attack inflicted.
That damage was then applied to the target. Damage had to go through layers before it actually hurt the player. These layers were the layers of protection that the armor or other protection provided. As it went through the layers, the actual damage amount was lowered based on how the armor handled it. Some armors (and protections) absorbed certain types of damage much better than others. Some types of damage couldn't be stopped (i.e.: mental damage type spells). If by the time the damage reached the body it was zero, we outputted a message that the person hit, but the target seems unaffected by it. We also wrote messages based on the level of success (or miss) of the attack, such as 'Player A deals a devastating blow to Player B' or 'Player A completely misses Player B, hitting nothing by air.'
So as you can see, combat isn't a simple formula of a + b = damage. There is a good amount of thought that goes into it based on the current weapon, the type of attack and the defender. I have a feeling this wasn't the final implementation of it, but fairly close.
Ok, so my first question is not about combat, equipment, or shop. It's how do you represent a player and NPC in the game (in terms of game objects). Do you have objects that have a body? Is it classical class-based hierarchy or component based entities? Google Component-Based Entity game development and you'll find a bunch of good articles on why component-based entities.
Now a broad answer that may not really help you since I don't know your exact setup, but could provide some insight.
When I did MUD development, every living thing inherited from a Race class that defined the body layout (based on a configuration file for that race) from the type of skin, to torso and and number of limbs, down to the number of fingers per hand. Equipment had a property that defined what type of limb it goes with (i.e. hand, arm, leg, foot, etc).
When you equipt an item, the system first checked the type of limb that is needed. It then checked the body to see if there was anything already on that limb. If not, then it basically set the item state to Equipt and which limb it was on. It also set on the limb the equipment that was tied to it.
Now with regards to combat, the actual formula got really complex. I'm going to try to recall how we did it, but it's kind of foggy right now.
The skill system the MUD used had an offensive and defensive version of a particular type of attack (based on the weapon type). Someone could really be proficient in sword-based attacks but horrible at blunt-based attacks. That person could also be really good at defending/avoiding projectile type attacks. The skill level indicated the success rate from 1 to 100. We then took a random number between the attacker's offense skill + luck and also a random number between the defender's defense skill + luck. The difference between the number indicated not only if the attack was successful, but what % of the weapons maximum damage the attack inflicted.
attack_level = attack + luck;
defend_level = defend + luck;
success = (Math.Random(attack_level) - (Math.Random(defend_level));
//If success < 1, then the attacker missed
if(success < 1)
return;
//Damage is based on the maximum damage * the success level. The success level / attack can be over 100% (a lucky hit)
damage = max_damage * (success / attack);
That damage was then applied to the target. Damage had to go through layers before it actually hurt the player. These layers were the layers of protection that the armor or other protection provided. As it went through the layers, the actual damage amount was lowered based on how the armor handled it. Some armors (and protections) absorbed certain types of damage much better than others. Some types of damage couldn't be stopped (i.e.: mental damage type spells). If by the time the damage reached the body it was zero, we outputted a message that the person hit, but the target seems unaffected by it. We also wrote messages based on the level of success (or miss) of the attack, such as 'Player A deals a devastating blow to Player B' or 'Player A completely misses Player B, hitting nothing by air.'
So as you can see, combat isn't a simple formula of a + b = damage. There is a good amount of thought that goes into it based on the current weapon, the type of attack and the defender. I have a feeling this wasn't the final implementation of it, but fairly close.
Will your game be PvP (ie, one player vs. all other players in the game) or more of an RPG (you vs. a pre-generated set of computer opponents)? Your answer will tell me what type of system you need.
Author
greetings
i represent the player by level, strength, agility, resilience, intelligence, dexterity, stamina
right now i got a crapy class to get the attributes of the player a then i make them attack each other other until the hp off one player its zero
i represent the player by level, strength, agility, resilience, intelligence, dexterity, stamina
right now i got a crapy class to get the attributes of the player a then i make them attack each other other until the hp off one player its zero
public player(int istm, int istr,int iintl,int iagl,int idex,int ilevel,int ires)
{
stm = istm;
str = istr;
intl = iintl;
agl=iagl;
dex = idex;
level = ilevel;
res = ires;
mp = Convert.ToInt32(Convert.ToDouble((18 * level) * (Convert.ToDouble(intl) / 2)));
hp = Convert.ToInt32(Convert.ToDouble(18 * level) * (Convert.ToDouble(stm) / 3));
}
Ahh, a project that I can really sink my teeth in. Excellent!
Ok, so my first question is not about combat, equipment, or shop. It's how do you represent a player and NPC in the game (in terms of game objects). Do you have objects that have a body? Is it classical class-based hierarchy or component based entities? Google Component-Based Entity game development and you'll find a bunch of good articles on why component-based entities.
Now a broad answer that may not really help you since I don't know your exact setup, but could provide some insight.
When I did MUD development, every living thing inherited from a Race class that defined the body layout (based on a configuration file for that race) from the type of skin, to torso and and number of limbs, down to the number of fingers per hand. Equipment had a property that defined what type of limb it goes with (i.e. hand, arm, leg, foot, etc).
When you equipt an item, the system first checked the type of limb that is needed. It then checked the body to see if there was anything already on that limb. If not, then it basically set the item state to Equipt and which limb it was on. It also set on the limb the equipment that was tied to it.
Now with regards to combat, the actual formula got really complex. I'm going to try to recall how we did it, but it's kind of foggy right now.
The skill system the MUD used had an offensive and defensive version of a particular type of attack (based on the weapon type). Someone could really be proficient in sword-based attacks but horrible at blunt-based attacks. That person could also be really good at defending/avoiding projectile type attacks. The skill level indicated the success rate from 1 to 100. We then took a random number between the attacker's offense skill + luck and also a random number between the defender's defense skill + luck. The difference between the number indicated not only if the attack was successful, but what % of the weapons maximum damage the attack inflicted.
attack_level = attack + luck;
defend_level = defend + luck;
success = (Math.Random(attack_level) - (Math.Random(defend_level));
//If success < 1, then the attacker missed
if(success < 1)
return;
//Damage is based on the maximum damage * the success level. The success level / attack can be over 100% (a lucky hit)
damage = max_damage * (success / attack);
That damage was then applied to the target. Damage had to go through layers before it actually hurt the player. These layers were the layers of protection that the armor or other protection provided. As it went through the layers, the actual damage amount was lowered based on how the armor handled it. Some armors (and protections) absorbed certain types of damage much better than others. Some types of damage couldn't be stopped (i.e.: mental damage type spells). If by the time the damage reached the body it was zero, we outputted a message that the person hit, but the target seems unaffected by it. We also wrote messages based on the level of success (or miss) of the attack, such as 'Player A deals a devastating blow to Player B' or 'Player A completely misses Player B, hitting nothing by air.'
So as you can see, combat isn't a simple formula of a + b = damage. There is a good amount of thought that goes into it based on the current weapon, the type of attack and the defender. I have a feeling this wasn't the final implementation of it, but fairly close.
To start off simple, you should have at least the following classes:
That is your normal start to any Game Object library. Give it a go. At some point, though, you will want to look into Component-Based Entity Game Object Library
- GameObject - A class representing an in-game object
- Living - A class representing any living object that inherits from GameObject. This class will contain properties and methods defining the living's body as well as attributes and skills.
- NPC - A class representing any NPC character that inherits from the Living class. This class will add AI to any living thing.
- Player - A class representing a player. This class processes user input. You could technically make Player inherit NPC and override the AI part.
That is your normal start to any Game Object library. Give it a go. At some point, though, you will want to look into Component-Based Entity Game Object Library
Author
To start off simple, you should have at least the following classes:
- GameObject - A class representing an in-game object
- Living - A class representing any living object that inherits from GameObject. This class will contain properties and methods defining the living's body as well as attributes and skills.
- NPC - A class representing any NPC character that inherits from the Living class. This class will add AI to any living thing.
- Player - A class representing a player. This class processes user input. You could technically make Player inherit NPC and override the AI part.
That is your normal start to any Game Object library. Give it a go. At some point, though, you will want to look into Component-Based Entity Game Object Library
what do you mean for gameObject? its a piece of armor or weapon and it has the those items attributes or its an in-game object like a chair or something
sorry for this kind of questions but this is my first approach to game programing
[quote name='Dino' timestamp='1305053356' post='4809079']
To start off simple, you should have at least the following classes:
- GameObject - A class representing an in-game object
- Living - A class representing any living object that inherits from GameObject. This class will contain properties and methods defining the living's body as well as attributes and skills.
- NPC - A class representing any NPC character that inherits from the Living class. This class will add AI to any living thing.
- Player - A class representing a player. This class processes user input. You could technically make Player inherit NPC and override the AI part.
That is your normal start to any Game Object library. Give it a go. At some point, though, you will want to look into Component-Based Entity Game Object Library
what do you mean for gameObject? its a piece of armor or weapon and it has the those items attributes or its an in-game object like a chair or something
sorry for this kind of questions but this is my first approach to game programing
[/quote]
Everything in your game should be based off of GameObject. It represents any in-game entity that can be interacted with. Armor, Item, Chair, Person, etc. It also contains very fundamental functionality that all in game objects have, such as position and size.
This is your typical class-based hierarchical approach.
Author
[quote name='invalid123' timestamp='1305101766' post='4809316']
[quote name='Dino' timestamp='1305053356' post='4809079']
To start off simple, you should have at least the following classes:
- GameObject - A class representing an in-game object
- Living - A class representing any living object that inherits from GameObject. This class will contain properties and methods defining the living's body as well as attributes and skills.
- NPC - A class representing any NPC character that inherits from the Living class. This class will add AI to any living thing.
- Player - A class representing a player. This class processes user input. You could technically make Player inherit NPC and override the AI part.
That is your normal start to any Game Object library. Give it a go. At some point, though, you will want to look into Component-Based Entity Game Object Library
what do you mean for gameObject? its a piece of armor or weapon and it has the those items attributes or its an in-game object like a chair or something
sorry for this kind of questions but this is my first approach to game programing
[/quote]
Everything in your game should be based off of GameObject. It represents any in-game entity that can be interacted with. Armor, Item, Chair, Person, etc. It also contains very fundamental functionality that all in game objects have, such as position and size.
This is your typical class-based hierarchical approach.
[/quote]
meaning things like how much money a mission would give, how much armor a breastplate would give and much money a player would need to pay in the shop right?
Not really. GameObject is your very lowest level class. It should only contain properties and methods that are applicable to all other objects in your game, like size, position, value, and visuals (i.e. images), and methods like Update, Initialize, and Destroy.
Your Armor class would inherit from GameObject
Your Sword class would inherit form Weapon, which inherits from Item, which inherits from GameObject.
Your shop would technically contain a vendor who inherits from NPC, who inherits from Living, who inherits from GameObject.
Again, this is the approach using classical inheritance found in .NET. Now I'm going to completely confuse you and make your head swim.
There is another approach, and that is designing your objects where everything is an entity (basically, a class that inherits from System.Collection.Generic.Dictionary<string, GameComponent>) and you add components that give your entity functionality. Components would all inherit GameComponent and add in specific functionality based on their purpose.
For example, a player Entity would have the following components:
A Sword Entity would have the following components:
A Chest Entity would have the following components:
The benefit of this system is that you can define small self-contained components that serve a single purpose and match them up at runtime to dynamically create new Entities at runtime. You can easily define entities using an XML file that simply states the list of components it uses. Take this as an example
As you can see, creating a new type of weapon is as simple as putting together a new XML configuration file. When an entity is created, the engine will instantiate a blank Entity object. It will then loop through all the component nodes in the main node. For each node, it will create the appropriated Component object (using .NET Reflection) and pass the XML node to the component in the constructor. That component will know what to do from there.
Your Armor class would inherit from GameObject
Your Sword class would inherit form Weapon, which inherits from Item, which inherits from GameObject.
Your shop would technically contain a vendor who inherits from NPC, who inherits from Living, who inherits from GameObject.
Again, this is the approach using classical inheritance found in .NET. Now I'm going to completely confuse you and make your head swim.
There is another approach, and that is designing your objects where everything is an entity (basically, a class that inherits from System.Collection.Generic.Dictionary<string, GameComponent>) and you add components that give your entity functionality. Components would all inherit GameComponent and add in specific functionality based on their purpose.
For example, a player Entity would have the following components:
- Physics - Defines the physical properties of an entity like size, position, and direction
- Visuals - Defines the visuals used when showing this to a player (images, description, etc).
- Body - Defines the body attributes of an entity like race and limbs
- Condition - Defines the health/condition of an Entity. This is often referred to as Hit Points.
- Magic - Defines the magical properties of an Entity, include the level of magic points.
- Attributes - Defines the Entities physical attributes like Strength, Intelligence, Wisdom, Dexterity, Constitution, and Charisma.
- Combat - Define the combat system used by this entity
- Inventory - Provides the ability for an entity to hold other Entities
- Command - Handles command processing. When a player sends 'give book to Krem', the Command component receives that command, parses it, and dispatches the appropriate messages to all objects involved (player, Krem, and the book)
A Sword Entity would have the following components:
- Physics - Defines the physical properties of an entity like size, position, and direction
- Visuals - Defines the visuals used when showing this to a player (images, description, etc).
- Condition - Defines the health/condition of an Entity. In the case of a sword, this would indicate how worn an Entity is.
- Weapon - Defines attributes specific to a weapon, such as the ability to wield, damage calculators, etc.
A Chest Entity would have the following components:
- Physics - Defines the physical properties of an entity like size, position, and direction
- Visuals - Defines the visuals used when showing this to a player (images, description, etc).
- Condition - Defines the health/condition of an Entity. This is often referred to as Hit Points.
- Inventory - Provides the ability for an entity to hold other Entities
The benefit of this system is that you can define small self-contained components that serve a single purpose and match them up at runtime to dynamically create new Entities at runtime. You can easily define entities using an XML file that simply states the list of components it uses. Take this as an example
<entity id="Game.Items.Weapons.Swords.Krem's Sword">
<component type="Physics">
<!-- Size is a cube (width, height, depth) in Inches -->
<size>6,42,2</size>
<!-- Weight in Lbs -->
<weight>10</weight>
<!-- A vector value in the format of X,Y,Z -->
<direction>0,0,0</direction>
<!-- Indicates if the entity is grounded or floating -->
<grounded>true</grounded>
</component>
<component type="Visuals">
<!-- The basic text to output when someone looks at the entity -->
<textDescription>Krem's sword is a typical double-bladed sword. It is quite bland</textDescription>
<!-- The image to show when someone looks at the entity -->
<imageURL>\game\images\krems_sword.png</imageURL>
</component>
<component type="Condition">
<!-- The maximum value for the condition of an entity -->
<maxValue>100</maxValue>
<!-- The initial/current value for the condition of an entity -->
<currentValue>100</currentValue>
<!-- The rate (as a decimal number) at which the condition is restored. Can be a negative value for Entities that decay like corpses. -->
<regnerationSpeed>0.0</regnerationSpeed>
</component>
<component type="Weapon">
<!-- The attribtues required in order to use this Weapon. Some Weapons require more strength or dexterity than others to use them -->
<requiredAttributes>
<attribute name="Strength" minValue="5" />
<attribute name="Dexterity" minValue="5" />
</requiredAttributes>
<!-- Maximum amount of damage this Entity can inflict. The actual damage is based on the hit success and could be greater than maximumDamage for special hits -->
<maximumDamage>10</maximumDamage>
<!-- The type of damage this Entity inflicts-->
<damageType>Blade</damageType>
<!-- Indicates how quickly an items can be used. Some weapons take longer to use, like reloading a bow or swinging a very large sword, versus others like a small dagger -->
<usageSpeed>Normal</usageSpeed>
</component>
</entity>As you can see, creating a new type of weapon is as simple as putting together a new XML configuration file. When an entity is created, the engine will instantiate a blank Entity object. It will then loop through all the component nodes in the main node. For each node, it will create the appropriated Component object (using .NET Reflection) and pass the XML node to the component in the constructor. That component will know what to do from there.
Author
although I'm making a text based pbbg forgive me if i'm wrong is there any need to make a class to save things like size(only if its size on the inventory) , direction and position ?
images and updates i understand a little since i as thinking off using a sql database for keeping user stuff although im only thinking off implementing images when i think the system is good to go
images and updates i understand a little since i as thinking off using a sql database for keeping user stuff although im only thinking off implementing images when i think the system is good to go
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
