Hey there folks! Our Creative Director & CEO is back with another article, this time going over how he handled adapting Tabletop ruleset into video games.
Hi everyone,
I've been wanting to describe the philosophy we have in adapting Tabletop ruleset to a video game for some time now. As I already mentioned in previous posts, I have played a lot of Tabletop RPGs in the past 30 years - and thus went through many rulesets over the years. That doesn't mean I claim to be an absolute expert though, for there are many ways to play on tabletop. For instance, some DMs prefer to favor roleplaying, immersion and imagination by keeping the rules behind their DM Screen, and forgoing miniatures & battle grids for the Theater of the Mind.
As for my friends and I, we've always been playing with a player handbook for each player, a detailed character sheet and a grid with miniatures. We love the detail and accuracy that goes into tactical combat situations (though we also try to avoid power gaming and excessive min-maxing), which is a philosophy that will be reflected in Solasta.
Like many of you, I've also been playing countless video games adaptations - starting with Pool of Radiance and the Gold Box series, then onto Eye of the Beholder, Baldur’s Gate, Infinity Engine sequels, Neverwinter Nights from Bioware... I've also tried out less successful attempts, and after spending some time analyzing the good and the bad I came to realize that the most successful ones usually were those which stayed the most faithful to the ruleset. This is why when I first started describing the project, I said we were adapting the video game to the Tabletop ruleset, rather than adapting the ruleset to the video game. It may sound like a marketing tagline, but that's what I genuinely believe.
The first thing I did was creating a way to input rules into the prototype. I am not sure if this has been revealed yet, but we are using Unity as a foundation for our game. The main reason for using this engine, other than a solid 8 years of previous experience (Endless Space...), is that it's good at making tools and editors. One of the very cool things Unity offers is ScriptableObjects, which allows you to define code templates (such as Character Class, Character Feature, Spell, Weapon Type...) and easily develop editing tools for this data - so we built a system to edit the database with all the Ruleset bricks needed to make an RPG.
One big question remains: how far can you go in making the ruleset editable, and when do you need to hardcode stuff? It is a fairly common software architecture question: should you make a super generic code or go straight to the point? Since we wanted to quickly develop a minimal viable product (MVP), the solution was a bit in-between: all the individual Rule Assets (such as Races, Classes, Items, Features, Spells, Powers, Monsters, Conditions...) can be edited, while the core is implemented in the engine. To illustrate that with tabletop - this is the same idea as having a core ruleset, then adding new content on top of it with additional books.
Going back to the technical side, if we take Spells as an example. By taking a generic approach and implementing a wide set of parameters, the bet is that we would be able to create most spells available. Every time a spell has some new exotic effects, we need to add new parameters - which could then be reused for other spells. On the other hand, a procedural approach would mean that each spell is individually hardcoded into the game - certainly a quicker solution, but one that would heavily limit reusability.
Fireball, when diplomacy is no longer an option (well, it does count as Intimidation, right? Can I roll with advantage?)
The most challenging and thrilling part is using rules that are often neglected in video games adaptations, such as lighting and verticality (climbing and flying). Some games tried to implement these rules in a limited manner, but we've come to realize that this is a large investment you need to plan from the start. The reward however, is that you end up with crazy and funny situations - especially when implementing Tabletop ruleset accurately (who wants to see a mage lose concentration when hovering over a deadly pit?)
That being said, there are still some elements that we need to adapt to work properly in a video game - especially when playing from a top down perspective. For example, a character could easily spot an enemy 500 feet away... But that would correspond to 10 game screens in distance. It notably becomes very hard to provide a meaningful and intuitive stealth experience with this in mind, so we have to reduce the distance to make the game manageable. There's also some simplification in displaying distance, using cells (5 'x 5 'x 5' block) instead of feet to avoid confusion and conversion problems for countries using the metric system. That said, while we are working on securing the core experience now, it is totally possible to include a setting to display distances in feet for the fans who prefer it.
Hope this post was interesting to you, stay tuned for more in the coming weeks and do not hesitate to ask questions or add feedback below!
Cheers,
Tactical Archimat