All Hail Temos News

How to balance an RPG? There is no perfect answer, and instead I think it can be described as “What you do is what you get.”

You are building a system, and from the functioning of that system, you will get the results that system produced. It seems redundant to type it out, but it is very much a cause and effect of how the system is designed, rewards and penalties will be assigned, and players will want to maximize rewards and minimalize penalties.

If other aspects of the game are also very good, maybe they will tolerate less than perfect maximum rewards and perfect minimum penalties, to see a more interesting story, or make more personal choices, but the balance of statistics and skills should support all these things as a foundation, because the incentive structure will in large part dictate how many players play, because of how they are rewarded, thus defining what type of game this is. What you do, is what you get.

So with that rambling preamble done, I will turn towards my methods of mixing perfect balancing versus asymmetric balancing to create a system that has a solidly balanced foundation, with a number of asymmetries that map to the theme and gameplay of the game.

Getting coverage on things you can do, and how well you can do them

[h2]Stats, skill Groups and Jobs[/h2]

Stats and are skills are core to RPGs, you perform skills, such as casting Magic Missile, and your stats help determine the success and strength of the skill usage.

In All Hail Temos, I divide up skills into skill groups:

• Combat (CBT)
  
• Influence (INF)
  
• Craft (CFT)
  
• Experiment (EXP)
  
• Seduce (SDC)
  

These skill groups are then balanced with stats, but I have an intermediary step to create both a perfect balance foundation, and an asymmetrical balance, for how stats are distributed inside.

[h2]Stats[/h2]

To explain this, I need to introduce the stats for the game, which have 5 base stats, and 10 derived stats, which are all the combinations of the 5 base stats, in unique pairings with each other. The base stats should seem familiar, but are tuned a bit to get better thematic coverage:

• Strength (STR)
  
• Agility (AGL)
  
• Wit (WIT)
  
• Awareness (AWR)
  
• Charm (CHM)
  

These 5 base stats are then combined to all their permutations with 10 derived stats:

• Precision (PRC) = STR+AWR
  
• Beauty (BTY) = STR+CHM
  
• Grace (GRC) = STR+WIT
  
• Endurance (END) = STR+AGL
  
• Accuracy (ACR) = AGL+AWR
  
• Social (SOC) = AGL+CHM
  
• Flexibility (FLX) = AGL+WIT
  
• Deduction (DED) = WIT+AWR
  
• Convincing (CNV) = WIT+CHM
  
• Personality (PER) = CHM+AWR
  

Together these are 15 combined stats. And there is a perfect balance between the number of derived stats, and the base stats. Thematically, I also tried to get a very wide coverage of potential elements of a character’s abilities, which we are reducing to stats, to inform how I should create the game to allow all these stats to be expressed. After all there is no point having a stat that is a dump stat, because it is never used in the game. Better to cut it, or expand the game in at least some way so that the stat is incorporated in a way that thematically and gameplay wise makes sense.

[h2]Skill Groups[/h2]

Next I assign 3 of these stats to the skill groups, without ever repeating or leaving any out, so there is perfect balance of the 15 stats into the 5 skill groups, with 3 each.

• Combat: Strength, Awareness, Agility
  
• Influence: Social, Personality, Convincing
  
• Craft: Accuracy, Wit, Endurance
  
• Experiment: Deduction, Flexibility, Precision
  
• Seduce: Beauty, Grace, Charm
  

To convert this assignment, I give each stat 2 points, so each skill group gets 6 points. The player selects a job that contains 2 skill groups, so the player is selecting a total of 12 points of stats when they pick their job, which is distributed in this perfectly balanced above way.

But, here is where I add in asymmetry to the design to give things a more thematic shape, based on how all these terms connect together and can be interacted with in the world.

• Combat: Strength + 2, Awareness + 2, Agility + 2
  
• Influence: Charm + 3, Agility + 1, Awareness + 1, Wit + 1
  
• Craft: Agility + 2, Wit + 2, Awareness + 1, Strength + 1
  
• Experiment: Awareness + 2, Wit + 2, Agility + 1, Strength + 1
  
• Seduce: Charm +4, Strength +2, Wit +1
  

This creates a situation where there is an asymmetric balance, so not all the numbers relate evenly with each other evenly, on top of a lot of symmetrical balance, where all possible options are present, and no duplicates exist. Which I’m calling perfect balance, for the purpose of this article, to underline both of those qualities are true: all unique combinations exist, no duplicates.



[h2]Jobs[/h2]
As I mentioned above, the player selects a job, which is what selects all of these stats and skill group assignment. Every job has 2 skill groups, which I can asymmetrically balance as a major and a minor skill group for that job. The jobs are:

