Skill Trees ~ Research on skill tree support in modern day game engines

Goal: We would like to eventually add support for skill trees to chiventure. We should start by first looking into how other game engines implement skill trees. This research should produce a list of ideas that will describe the structural design of the module, and that will be considered in the future when writing the design doc.

Results: My research lead to mixed results.

One engine I looked at was the Unreal Engine, a commonly-used modern day engine, which has open-source code on github. After diving into the source code, it becomes clear that the size and scope of UE is way beyond the magnitude of chiventure, and any attempt to understand its inner workings through the source code alone would be an impractical endeavor.

On my second go, I looked through the documentation for UE, which is, perhaps, almost as long as the code itself. This attempt also did not yield much. Much of the documentation is aimed at game developers, who are much more interested in interfacing with the engine, than in interacting with the low-level implementations that I'm after.

After digging deeper, I found that there was actually a marketplace of plugins, designed by community members, that are meant to give a much more concrete interface for game developers to implement skill trees in their games. Most of these plugins are behind paywalls, which make getting at their source code more difficult. But moreso, this suggests that UE itself does not have any inherent support for skill trees. When a prospective game developer wants to add a skill tree to their game, they either have to buy one of these plugins, or make use of much lower level assets provided by UE.

I also looked at the Godot Engine, a smaller, but also open-sourced, engine that is more geared towards enthusiasts. After looking through the documentation, I came to similar results.

This leads to two choices that we can make in regards to skill tree implementation for chiventure. The first choice is to provide the user with a much lower-level and more general system of player asset-posession (kind of like buying and selling objects, but with a special currency or skill points) that can be repurposed into a skill tree-like system. The pros of this approach would be that this low level system can be used to implement many other features, and would provide much future expandability. For example, this could directly lead to an inventory system, or it could lead to player stats where a player's strength stat is just how many "strength-point items" they are in posession of. The cons of this approach is that it is much more difficult for the user to interface with, as well as the fact that it requires a pretty sizable refactoring, and redesigning, of existing code and features.

The second, and more likelier, choice would be a more direct implementation of skill tree support, which is closer in scope to the goal for this quarter. The pros of this approach would be that it gives the user a much simpler and precise interface to create and interact with skill trees, and this interface would be distinct from many other features. The cons would be that it has less future expandability than the previous, more general, system would provide.

As we are choosing the second path, there are not many features from the Unreal or Godot Engines that we can take as design inspiration, so we are more or less in the dark as we start making design choices in our implementation of skill trees.