General Need help making my game's MaxVItal forumla.

[XerShade]

So I am currently trying to design the structures for entities in my game and have run into a little snag with how it calculates the max vitals for the vitals structure. The snag is that the formula needs EntityStats but EntityVitals does not have access to that, and I would prefer to keep it that way so I am not tossing references around the place.

Here is my project structure for what I am working with.

• Data
  • Entity - The entity object.
• Logic
  • LogicEntities - The static class where my GetEntityMaxVital function will be.
• Strcutures
  • EntityStat - A single entity stat structure.
  • EntityStats - The structure that defines entity stats.
  • EntityVital - A single entity vital structure.
  • EntityVitals - The structure that defines entity vitals.

 

Any help would be greatly appreciated.
-XerShade

[Robin]

Try not to get too caught up in encapsulation exercises in game development. Strict object hierarchies are always going to end up causing problems.

 

Why should all entities have stats? Or vitals? Why should entities that have vitals have stats?

 

Instead, you want a system where you can build entities through composition. Entity-Component-System is a pretty good example of this.

 

Entities are your game objects - they have no real state by themselves until you start adding...

Components are your 'data'. They define the state of the entity. These can be processed by...

Systems are where the majority of your game logic go. These register interest in entities based on their component composition and pull/push data between them.

 

In your specific example, anything that inherited from 'Entity' would be forced to have a bunch of stuff that might not be required. Worse yet, you'd start having to have all kinds of identifiers to dictate behaviour, or what systems that entity should be processed by.

 

Here's what your code could look like in the context of an ECS:

class CombatStats : Component
{
	public int strength;
	public int endurance;
	public int dexterity;
}

class CombatVitals : Component
{
	public int health;
	public int mana;
}

class CombatScene : Scene
{
	// create a player entity
	var player = createEntity();
	player.addComponent(new CombatStats());
	player.addComponent(new CombatVitals());
	
	// create an attackable object
	var something = createEntity();
	something.addComponent(new CombatVitals());
	
	// create a system that registers attacks
	addSystem(new CombatSystem()).registerInterest(typeof(CombatVitals));
}

class CombatSystem : System
{
	void process(Entity entity)
	{
		// get the stats of the entity attacking us
		combatStats = entity.attackedBy.getComponent<CombatStats>();
		
		// do damage to our vitals
		combatVitals = entity.getComponent<CombatVitals>();
		
		combatVitals.health -= combatStats.strength;
		
		// check if we've died
		if (combatVitals.health < 0)
			entity.destroy();
	}
}

With no strict link between vitals and stats, you can re-use them in other ways. By using systems which register interest in entities based on their composition, you can easily register/deregister entity functionality by simply not adding systems to a scene, or by having more specific composition matching patterns.

 

For example, we've created an entity that has no stats but can be destroyed because it has health. Likewise, we could easily just not create the combat system and disable combat on that scene/map.

 

There are the de facto standard in game development now, so if you're starting off a new project I'd suggest you read up on it a bit. I haven't looked back since using this type of architecture.

 

Further reading:

 

Understanding component-entity systems

 

Entity-Systems Wiki

 

Introduction to entity systems

 

Refactoring Game Entities with Components

 

Component Based Engine Design