• Explorer = Combat, Influence
  
• Saboteur = Combat, Craft
  
• Tactician = Combat, Experiment
  
• Assassin = Combat, Seduce
  
• Merchant = Influence, Craft
  
• Detective = Influence, Experiment
  
• Spy = Influence, Seduce
  
• Engineer / Inventor = Craft, Experiment
  
• Artisan = Craft, Seduce
  
• Bureaucrat = Experiment, Seduce
  

The assignments of all skill groups are such that in all the jobs, there are all combinations present, and no duplicates. So perfectly balanced. But, the distribution of which job is major (first listed), and which is minor (second listed), is asymmetrical and was tuned to be in the theme of the world and gameplay, and not for perfect balancing, unlike the 10 derived stats which are perfectly balanced from the 5 base stats.

The player will select one of the above jobs, which give them a major and minor skill group, which give them 12 points of stats total, divided among the stats that comprise the skill group, with 3 stats per skill group, at 2 points each.

After selecting their job, the player is given 12 points to assign how they want, so they get 50% nature (all given by a single choice) and 50% nurture (selected individually). This creates another perfect balance, 50-50.

[h2]How will this affect gameplay?[/h2]
Until I get a lot of player feedback, I won't know how things will initially be received, but there is actually a lot more missing from this balancing article, which is the skills themselves. When you swing a sword, cast a spell, try to pick a pocket, etc, how is all of this information balanced there?

It’s balanced individually, for that skill. So this is where the real balancing of the game occurs. All the balancing I did above is to provide the framework to balance individual skills you will use in the game. How far you can dash, or shoot an arrow, will be determined by the way that specific skill uses the underlying system of stats, skill groups and jobs.

By the way, you can change jobs. Any time you want, but it doesn’t take effect until the next time you go up a level in a related skill group to that specified new job. Your selected job gives you a type of cap on a type of progression you can do with skills from other job’s skill groups, and when you change jobs, you lose access to high level skills in all your non-selected jobs, but keep access to low and mid level skills. So, you can level and play across the range of jobs and skills, but not all at the same time, but you can keep adding more low and mid level skills to your usable skill set. I will write a post about this in the future.

[h2]Conclusion[/h2]

So, that is how I created the stats, skill groups and jobs used in All Hail Temos, so that you can get a mix of perfectly and asymmetrical balanced relationships that describe how your character exists in the world, and what gameplay is possible.

If you would like to see how all these stats and jobs can be viable gameplay, wish list All Hail Temos on Steam.

Kicking off the Devlog series for All Hail Temos, this is how I implement saving the game, but instead of normal save game files, I want full timeline Rewinding, so the player can travel back to any point in the past, at a certain granularity, and then play forward from there. It also means no worrying about saving, because everything is always being saved, and you can always go back and try something again.

For UX reasons, I will still have a bookmark of save games, so you dont have to scrub through the timeline if you know you want to remember an area for rewinding to.

This does make Save Scumming a first-class feature of All Hail Temos, so I make it easy to go back and try different options, and I introduce you to the reality of time travel into a story with many branching paths. But that is a design discussion, and this is a technical devlog.



[h2]Introduction[/h2]

Every change in the game is stored in a sequential record, and then when you rewind, you can rewind over your entire play session, including when you reloaded previous game saves before, those are all just in the time line linearly. So you will have a you-tube like scrubber bar and you just go back in time to where you want to Rewind to. Then your Journal gets a summarized version of this, which is your actual Historic Record, and is what will be in your journal book, even though all the information exists in the timeline, the book only contains the Historic Record. Later I will add a toggle so you can actually get the entire timeline in the book.

Side Note: Your gameplay Journal can be exported as an EPUB in a later release.

[h2]Journal Historic Record - what you have done
[/h2]
The Journal Historic Record, looks like this:

0
1
2
3
456

You start the game: 0 and advance to 1 -> 2 -> 3 -> but then you played 455 more snapshots worth of gameplay, and did a rewind all the way back to #3, which created the new 456 to start making changes from. All the 0-456 exist in the timeline, but your journal only sees 5 items.

[h2]Snapshots of the Game - Instant-Frames[/h2]

Every snapshot of time above contains a lot of changes inside of it. I call the full snapshots of the game, which is normally called a save file, an Instant-Frame (or I-Frame) and the individual changes in the snapshot I call Progress-Frames (or P-Frame), which roughly also map to terms used in MPEG encoding. That looks like this:

---
i: 456
start:
	985473299343: 9875
	123173621736: 1001
