I am overburdened, loot is forever news

Post news Report RSS I am overburdened, loot is forever

This entry turned out to be lengthy and pretty technical. Sorry about that, but last week was spent only on "under the hood" stuff. So the agenda is the item system which became really sophisticated, especially compared to the size of the game + the difficulty and pacing management.

Posted by Spidi777 on Feb 21st, 2017

Hello everyone!

This entry turned out to be lengthy and pretty technical. Sorry about that, but last week was spent only on "under the hood" stuff. I did my best to make it interesting though ;) ! So the agenda is the item system which became really sophisticated, especially compared to the size of the game + the difficulty and pacing management.

I settled on the video format of the last entry, because EP 3 was the most pleasant recording experience and in my eyes it was the most enjoyable video so far. So from now on, I'm going for condensed and "scripted" logs focusing on the features and development of the game.

Items, loot

The plan for the game is to have a wast and diverse set of unique items (approx 100). Since no leveling will take place, the player will have to risk collecting as much loot as possible during the journey and focus on customizing the play-style by carefully picking which items to wear. So the technology behind the game has to support a great number of skills and excessive customization of the items, but also has to allow lightning fast iteration times, since I will be spending a significant amount of time during the upcoming 2 to 4 weeks with designing and balancing the possible loot.

Attribute bonuses

The easiest development was attribute bonuses on items. Adding the following piece to the descriptor of an item in the loot configuration file will provide the given bonus attributes to the player while equipped:

<Attributes>
	<Attack>1</Attack>
	<Defense>2</Defense>
	<Vitality>3</Vitality>
	<Speed>4</Speed>
	<Luck>5</Luck>
</Attributes>

I highly recommend calculating most of the final modifiers and attributes of a character in RPGs every time one is needed. The more caching you introduce into these systems, the more groundwork you lay for pesky bugs to occur, so keep it low! Usually these calculations are pretty simple (will never be a performance hit) and the hard-coded constant formulas will be really straight-forward to follow.

public class Attributes
{
	public int Attack;
	public int Defense;
	public int Vitality;
	public int Speed;
	public int Luck;
	
	// events ...
}

public class Player
{
	public Attributes Attributes;
	
	// handle pick-ups and other logic related to permanent attributes...
}

public class Inventory
{
	public Attributes Attributes;
	
	// handle item pick-ups and other logic related to item attribute bonuses...
}

The player data holds the permanent attributes of the character (starting attributes + permanent power-ups) and the inventory holds the sum of the attribute bonuses from the equipped items (only a tiny bit of caching) recalculated every time it is changed (e.g.: item pick-up, item swap etc...). The final value of an attribute is the sum from these two structures and the modifiers queried from the extra skills of the equipped items applied to it.

Skills, event system

For a high level of flexibility and to have a varied set of special skills I implemented an event system. I followed a similar but a bit more dynamic approach as the built-in event language feature of C#. Essentially an event is a string (the name of the occurred event) and a context holding additional data related to it and a skill is an event handler implementation.

Event systems can be implemented a number of ways each having their strengths and weaknesses, but all-in-all the following is pretty close to the my solution:
WARNING pseudo code incoming!

// Actual skills need implement this class:
public abstract class Skill
{
	public void HandleEvent(string name, EventContext context)
	{
		if (this.EventsHandled.Contains(name))
		{
			// Additional checks related to the context...
			
			TakeEffect(name, context);
		}
	}
	
	protected abstract void TakeEffect(string name, EventContext context);
	
	// Some helper methods...
	
	public HashSet<string> HandledEvents;
	
	// Additional requirements for the event & context...
}

// Special events extend this structure to "add" extra data to the event context:
public class EventContext
{
	// The creature whose action lead to the event:
	public Entity Creature;
}

The execution of the "TakeEffect" method can also be chance based (luck of event firing creature is taken into account). so a skill may only take effect with a given chance (e.g.: 10% chance to "XYZ" types).

An item can have a list of skills listening for events when equipped by a creature. Some events pass in an extension of the "EventContext" class with extra information, like the damage dealt, or the target creature attacked etc...

Few of the most common events in the game:

NextDungeonReached: the player reached the next level.
Attacking: a creature starts attacking.
OpenChest: the player just opened a chest.
Pickup: the player picks up a bonus item (e.g.: health potion, gold sack etc...)

Some of the existing skill implementations:

Attribute: grants a "bonus" for the upcoming trial (e.g.: +10 luck for the next luck trial).
Cripple: interrupts the next attack of the target.
Thorns: reflects a "bonus" amount of damage to the attacker.
Vampiric: a "bonus" amount of the damage dealt is healed to the attacker.

"bonus" == modifier applied to an integer value. Can be an integer like +/- 5 or a percentage like +/- 5%. The integer bonuses are applied first and the percentage modifiers afterwards.

Most of these events and skills took only a few lines of code to integrate and I have several more ready and working. Combing and configuring them to take effect on specific events with various chances is already an immensely versatile system to build items :) !

Difficulty, pacing

It's important to constantly introduce new content and to increase the difficulty curve so the player always finds a challenge while progressing deeper into the depths of the dungeon. I achieve this with a construct called "dungeon profile". For each level of the story (currently planning to have around 30) a profile will specify which tile-set to use, what kind of monsters can be spawned and what type of pick-ups, treasures and chests can be placed. Of course this data is read from asset files and it is fed into the dungeon generator after constructing the layout for a level. This gives fine control over the length, the pacing and the minute to minute difficulty changes of the whole game without modifying a single line of code.

Yep, last week was rather busy, though I'm behind my schedules once again :( . A little more than a week ago I was confident I will have some (even if not many) art assets done for the game by now. Sadly slipped a little. This is the next step though, so the following entry will have pretty sprites and screenshots ;) !

Stay tuned!