Once again I have slipped a little on offering a development update. As is obvious to anyone reading this, there has been a pandemic, and the ongoing covid situation has taken up a lot of time and concern, so things have been considerably slower than I had hoped for. All the same I have made some progress, and I hope the groundwork I’ve done here will help me iterate quicker in future.
Updates as follows:
AI work:
Refactored base behaviour
Redesigned senses: AI now does proper vision tracing and can hear things to respond to them
Added stimuli-response logic
Added behavioural relationship logic between AIs (can distinguish between friend and foe)
Added threat logic
Fixed numerous bugs with AI routine processing
Made movement logic more efficient
Recreated basic attack routines to be more believable and more “fluid”
Added interaction logic
Tooling:
Updated prtoject to latest UE4 engine version
Retargeted solution to use VS2019
Edited project to be compatible with ReSharper C++
Housekept project to remove old and unused data, revamped structure
Miscellaneous:
Integrated external tools for asset production for landscapes (more on this in future)
Added some basic weather effects and laid the foundation for a weather managing system (snow seen above, rain below)
Modified the data structure of items to make statistics, values, and events more identifiable to outside objects
Significant progress on the inventory and item tooltip interfaces (WIP and much work left to do)
Photographed, manipulated and created 7 new photogrammetry assets.
Incorporated a few third party asset libraries to fill gaps
Added one new cursor
Loads of miscellaneous bugs
Lots of little stuff that should hopefully amount to some huge progress soon enough.
My next priorities are finally making the inventory and item UI fully usable and accurate, and the same with the AI system. Once these are in place I will begin working on some more basic gameflow, and then a multiplayer test should be approaching ready 🙂
Work continues. I have spent a lot of time crunching bugs and making foundations for important future work.
I’ve gotten a substantial amount done on the calendar system. Date and time is now recorded and proceeds cyclically, and the day/night cycle is fully in place and reflected across game systems. Here’s a basic look at the cycle, sped up significantly:
The tweet was from October, but now the system is much more developed.
I’ve also been working on the inventory: now, finally, droppable, equippable items are fully implemented and networkable. The UI is still incomplete and in need of work, but the functionality is there:
Picking up some junk in a test area
I’ve also started working on the AI systems. This is important – before now, the AI was the very basic “run at and hit” sort. Now, they record relationships with characters, can patrol, have different states, and will respond more “humanly” in combat. There’s some work yet to do, which I hope to outline in a specific upcoming post.
Finally, I’ve improved some of my development tools, making it much easier to place actors and dialogue trees.
I have been quite busy with life in general and unfortunately a lot of the work I have been doing on Olusia is really tricky, time-consuming non-visible stuff. So while I’ve made significant progress, there’s not an awful lot to *show*.
I’ve fixed a series of tricky bugs and made the networking logic significantly more reliable, which took up a chunk of my time. Now in future adding exciting new item enchantments will be significantly easier.
I’ve also started work on the following systems:
Calendar and age
Inventory
Character creation
As well as going out and creating a series of new photogrammetry assets and textures, and having new music assets created. Here’s a peek:
Some work left to do on texturing and general appearance. This is one of my test maps.
I hope my next update will come pretty soon! It should be on either inventories and management or the calendar system – but it depends which one I advance quicker on.
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.
The idea is to occlude foliage such as trees or leaves when the player passes behind them. This means the player never loses sight of their character and gameplay is not disrupted.
I will outline roughly how I achieved this effect. I am making the game with UE4 and as such will use specific terms, but the concept should translate to Unity or wherever else. The idea is fairly simple: to have a material function that creates a cylindrical mask at a starting point of the camera position, and extending forwards to N point.
Here is an image of the material function:
Bits of this may not be applicable to your specific scenario, so I will roughly explain which parts do what.
In the top left we have two inputs, one is the world position of the material we are applying this to, and another is the current camera position. Each of these are transformed into two dimensions and inserted into a Sphere mask, which is then inverted to ensure we have a “cutout” rather than the opposite. This alone would achieve a cutout effect and you could insert that into the output and be done with it.
In my game, I only wanted this cutout to extend so far. I only wanted it to take effect on things that were between my player and the camera, and not extend forever forwards. As a result, I have added a few extra nodes. You can see I get the distance between the two inputs by subtracting and using abs, getting the length of the vector, and inserting this into an if statement. I then have a global parameter collection that contains the distance between the player and the camera.
Again, this may not be necessary depending on usecase. However, the player in my game is able to zoom the camera in and out, and I want to make sure that doesn’t break this effect. So, the if statement on the right simply checks to see if the distance between our two points exceeds our preset value, and then either applies the mask or returns a fully white mask to ensure no opacity is applied if the object in question is “behind” the character.
The bottom nodes are me adding a noise effect to make the circle a little more interesting and “melted” looking, as you can see in the second gif. This isn’t required and again, you can apply at leisure or pile on other effects and multiply your eventual mask by them to see differing results.
The last thing that needs to be done is to simply open your desired material and apply this material function for the “opacity mask” node. You will need to set the shader type to “masked” if you haven’t already for this to take effect.
Let me know if this has been helpful or if you require any help, and please show off anything interesting you make using this effect!
Disclaimer: I am not a shader expert, so if there are more efficient ways of achieving this effect, please alert me as soon as possible 🙂
A lot of the models in Olusia are made via the art of Photogrammetry. In short – deriving models from a range of photographs.
Photogrammetry is a useful tool for getting really authentic-looking assets and is surprisingly easy to tackle. It’s good for developers who cannot produce quality assets on their own.
Photogrammetry-produced assets are available on various stores for use by devs. I suppose the best example is probably Quixel with their Megascans library. These look amazing. They’re expensive, but well produced and look really great when in-game.
I decided to give the process my own approach, however, and make my own assets.
1. Photography
The first and most obvious step is in the capturing of the object. One of my hobbies is photography and so I fortunately possessed the required tools to capture this information – a good camera and set of lenses. While you could technically produce some assets on basic bridge cameras or with phones, I’d not recommend it. Try and stick to a solid SLR or mirrorless camera with as large a sensor as possible, and use something between 35-50mm lens range to get rid of any potential lens distortion (it’s important later on for the software to be able to link photos together with a minimal amount of disruption, and lens barrel distortion or chromatic abberation will make this all the more difficult).
Stick the camera on full manual, stop down the aperture to make the depth of field as wide as possible, and use as low an ISO as you can to reduce noise. Then, just get to town taking pictures of the object. Go around it in a 360 degree circle snapping it from every angle. Adjust height every now and then to make sure every surface is captured. There’s no real prescriptive process here, just try and capture as much as you can.
An example of a tree stump I’ve capturedIn these examples you can see the background is actually quite blurry. That’s not ideal, but fortunately it didn’t damage the capture.
Once you’ve taken as many photos as possible, there are a few post processing steps to take.
2. Post-processing
Once they’re all taken, open them in your suite of choice (lightroom, photoshop, whatever).
You’re aiming to try and make sure the images are as clean as possible. Sharpen them, and where possible remove as much shadowing, dirt, or flares as possible. Discard any that are blurry or out of focus.
If your scene had a lot of strong directional light, this will be difficult. Shadows can be removed through some creative image manipulation, but this will increase your workload a lot. Ideally, shoot your object in a scene with lots of diffuse light so there are no obvious shadows. Otherwise, these can work their way into the final texture and make it difficult to use in-game.
3. Photogrammetry
The actual interesting bit. I use AgiSoft Photoscan. They appear to have since renamed it “metashape”. This is what I use to make the actual model + textures, but there are various other solutions that do similar things. I found this one the most accessible.
There’s a lengthy process that I won’t detail fully, but eventually you will wind up with your model:
Pretty neat!
4. Cleanup
We now have our model. It looks pretty great! But what about in this view?:
That is not a solid render. Take a look…
It’s a wireframe
Obviously this is far, far too high detail to be used in a game. So there are a few steps to take:
Decimate the mesh. Reduce the vert count drastically.
Retopologise in your program of choice
Remove any parts of the model you don’t want to keep. In this example, that’d be the surrounding square of land near the stump.
We should end up with something significantly more efficient. And if we’ve done correctly, it shouldn’t really be noticeably different to the original:
One of these has 10,000 faces. And the other… 943,000. Can you tell them apart?
5. Texture and Finalising
Finally the object must be textured. Agisoft has extracted albedo data for us, so we have a texture we can use. But we need to make it PBR-friendly. For that, I use Substance B2M.
At this stage you can take extra efforts to tweak the appearance to your liking: removing marks or dirtying up the texture, creating tesselation maps, etc.
Once we’re done, we can go ahead and import it, and it’s in game with little difficulty:
With enough effort a fairly convincing collection of assets gets built up.
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:
A well timed cast……and a poorly timed one
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.
4. Channelled
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
5. Toggle
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
Resources
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:
Statistics
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.
A basic example of a roughly equal Strength vs Endurance block….…compared with a low Strength vs high Endurance block
Attributes
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.
Experience
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.
Race
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.
Classes
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.
Traits
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…
Sword Phobia
An awful affair involving swords haunted you from an early age – as such, you are unable to use swords as weaponry.
+ 2 pts
Iron Hide
Your skin is unusually tough and leathery, able to withstand blows that would bring a lesser being down to size. You gain 3 Endurance.
-8 pts
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.
Sex
The player can select a sex. It changes appearance, but otherwise has no effect on gameplay aside from the occasional change in dialogue.
Non-Permanent Perma-Death
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.
Movement
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.
Using Items
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 animations aren’t quite finished…
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.
