Tech trees and pâtisserie
Last changed on
So, the tech tree is not finished. And it is no longer a tech tree per se, or in the traditional sense. It has become something… similar to a mille-feuilles (yum). In this post I will try and explain what happened: where the tech tree came from and where it now stands.
First, meet the unborn Tech tree
In the previous post, I tried to explain my clumsy yet passionate approach adopted before and during the design/building of the tech tree's first version. As it turns out, it did work reasonably well, with a few hurdles encountered along the way - nothing unexpected:
- During the quest for "sciency stuff" a split was decided: some sciences would be "pure" and others "applied". Nothing earth shattering: pure sciences would not open up access to blueprints, whereas applied sciences would. In more ways that one, this made applied sciences the leaves of the tree and blueprints the fruit.
- Some pure sciences became applied sciences and vice-versa
- Some trimming was heavily applied: what were sciences before became opportunities for blueprints; the opposite also happened and several blueprints became applied sciences. Or just variants of items/toys.
- The tree was wider than it was deep… perhaps a symptom of a larger, deeper problem. Noticing this felt a little bit strange, as the progression in the dimension of the future felt adequate. Ah well, probably just me.
- The split under Physical science, Material sciences, Biology and Human sciences was actually working quite well in terms of internal trunk progression, but also for cross-trunk dependency opportunities.
The tree reached a stage when it encompassed around 300 sciences, what's more split almost equally between its four trunks (good for balance). It was also about to be enriched with about 400 applied sciences, mostly as children of pure sciences.
Some technical stuff
Mentioning this as a reasonable amount of time was spent on deciding how to the data was going to be stored. In the end, sciences were stored "almost flat" in several MySQL tables:
- a main
sciencetable populated with the usual stuff: name, slug, description, quote, etc. - a joining many-to-many table defining the parents/children (or ancestors/descendants) relationships between sciences, including the data associated with such relationships: points, conditions, etc.
- all the above quite easily (and efficiently) queried using recursive CTEs
It looked deceptively simple - perhaps overly so. But my goal was to be able to run very quick queries across any and all sciences, including annotations via subqueries, to be able to keep track of what was where, for example:
- Knowing on the fly how many "points" a science needed to be unlocked (I will not get into this past version of points and unlocking because the new system is utterly different)
- Knowing on the fly how many ancestors and/or descendants a science had. In the case of ancestors, this potentially covered several branches, and allowed to get a very quick "depth" for any science.
- In other words, utilities that are much easier to perform/display when working with simple, normalised and reasonably well-indexed tables
- Not to forget the ultimate goal of dumping the science's complete definitions as a
rustfile right before compilation! (that goal still remains valid today)
Front-end-wise, all worked pretty well: in only three queries, it was possible to get: 1) a given science 2) the tree of its ancestors 3) the tree of is descendants. The visual result was similar to the following and averaged 35 ms server time, all included (queries, rendering, etc):
I was particularly happy about the CSS flexbox code used to render this - no images whatsoever, pure CSS. :-)
Production deployment and the nagging
I deployed the tree so it could be browsed; it could be viewed only under certain conditions, as I needed some feedback from people outside of the low-level detailed stuff and able to give me precious and coveted outside opinion about how it all felt:
- they needed an account and to be logged in
- their user account needed to be flagged in a certain way (nothing fancy at all, a simple boolean/tinyint was enough…)
I got the feedback I needed, so thanks for that, all :-). But the main feedback I got was the one from yours truly. And as I was working on the addition of new sciences, the shuffling around of sciences to new parents, etc. I began to not like this tree.
It felt too static.
It felt too predictable.
It felt too artificial.
Fair to say my own feedback was bad. After trying to enrich the nature of relationships between sciences (introducing new variables/dimensions) - to no avail, I decided to undo the structure of everything while keeping the basic building blocks (the sciences) themselves mostly intact.
I had been trying to catch a knife that was already on the floor. I am now glad I gave up on this initial version.
Meet the mutated tree
The "tree", in its current form, is no longer a tree at all. As mentioned above, it is now more a mille-feuilles than a set of trunks, branches and leaves. It feels much better in several ways:
- it is far more organic
- it lends itself to considerably more relationships and mechanics tweaking
- … but in many ways it is also more technically complex. Functionally though, it feels just about the same. In fact, in can feel simpler and more intuitive. But you be the judge 8-}
Aspects: a split Universe and Knowledge Points
Let us start with a famous quote by Isaac Asimov…
Science doesn't purvey absolute truth. Science is a mechanism… for testing your thoughts against the universe.
…since the whole new system is a little bit inspired by these words: under it, Ad Lumens's game universe is split into aspects, which represent facets or truths of reality. From here on in the post (and probably subsequent ones), we will use a simplified list of aspects that could be used in a (also simplified) Fantasy setting. The imaginary list (and not the one used in Ad Lumens) is the following:
| Aspect name | Description |
|---|---|
| Earth | Mastery over the element of Earth |
| Air | Mastery over the element of Air |
| Fire | Mastery over the element of Fire |
| Water | Mastery over the element of Water |
Fairly simple. In this alternative fantasy universe, every faction, guild, clan (or whatever name a player's set of units is called) keeps track of how advanced their knowlegde is for each every one of the universe's facets. This is symbolised by the accumulation of Knowledge Points, stored in the form of a standard many-to-many relationship between factions and aspects.
It should be noted that the universe split into aspects is purely: 1) subjective 2) extremely opinionated 3) hence debatable 4) easy to change/update. In our simplistic example, the world knowledge probably revolves around elemental magic, primeval building blocks or the like.
If we imagine factions A, B and C:
| Faction | Knowledge points | |||
|---|---|---|---|---|
| Earth | Air | Fire | Water | |
| A | 120 | 80 | 10 | 110 |
| B | 50 | 70 | 30 | 210 |
| C | 230 | 42 | 42 | 42 |
Each faction has accumulated knowledge points at different paces, in different aspects. Obviously, faction A's mastery over Earth is greater than that of faction B, and both are less advanced than faction C in this aspect.
Aspects are hidden…
I chose to make aspects hidden from the "public", at least for the time being and in clear, points-based form. The reason is simple: they are supposed to represent hidden truths about the Universe, mastered to a great or lesser extent by player entities (or factions). Ad Lumens currently makes use of 80 aspects, spread over the following families:
- Abstract/Physical: does the aspect cover purely physical principles and rules or is it about intangible things?
- Natural/Artificial: does the aspect cover principles that are anchored in the Universe whether humans are there or not, or is it more about humans themselves and their inventions/dynamics?
These split are very fuzzy, and more about getting a feel for balance (or lack thereof!) than to implement rule-based mechanics. Indeed, if aspects veer too heavily towards physical truths, then it might mean the game may be lacking in ideas in terms of more abstract realities, etc. You get the idea. :-)
…Sciences are visible
So, if aspects are hidden, how on earth is one supposed to improve their knowledge about the Universe, I hear you say? Well, via science and research.
Sciences are exactly what one would expect in a "tech tree" environment: they are publicly available, have a label and various other fields such as description, some pre-requisites and bring some advantages as rewards for allocating in-game resources towards them. One side of sciences remains hidden: their relationships with aspects. which shall be covered in an upcoming post.
The way they are interacted with is not quite what one would expect. Let us switch to "traditional tech tree mode" and follow what happens, more or less in order:
- See the science ahead in the tech tree; either in-game or a wiki somewhere
- Start working your way towards it via accumulation of "science points" and the like
- Once enough points have been accumulated, unlock the science and reap the benefits: new buildings, units, etc.
Some excellent games do introduce originalities in the above (such as randomness, having to choose once research is complete, etc.) but their mechanics remains fundamentally similar.
The way Ad Lumens is trying to make this work is as follows:
- Sciences are unlocked based on aspect knowledge points thresholds
- Any science has multiple requirements in terms of aspects/knowledge points; this means a faction needs to have accumulated enough knowledge points in all the linked aspects to unlock a science
- Once unlocked, a science
shouldmust keep on being researched - Accumulating research points towards a science has two main benefits:
- they are converted into knowledge points in aspects linked to that science
- they open improvement opportunities for blueprints and other entities linked to that science
- If an aspect is required to a science, researching that science will pour knowledge points into that aspect. Some kind of a bijective relationship between the aspect layer and the science layer
Going back to our fantasy settings aspects, one could imagine the following sciences. Some are bit silly, but I hope they will convery the idea:
| Science | Description | Required knowledge points | |||
|---|---|---|---|---|---|
| Earth | Air | Fire | Water | ||
| Blacksmithing | The art of merging fire and metal | 10 | 0 | 10 | 0 |
| Fire magic | How fire can be made to travel the air | 0 | 60 | 110 | 0 |
| Masonry | The art of building strong(er) buildings | 10 | 0 | 5 | 5 |
Based on those required knowledge points, it is easy to see which among the A, B and C factions have access to which sciences (check the table above). In the case they do not, they can continue to improve their "skill" with one of more sciences, thus improving their underlying mastery over the related aspect(s).
For example, by continuing to work on Blacksmithing - and thus accumulating research points in it - faction can not only get better toys linked to that science (probably stuff such as weapons and armour), but also keep on improving its deeper knowledge about certain aspects of the Universe: Earth and Fire.
Lastly, nothing prevents a faction from researching several sciences at the same time.
And that's for a brief introduction to the tech mille-feuilles. In an upcoming post, more details will be revealed about mechanics, etc.

Please signin to add your comment.