I am overburdened, loot is forever.

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

2017_02_19_screenshot_1

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

2017_02_14_gif_1

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 🙂 !

Tags

String tags can be added to a creature when describing it in a configuration file, like: undead, deamon, boss etc… The event system allows to define tag requirements for targets before a skill can take effect. A creature meets a given a requirement if it does not have any tags from its “can not have” set of tags and has all the tags from its “must have” set of tags. It is as simple as that.

2017_02_20_gif_1

2017_02_20_gif_2

This tiny addition allows skills which have real “character” to be made. Some cool examples would be monsters tagged as “undead” and a life-steal granting sword which does not work on them (pictured in the GIF), or a holy shield which grants enormous extra defense, but only when attacked by monsters tagged as “deamon”. This also allows to disable certain skills against bosses which could make them too overpowered otherwise.

I’m still at the beginning when it comes to designing the concrete items, but with these systems in place I hope I’ll have a pleasant experience while implementing the actual artifacts. As closing words for the loot topic, here is a rather complicated item description just to show how this is all put together in configuration files:

<!--
  Forearm armor:
    +1 Defense
    20% chance to cripple non "Boneless" enemies
-->
<ItemDescriptor>
  <Type>Forearms</Type>
  <Name>Vambraces</Name>
  <Sprite>Item22</Sprite>
  <Level>1</Level>
  <Attributes>
    <Defense>1</Defense>
  </Attributes>
  <Skills>
    <Skill>
      <Cripple>
        <EventHandled>InflictDamage</EventHandled>
        <ChanceBased>true</ChanceBased>
        <Chance>20</Chance>
        <TargetTags>
          <CantHave>
            <string>Boneless</string>
          </CantHave>
        </TargetTags>
      </Cripple>
    </Skill>
  </Skills>
</ItemDescriptor>

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.

2017_02_20_pacing_1

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!

I am overburdened, monsters and mods.

Hi there!

Small update this time. Been working on wrapping up all the remaining core features, but got a bit sidetracked so I’m going to write a little about level editing too besides monsters + I’m trying out yet another video setup.

This video is the most condensed so far, focusing exclusively on last week’s development and showcasing gameplay features. I thought making a third video using this form will result in a diverse and easily comparable set and will help to draw my final conclusions about the series.

So it is short (3 minutes), maximally to the point and heavily “scripted” 🙂 :

Monsters

2017_02_11_gif_1

During this week, I pretty much completed all the logic related to the monsters of the game. From their type description (sprites, attributes, inventory?! 😮 🙂 😛 , database of monster types etc…), all the way to battling with them. Also filled the game with a bunch of placeholder monster sprites/types to test it out, and now it feels like a real rogue-like with character advancement, treasures and risk of death 🙂 .

Battle system

Once you try to move to a tile occupied by a monster a “battle” starts. Both entities will take their turns to attack, the faster one (speed attribute) will start or it will be decided with luck trials if there is a match. If both contestants survive the first attack the slower/unlucky entity strikes back, and shortly after the player gets back input control.

Levels and modding

Official mod support is sadly out of the scope of this project, but I still managed to come up with a clean solution for a “half-offical” way 🙂 . Since all the configuration files (monster/pickup/chest types, starting attributes, spawn profiles, item skills) will be shipped as plain XML files, huge part of the game can be tweaked with a plain old text editor, but for a pleasant level editing experience that will not suffice…

Tiled

2017_02_11_tiled_1

2017_02_11_tiled_2

I decided to ship the game with built-in support for the the Tiled editor. Now the game can read plain tmx files. Never made a run-time parser for it before, but I used this editor multiple times so it was a natural choice. The final package will also feature a pre-built tile set for Tiled map files (placeholder one pictured) and a written guide on specific map properties related to the game.

2017_02_11_screenshot_1

By the next entry I will have all the missing bits and pieces of the game-play loop implemented (difficulty management and item skills) and the game will be pretty much fully playable albeit lacking content or balance. As always, open for questions, comments and critique.

Take care!

I am overburdened, prototyping.

Hello everyone!

I worked on a lot of stuff since my last post:

  • Thought a lot about the content/format of my blog and my freshly started video series, and made some decisions about their future.
  • Worked on the linux/mac port of KREEP, but still no announcements yet (but not far).
  • Lot of progress on the development of “I am overburdened”, although not as much as I hoped 😐 …

Blog

Both the last video and blog entry were huge in length and quite empty (video was okay? I guess as the first one). My goal with the series is to have a little introspection of the development process and to showcase the games I’m working on + to gather some interest for them. Of course with dreadfully uninteresting videos this is not going to happen 😀 . Cooked up these rules and goals to try to fix this:

  • Cut short the videos or fill them with more “action” (50+% game/feature showcase sounds about right).
  • From now on measure word-count and aim for 500 to 600 word long written entries.
  • Made an introduction video. This allows omitting the silly “greeting and explanation” section from the upcoming entries.
  • Embrace “freestyle” recording to act more naturally (+ to cut down the time it takes to prepare an entry).
  • Increase recording quality.

So here it is, in it’s full glory, episode two:

As always, open for critique and comments both for the video and the blog entry. Please leave them here or below the video, so I can make better follow-ups.

Progress

Steady, but a tad bit slow. I hoped I could complete all the core features by now, but failed to implement monsters. It is starting to become a real game though, but I’m still in the “prototyping” phase, hence the title. Here goes last weeks progress in GIFs:

RPG layer

2017_02_02_gif_1

The RPG design and its implementation is mostly complete. Our hero has health points (damage, healing and death when reaching 0 works), and the main attributes are done (most of it is integrated and takes effect on certain events).

  • Attack: damage output.
  • Defense: damage reduction.
  • Vitality: maximum health points.
  • Speed: who attacks first.
  • Luck: luck trial influence (item find chance, potion efficiency etc…)

Pickups

2017_01_31_gif_1

Treasures scattered around the dungeon floor are fully functional. There are various types (e.g.: gold sacks, health potions, permanent attribute bonuses, random artifacts), with varying probabilities to be spawn. The system is data driven, so without modifying the game a lot of pickups (and types) can be added to the mix easily.

Chests

2017_01_25_gif_1

Chests, the most valuable targets, are working. Again large part of the system is data driven (sprites, cost to open, probabilities etc…) and I have some “okay” default chest settings added to the game already.

Items and inventory

2017_02_02_gif_2

The inventory system and the basic item logic is in place. Items don’t have their bonuses and skills implemented yet, but I’m already working on it 🙂 . The plan is to have an event system “fueling” the skills, so the bonuses can be configured in tiny “scripts” (e.g.: [+X] [“Attack”] when [attacking “undead”] or [+Z permanent] [“Health points”] when [reaching “stairs”]). It has to carry the weight of 100+ unique items, so I hope this approach will be adequate.

2017_02_04_screenshot_1

As the next step, I have to complete the monster and battle logic. I put down the skeleton code for this too but it is going to take a few days to finish. Once that is done, the game will be pretty much playable, but lacking content and original assets. So the next post will focus on the monsters, finalization of the RPG layer and the item system. Maybe it will have plans for an open alpha release too 🙂 ?!

Stay tuned!