RPG Progress
11-01-2017 Filed in: RPG
Wow, its been a very long time since the last update!
But that does not mean that I’ve been sitting around quietly doing nothing. I’ve made quite some progress in three parts:
I’ll go over each topic in sequence.
But that does not mean that I’ve been sitting around quietly doing nothing. I’ve made quite some progress in three parts:
- visual style for the game;
- hooking the Ink conversation system into the core systems;
- combat system.
I’ll go over each topic in sequence.
Wow, its been a very long time since the last update!
But that does not mean that I’ve been sitting around quietly doing nothing. I’ve made quite some progress in three parts:
I’ll go over each topic in sequence.
Early on I decided to settle for a simple low poly aesthetic that looks “classic” and brings back memories of the JRPGs of yore, but also has looks modern due to increased resolutions and lighting effects. Here are some examples of a simple starter area I created:
Ink is amazing. It offers a simple way of authoring dialogue, but in addition also provides simple logic tests. Finally, it also has persistence. So saving the global state of the game (where you are, what you already have accomplished and so in) is very simple. I try and use Ink for as much as possible. This means that I keep the state of things like chests and whether you have achieved certain activities within Ink. Unity is actually only responsible for reacting to variable changes. You can see Ink in action here:
Behind the scenes of this particular example, the following scripts are performing all the magic:
Also, to perform quick tests I created a custom editor for the dialogue manager that allows me to quickly set variable values in Ink state:
I tried various types of combat: action-RPG style, turn based and card based. I finally settled on using a card game as the combat system. I believe this has the potential to offer more interesting strategies as I want to allow players to be able to create their own decks from the cards they collect over the course of the game. Also, it provides for interesting modifier abilities: i.e. do you want to have an extra card in hand at the expense of less ability points (potential to play cards). Do you want to have a more players in your party so you have more actions with the tradeoff that you might not be able to cast any card if they are of the wrong elemental alignment.
A very crude example of the combat system as it currently is:
Note: this system is far from complete and doesn’t use final graphics. In particular, there is currently no party support, no level-up/experience system, no target selection, very few cards, enemies don’t have any “cast” effects, etc. But what already is there might be more important: turn sequence, win/lose condition, immediate effects as well as effects over time. And most importantly for me is the decoupling of the actual combat logic and the visuals you see on screen. Everything on screen is triggered by events. The following code snippets give an idea of this. The first is the CombatActor class (a pure c# class) that knows nothing about visuals. The second is the EnemyVisuals class (derives from MonoBehaviour) that hooks into the events exposed by CombatActor to show the action on screen.
But that does not mean that I’ve been sitting around quietly doing nothing. I’ve made quite some progress in three parts:
- visual style for the game;
- hooking the Ink conversation system into the core systems;
- combat system.
I’ll go over each topic in sequence.
1. Visual style for the game
Early on I decided to settle for a simple low poly aesthetic that looks “classic” and brings back memories of the JRPGs of yore, but also has looks modern due to increased resolutions and lighting effects. Here are some examples of a simple starter area I created:
2. Hooking the Ink conversation system into the core systems
Ink is amazing. It offers a simple way of authoring dialogue, but in addition also provides simple logic tests. Finally, it also has persistence. So saving the global state of the game (where you are, what you already have accomplished and so in) is very simple. I try and use Ink for as much as possible. This means that I keep the state of things like chests and whether you have achieved certain activities within Ink. Unity is actually only responsible for reacting to variable changes. You can see Ink in action here:
Behind the scenes of this particular example, the following scripts are performing all the magic:
Also, to perform quick tests I created a custom editor for the dialogue manager that allows me to quickly set variable values in Ink state:
3. Combat system
I tried various types of combat: action-RPG style, turn based and card based. I finally settled on using a card game as the combat system. I believe this has the potential to offer more interesting strategies as I want to allow players to be able to create their own decks from the cards they collect over the course of the game. Also, it provides for interesting modifier abilities: i.e. do you want to have an extra card in hand at the expense of less ability points (potential to play cards). Do you want to have a more players in your party so you have more actions with the tradeoff that you might not be able to cast any card if they are of the wrong elemental alignment.
A very crude example of the combat system as it currently is:
Note: this system is far from complete and doesn’t use final graphics. In particular, there is currently no party support, no level-up/experience system, no target selection, very few cards, enemies don’t have any “cast” effects, etc. But what already is there might be more important: turn sequence, win/lose condition, immediate effects as well as effects over time. And most importantly for me is the decoupling of the actual combat logic and the visuals you see on screen. Everything on screen is triggered by events. The following code snippets give an idea of this. The first is the CombatActor class (a pure c# class) that knows nothing about visuals. The second is the EnemyVisuals class (derives from MonoBehaviour) that hooks into the events exposed by CombatActor to show the action on screen.