progress:
	# location: progress IDs, ...
	985473299343: 9876, 9877, 9878
	123173621736: 9879, 9808
---

This shows the snapshot 456, has 5 changes in it, across 2 different locations. Location 985... and 123... have several changes made to them. So these are the I-Frame and P-Frame numbers together. Which are made sequential by the Journal Historic Record, by just putting the snapshot I-Frame number in a sequence.

[h2]Changes to the Game - Progress-Frames[/h2]

Finally, this is the change data (Progress-Frame), which contains all the information needed to rebuild exactly what was happening when the game was being played, and also constantly updates where the player is, what they are doing, their physics information, and the same for any other NPCs in the location.

file: i_p_001_456
---
p: 9876
seed: 756894
seed_advance: 126
day: 76543.4
day_last: 76543.4
state:
	- Tenin.returned_horse_cart
counter:
	Tenin.angry: 6
start:
	1: ACTIVE, 337,0.523, 123,321,213, 0,90,270, 0,0,0, 0,0,0
actor:
	1: 10000, 123,321,213, 0,90,250, 0,0,0, 0,0,0
	98754321: 0,123.4
object:
	# Destroyed object
	628374: -1,1
	# Removed object, by the player
	628374: 0,1
---

This repeats the I/P frame information, so you can always easily tell where you are, and search for them in the text files. I also put this information into the filenames that are stored, so modders can easily look at the files. There will also be instructions on all file formats, in case people want to mess with things, to enable low level modding types. It also gives the time in-game days since the player started, so we know the current time, and it gives the last time this file was updated, as it stores both a fixed change, and updates about what people are doing.

I also keep the Seed and times advanced since re-seeding for the Random Number Generation. This allows me to reset the seed, call it the number of times advanced, and the next random number will always be the same.

[h2]Storing State at Every Location, for Every Situation[/h2]

In AHT, every time you go anywhere, the location you are seeing was set up specifically to be that way, at that time, in your circumstances. If you had answered a question differently, or done a quest, the stage may have different actors there, different furniture or props, anything could be changed, as it was completely set up by your narrative stage, when you triggered spawning that area. So I already know the starting state of any location in precise detail, so the only thing to track are things that have changed.

In the state section, I say that the Narrative has changed, and you advanced a quest-line of returning a horse cart. In the counter section, I update a counter that also changed, so this guy has gotten angry more 6 times. Since its angry, it is a counter going up. But if it was irritated it might go up or down, depending on how they are reacting to what you are doing in the world. You could make someone angry who isn’t there, because you did/said something, and after 1 day and you enter a location, they confront you over it.

In the actors sections, I give the UUID of the actors (1 = the player), and what they are doing currently, and information about that.

[h2]Example of Change State[/h2]

For instance the player is free roaming around, and I give their current animation, time into that animation, position XYZ, rotation XYZ, momentum XYZ and rotational momentum XYZ. So I know where they are, what they are doing, and how to carry the physics into a reloaded scene.

Maybe they were jumping off a roof, and had forward momentum. I don’t want them to lose that, and they just fall on the ground, but I’m also saving minimal information, so it doesn’t take a lot of file IO or space, and is easier to parse as a human. Its also written in a pseudo-barebones-YAML format I made. The other actor (Tenin = 987...) is at station 0 (Guarding), at 123.4 seconds into that action.

[h2]Objects of Loot and Destruction[/h2]

Finally objects tells me if an object has been destroyed, or taken, and by who (actor UUID, 1 = player). So the player took that item out of the area.

The other object was destroyed, by the player. Other actors could destroy or take things too, and this leaves exact information for any quests related to theft. You could trick someone else into stealing something for you, and in my narrative logic, I can test whether it was the player or someone else who took it.

But, if they player has the item and they didn’t take it, I can then narratively say that they tricked or convinced the other people to do it for them. If the other person is their friend, then they have built alliances I can acknowledge in some narrative way, and if the other person was attacked by them afterwards and the player took it, which I also know, I can narratively say they were devious.

[h2]Conclusion[/h2]

I hope you have enjoyed this explanation of how to save and rewind time in All Hail Temos. If you are are interested in game, the Prologue demo is planned for release in the beginning of September. Wishlist it to remember.

I did this interview a few weeks ago, and talk a bit about the development and goals of All Hail Temos:

https://podcasts.apple.com/us/podcast/sww-interviews-episode-90-all-hail-temos/id1435072446?i=1000565975916

Just to update the current basic roadmap:

- A Prologue Demo in late August or early September
- Steam NextFest in October
- Launch in EA in late October or November
- About 3 month in EA before launching 1.0
- More content releases regularly, with more story and more places to explore