As with all good RPGs, Olusia has a robust dialogue system. This will be a short post outlining some of the approaches I took.
I’ve modeled my dialogue system somewhat on the brilliant examples found in classic games such as Baldurs Gate or , and sprinkled on a few of the innovations seen in more modern games such as Tyranny and Pillars of Eternity.
Here’s an example picture:
As expected, the player will be able to respond to the NPC to have a conversation, with a range of presented options. These options will expand dynamically based on character traits or statistics – if they’re high in charisma, they might try complimenting or bribing an NPC; if they’re insane, they may unlock some less savoury options…
One of my favourite modern interventions in this space I first saw in the game Tyranny. This was the “mouse over” functionality that enabled the player to hover over words to pull up a glossary-style definition. I’d never seen it used before, but now it seems so obvious and intuitive that it’s baffling it was never attempted. It lets the dialogue writer cut down on needless exposition and effortlessly provides additional context without breaking conversational flow.
I already mentioned item usage – press and hold a mouse button to use an item, be it a sword or a shield. So that’s how weapons are used. But the other most important part of playing is ability usage. I’ll outline the different types.
Every character has a pool of Ability Points, which are used to cast abilities. Ability Points (AP) are derived from the characters stat pool, and the statistics that contribute are dependent on class.
Each class likewise has its own bespoke resource or trait. This makes playing each class something unique and can change the way abilities are cast. I will be doing future blog posts specific to classes so I won’t go into great detail here, but later will use the Knight, perhaps the most simple class, to demonstrate.
With these resources in mind, there are 5 universal “types” of ability, and some examples of them:
1. Instant Cast
This is the most immediately obvious sort of ability. You press a button, and the action happens. Some AP and resource is spent, and then the ability goes onto cooldown.
An example is the Knight’s Hew ability:
The Knight Hews the target. One target in melee range is hit for max weapon damage and a debuff is applied for 3 seconds, which reduces the targets Speed by one and deals 5 points of bleed damage per second.
2 Action Points
2. Standard Cast
This is the most common type of ability in the game. It has a cast time, a cost, and a cooldown. When the bound button is pressed and held down, the timer begins, and when it complete, the ability is cast. If the button is released prior to the timer ending, then the ability is cancelled. Sometimes cancelling prematurely can have consequences, but most of the time it just results in the ability not costing AP and not going on cooldown.
3. Timed Cast
This sort of ability is a little more novel. The player is given the opportunity to “fine tune” a cast to get better results from the ability based on their reaction time. As with a standard cast (2), Timed Cast abilities are initiated with a press and hold of the ability key – however, they are cast upon release of the key rather than after a set period, and the potency of the ability is greater depending on how close to the “sweet spot” a player releases the key.
Here is a basic example with the Wizard’s Translocate ability:
Drawing on latent energies, you carefully transport yourself through the unknown winds of magic to a new location.
Translocate will become more precise the more well timed it is. If timed poorly, the caster will take damage as the strange and wicked magical energies contort their bodies en route to their new location.
2 Action Points
Here are some gif examples.
Once again, the art is very unfinished – please ignore the UI and the character animation for demonstration purposes:
As can be seen, the accuracy of the spell increases the closer the player is to releasing at the correct moment. Failure to properly cast the spell may result in unintended consequences!
There are various timed-cast abilities in the game with different boundaries of success and consequences of failure, which will be revealed in time.
Channeled abilites are cast repeatedly for as long as the player holds down the associated key. They will drain AP at a set rate and eventually cancel when the player either releases the key, or runs out of AP.
An example is the Knight’s Parry:
The Knight parries incoming assault, avoiding damage. Whilst Parry is being channeled, the Knight will be immune to any oncoming damage, which will be intercepted and cancelled.
3 Action points per second of channel
Some abilities work on a toggle. They are used, and cause something to happen until otherwise turned off. Some of these will be a constant AP drain, and others simply cost AP to turn on or off.
An example is the Knight’s Defensive Stance:
The Knight may switch stances in and out of a more defensive position – when this stance is enabled, the Knight’s Speed attribute is halved, but his Avoidance is doubled.
1 Action Point
At the start I mentioned each class has a unique resource. This gives the player something to track other than Action Points, and adds a little flavour and nuance to the various abilities in the game.
These resources are not necessarily alike. Some are generated and spent like AP, others are passive, others react to certain scenarios.
The example I will use for now is the Knight, who has the Combo Points resource.
Whenever a knight makes a melee attack, a Combo Point is added. Combo Points stack up to 4 times. If an ability is used when the Knight is at maximum Combo Points, then the cooldown of that ability will be halved, and the Combo Points reset.
If a Knight has 4 Combo Points, and does not use an ability, then the proceeding attack will reset the count to 1.
Master Knights, that is, those who have not multiclassed, will gain the “Combat Mastery” trait, which instead reduces the number of required points to 2.
When multiclassing, there are obviously a range of abilities and resources to manage beyond just combo points.
In an RPG, the most important single aspect is the player character. I mentioned input and responsiveness in my last post, which is important in grasping the player and making sure the game is actually enjoyable to play – but any real, long-term investment means two things must be nailed down: the character, and the narrative.
To fulfil the “RP” in “RPG”, the player must either be allowed to create his own character or to be given one with a very fleshed out role – but in either case, it is crucial to allow them to manipulate and modify the character as they play in order to keep them interested and invested.
I have gone with the “create your own character” route. I think it’s more personal and ultimately allows finer control over what the character can do, and it should mean increased longer-term interest.
Along with all of the customary naming and appearance customisation, the following attributes make up a character in Olusia:
There are five primary statistics in Olusia which serve as the ultimate abstraction of what a character can do. They are as follows:
Strength: Strength governs how much damage a character may do in combat with melee weapons. It also effects critical hit chance – and if a characters strength is significantly higher than an opponents endurance, there is a chance of knocking a foe off their feet.
Endurance: Endurance is what determines a characters health. It also governs how much the player may carry, and how likely they are to be knocked back by powerful attacks.
Luck: Luck is not a ‘nothing’ stat as it is in some games – a higher luck increases the chance to avoid being critically hit, increases ones own chance to critically hit, and increases likelihood of finding magical items and gold, amongst other things.
Will: WIll is the measure of a characters strength of mind. A higher Will means a greater resistance to debuffs from the Sanity system, increased resistance values, and for certain classes governs their ability to cast spells reliably.
Speed: The most self-explanatory of the primary statistics – Speed dictates both how fast a character can move, and, to a lesser extent, how quickly they swing their weapons in combat.
In addition to these primary statistics are a range of attributes. These are less vital than statistics, but still effect how characters are played, and each have distinct uses and effects on dialogue and gameplay:
Lore: determines how knowledgable and how quick to learn a character is. Characters with higher Lore will earn experience faster.
Piety: the amount of faith a character has. The higher the Piety, the less quickly Favour will decay with their chosen deity, and the more likely they are to make successful divine requests.
Survival: has a minor effect on debuff mitigation and damage resistance.
Charisma: used to achieve better prices at vendors, and to unlock certain dialogue options. For certain classes, has an effect on ability usage.
Avoidance: a higher avoidance rating can result in greater protection from attacks and a reduction in chance to be critically hit.
Characters gain experience through doing things – defeating enemies, finding treasures, discovering locations, or completing quests. As they earn experience, they will gradually level up.
This is one of two progression mechanics. As they gain levels, the experience can be spent towards unlocking new abilities for their classes, increasing statistics or attributes, or adding new traits.
The player can pick one of several different races for his character. I don’t want to go into too much detail here, because some of these races will be unlockable through play and should remain secret – but each race comes with unique statistic, attribute, and trait packages that make them each different to play. As a basic example – Humans are the most “generic” race, and suffer no stat penalties or bonuses and few interesting traits, but Halflings gain a small boost in Speed and a detriment to Endurance, and have a few special traits that align with this theme.
Characters must specialise into classes. These classes determine the resources and abilities available to a character for use.
A player may select up to two classes for a character, and it is suggested that they do select two for maximum diversity and personalisation. Players may select one class alone to “specialise” into it for some bonuses – but players that select two classes will have a broader pallette of abilities. For example, a player might select Wizard alone. If he does – he will gain the Grand Wizard trait, enabling him to cast spells more frequently and with less risk. Or – instead – he might forego this extra trait to select a second class, and pick Necromancer. Now, he is a Summoner, and has a pool of abilities from each class, but does not gain the specialist trait from either.
Each class combination has a unique name! I will be making distinct posts on classes in the future.
When creating characters, players must select a balanced slate of traits to fine tune their abilities. These are of varying severity and benefit, and exist to allow players to make their character more specialised.
When choosing a race and class, certain traits will be adopted by default – these cannot be removed, and cost nothing to have. Players will then be granted a number of points to spend on new traits. Some traits have negative effects, and these therefore have negative cost, allowing the player to adopt some character flaws in order to increase their capabilities elsewhere. For example, let’s say the player has 10 points…
An awful affair involving swords haunted you from an early age – as such, you are unable to use swords as weaponry.
+ 2 pts
Your skin is unusually tough and leathery, able to withstand blows that would bring a lesser being down to size. You gain 3 Endurance.
And selects both of these traits. One is positive, one negative – and taking them both results in a remaining 4 points to spend.
A player is free to select any number of traits as they see fit – but the remaining points must always be greater than or equal to zero for the build to be valid.
The player can select a sex. It changes appearance, but otherwise has no effect on gameplay aside from the occasional change in dialogue.
Strange name for a feature.
A lot of Roguelikes have perma-death. When you die, game over – start again. It raises the stakes and makes your character feel important…
But losing your progress also sucks sometimes, especially in games with lengthy narratives. So I have a character system called Age.
Characters start at a young age and get older over time. This represents a natural difficulty curve – the older you get, the tougher the game becomes as you begin to gain experience and become more vulnerable through acquired debuffs/traits/sanity afflictions.
When you die – you will have the option of asking your god to return you to life. If so, you will return and continue playing with only minor temporary downsides just as before – but your Age will remain frozen at the point of your death.
This works as a sort of “medal of honour” in that it represents how long you managed to last without dying – and when playing in multiplayer seeing other heroes with a high Age should be genuinely impressive.
(For narrative reasons, you will ultimately be able to age indefinately. This system will tie into the Calendar system, which I will outline in a later post).
When people first play games – perhaps the first thing they notice (after the appearance) is the interactivity. If the input is imprecise or unresponsive, or the means by which they interface with the game is not quite right, it immediately sends a bad signal and they’re unlikely to continue.
Think of most of your favourite games – with a few exceptions where innovate gameplay might make up for it, they almost certainly all control exceptionally well.
This game was originally a 2D dungeon crawler and it went through various iterations. I’ve also dabbled in other small games for gamejams or out of interest, and without fail I always end up flitting between various systems to program them and move on before completing because something new and shiny catches my eye. I’d do a bit on UI, on procedural generation, maybe something on niche gameplay features… but never finish them. Which is why this time I’ve resolved to work almost exclusively on movement, input, and combat before moving on. After all, it’s basically the core of the game. As a result, the other systems are mostly in their nascency, but there’s still plenty to talk about there.
Olusia is a top-down game. I’m taking a lot of inspiration from classic CRPGs, but not in the realm of player input. Most classic CRPGs implement click-to-move. There’s nothing necessarily wrong with it, but it’s suited to certain types of game – specifically those where you’re in control of > 1 unit, or turn/round based games. There are a few reasons I didn’t opt for it:
Less personal. You click where you want to go, and the unit will path there as it wants.
Less responsive. There’s less opportunity to respond to stimuli quickly and precisely
Inappropriate – it doesn’t really make sense when taking into account the rest of the mechanics
Instead, I have opted for full directional movement and rotation. Move with WSAD keys, and the unit will face wherever you are pointing the mouse, as shown in this GIF:
It allows for more “actiony” mechanics and makes aiming bows or spells that much more interesting. It also has a tactical aspect missing from most point-and-click games – for example, you can face one way whilst walking backwards, perhaps so you can block projectiles with a shield at the same time as retreating. Walking backwards does result in decreased speed – and so does holding up a shield. For example, in the following GIF:
This guy is in very light clothing and so has a high run speed, but slows down when raising his shield.
Movement effects are cumulative. If you are in heavy armour, walking backwards, and for some reason have two shields with which you want to block, well…
You move quite slowly. But that is all the players choice.
Item usage is something that is largely decoupled from movement. That is to say: you can move and use items at the same time (with rare exceptions).
Each arm is bound to a mouse button. Left click to use the left arm, right click to use the right. Simple!
All items will largely follow these same rules, and most will also have the ability to what I’ve termed “Prime”. I’m not sure when or why I labelled it that, but I have stuck with it.
If a mouse button is held down, the item will be “primed” until released. Here is a quick example with a sword:
The sword is raised upon holding down of the button, and swung upon release. This sort of thing allows a little more control over the mechanics of various items, especially ranged weaponry or shields.
There’s also some other stuff that ‘feels good’ to help with finer control. This includes rolling and jumping. Not only do they look cool, but they also make combat higher-stakes and faster by providing the ability to dodge attacks.