The Bard Tree - Networking

Networking - Development

Apr 26, 2018. | By: Isaac Mulcahy
5 mins

The final game involved a group project which consisted of four of us. The task was to develop a game which utilized networking in a turn-based combat game. The group decided to make a game that would resemble ‘South Park: The Fractured But Whole’ in both combat system and comedic tone.

Communication within the group wasn’t the best and resulted in some issues with developing the game. This also made some members of the team to panic and make drastic changes to the concept and game without consulting the rest of the team. I myself didn’t do great with communication as I did miss an important meeting with the team which was where the game was concepted due to illness but I did try and provide other means of communication.

Development

With development I was able to have the task of developing the character system and abilities. The first step I took in this development was to tidy up pre-existing code that was present for this system. This involved renaming of some objects to allow for easier readability and maintenance. I also developed a more object-oriented approach for the systems as the existing code had a lot of duplication in. With this tidying, I removed unneeded functions and added new ones with appropriate names.

I then added a character system which used polymorphism to create the class system. These classes were based on the new class ‘Entity’ which derived from the old class in this project called ‘Player’ but a lot more tidied up and removed unneeded sections as stated above.

class Mage : public Entity
{
public:
	Mage();
	~Mage() = default;

	void attack(int attack_id, Abilities* ability, Grid& world, bool execute_ability) override;
};

The constructors for this system would then assign the stats to the characters on creation. This was all kept in a ‘Classes’ file adding to the ease of use as everything to do with class definitions was kept in one place.

Ability System

After this I developed the ability system which was designed to be flexible and allow for abilities to be used by more than one class. This worked by having an object which held all the abilities. The attack function from the ‘Entity’ was a virtual one which allowed for the function to be able to overwritten, I also developed an ‘id’ system which was how each ability was chosen. This allowed for an easy interface and scalability.

void Mage::attack(int attack_id, Abilities* ability, Grid& world, bool execute_ability)
{
	switch (attack_id)
	{
	case 1:
		ability->Stab(this, world, execute_ability);
		break;
	case 2:
		ability->Fireball(this, world, execute_ability);
		break;
	case 3:
		ability->Heal(this, world, execute_ability);
		break;
	}
}

The ability system was developed to allow for vast functionality and quick development of new abilities. This was achieved by having functions which could be called upon for directions of abilities.

void Abilities::abilityForward(Entity* attacker, Grid& world, int min, int max, TILE_STATE type)

As you can see from the code snippet the function takes the position of the attacker, the grid system, min and max as well as what type. The attacker is needed to compare within the grid where the attacker is. The min and max are then used to define what range in front of the attacker the ability will affect. The reason it needs the grid system is so it can use it to find out where entities are within the grid. It is also used to give the visual cues of what can be/ is happening. The type state is so the programmer can change the visual cues to offensive, buff etc. These functions are then used within an ability to define it as you can see below:

void Abilities::Stab(Entity* entry, Grid& world, bool execute_ability)
{
	// Show range
	abilityForward(entry, world, 1, 3, TILE_STATE::ATTACK);
	abilityForward(entry, world, -2, 0, TILE_STATE::ATTACK);
	abilityLeft(entry, world, 1, 3, TILE_STATE::ATTACK);
	abilityLeft(entry, world, -2, 0, TILE_STATE::ATTACK);

	if (execute_ability == true)
	{
		std::vector<Entity*> candidates = world.entitiesHit();

		for (int i = 0; i < candidates.size(); i++)
		{
			candidates[i]->damage(10);
		}
	}
}

This system as well works for both executing the ability but also for showing the visual range. Within the function the coder can easily define what the ability does and this can apply to all or whoever the coder wants within the ability range (e.g. only knights, below certain health etc.).

Grid System

The grid system which existed before my development of the ability system didn’t exist as a ‘Gird’ at it was just a visual representation with each of the objects within the game holding variables stating where it was within the grid. This system didn’t have a central point and would have been cumbersome to use effectively. I with permission from the team recoded the entire system in this section.

The old ‘grid’ object got changed to tile and controlled the visual representation (this used mostly the old ‘gird’ object and got renamed to ‘tile’ and removed unneeded variables and functions from it). I then created a vector of pointers to the objects within the grid which could then be used for functionality such as for finding specific object coordinates and also objects within certain places. By adding this system, it greatly improved accessibility to grid data and made my ability system work.

I then removed the original constructor of grid object and replaced it with one which required the coder to define the grid size on creation and tile width/height. At construction of the grid the vectors are dynamically sized to the correct proportions.

Conclusion

These systems unfortunately didn’t make it into the game due to changes in design that were made by some of the team. Even though these systems didn’t make it into the game I am still proud of the work I did towards the project and felt I learnt a lot and grew my design and coding skills.

Networking - Development

Networking - Development

Subscribe

Categories

Recent Posts

Popular Tags

About

Social Links

Our Bunker