1
Reddit link : https://www.reddit.c...lementation_in/
I will divide this entire concept up in a few sections, namely :
1. Meaningful Choice
2. Important pillars and core concepts
3. A means of balancing
4. Implementation towards the future
5. Further changes accompanying the tree and their use
-A possible concept-
1. Meaningful Choice
To start things of, the subjective term of “meaningful”; Our design must implement features in such a way that most of the clients can appreciate the choices they have to make.
The important question is; what is “meaningful” and how does this matter? A fast definition provided via a search states : “full of meaning, significance, purpose, or value; purposeful; significant”
For a gaming demographic, a meaningful choice in their game means that they want to feel an effect from their choice; I can “choose” to make my mech bright blue with red polkadots but that choice is not “meaningful”, it’s “aesthetic”. A meaningful choice could be to decide to use an LB20-X or an AC20; both specialise in a certain range, but with different mechanics.
In simpler terms, it’s choosing between an apple and a pear, when both are right in front of you on a separate plate. The choice is as you want, perhaps you don’t like pears, you choose the apple. If you don’t like apples, you choose the pear. If you enjoy both, you will pick whichever you feel like at that moment.
2. Important pillars and core concepts
As Chris stated often in the Podcast, PGI has a number of “pillars” they’d like to adhere to.
- A Focus on battlefield roles
- Investments towards more general roles
- Significant investment in “high value” stock / trade-offs
- A sense of progression
- A balance in economy
My first issue with these pillars, is that you want players to focus on their battlefield roles, but at the same time you want everything to invest towards general roles.
These two concepts clash in practice. A focus on my role as a scout, would lead me to take skills related to scouting and info gathering. A focus on dealing damage or taking down heavily armoured mechs, would lead me to take skills which help me fulfil that goal.
The general roles obstruct the very same nature of “battlefield roles”, and for a game such as MechWarrior, the choice to specialise is far more important than to try and make everything “equal but different”; this entire concept has led to the chaos that is the current tree.
A second issue stemming from these pillars, is the notion of “high value” skills. In a fully designed system, the “high value” is entirely dependent on the player at the wheel. For some, the high value lays in their “speed tweak”, for others it lays in “radar deprivation”, for someone else it lays in “ECM”. This balance is not something one person, or one team can decide; balancing towards this leads to even more unbalance for everyone who happens to hold a different opinion.
Everyone agrees that a “sense of progression” is important; if you invest points, you want to see the difference, you want to feel the change. The current system is lacking in this regard because every bonus is too small to matter, things are too far away or your path is littered with things you don’t want. To take the earlier example of the apple and pear; imagine if you had to drive to a store 10KM away for the pear, while you can get an apple by only driving 5. If you don’t care, you drive to the apple, if you like apples- Hey, good for you, you don’t have to drive for a pear anyway! If you like pears, you feel shafted. Add to this, imagine having to drive around to multiple different stores to get slices of pears or apples to try and assemble the full fruit.
For the balance in economy, this is a fine line to walk; personally, I don’t feel like the economy matters; it’s the players that need to feel that they are being justified, there will always be people playing in a way that someone else wouldn’t ever consider of doing. Mechwarrior Online has a rather closed system, this is a good thing. If you accidentally make someone richer, but treat the others fairly using the same system, then I feel this is a valuable trade-off.
3. A means of balancing
In an ideal world, the skill tree functions as an additional means of balancing individual mechs compared to each other or their variants.
While asking for an unique individual tree per mech is an impossible task, there can be ways of implementing the tree in such a way that you have a solid base structure where you can implement new systems, remove old ones and balance individual branches on their own without affecting the entire balance. Once more, the existing skill tree fails in this aspect due to the misinterpretation of value and the use of “junk”-padding; for each change, you will have to consider everything surrounding the area of the change, because you might end up undervaluing or overvaluing nearby nodes.
4. Implementation towards the future
We require a solid base where, once the initial system is in place, we can add or remove parts as we wish, when we wish. Modularity is a big factor in this; much like a house where you can build extensions or decide to extend the garden or revamp the entire thing leaving only the main support walls; still considering that a house being far more limited than an online implementation, the example still holds.
We want to have these “main support walls” in our tree, namely the design itself; the contents simply don’t matter if the design itself is solid enough to carry itself.
Moving forward, if down the line a drastic change or new thing comes in, we need to be able to implement this without having to re-do our entire previous work all over again; that would mean we have wasted the entire initial development process and triple or quadruple our new workload. There will be more on this later in this thread.
5. Further changes accompanying the tree and their use
To have a near-perfect implementation of the tree and the core pillars after the initial implementation and balance patches, there will need to be minor changes towards the game in the form of rewards; to allow for “battlefield roles” to be a viable option, there needs to be further rewards for scouting, info gathering, supporting, tanking, …
Currently, the game mostly rewards for dealing damage; even if you were the one responsible for allow your team to [*shudder*] LRM the opposition by risking your hide via the means of a flank and a close-range targeting of an ECM mech, the reward you gain for this is negligible. The same deal if you stick with your team to provide an ECM bubble or if you happen to carry 3 AMS systems to protect against missiles; the rewards are too low to matter and therefore push people to pursue damage over teamwork.
_________________________________________
-A possible concept-
Once again, a disclaimer : This is how I would implement a skill tree, with the above goals in mind; feel free to disagree, I won’t mind having a debate over certain sections or parts and I’m open to sensible change. I also offer my apologies for the bad graphics I will be using, I am not an artist and cannot shuffle nice graphics out of my sleeve in a matter of minutes.
My implementation would focus on “player choice” in a modular skill system, taking in account most of the main pillars which I deem important for the game.
1. Meaningful Choice
The choice would be entirely up to the player, let the player balance their mech out according to their own will, without being obstructed by various “waste” skill nodes.
First, the tree will be linear in nature; but more akin to a forest of trees rather than one large branching tree. For the development, the splitting into multiple minor trees will allow : a balancing per “branch”; the option to add, stretch, shrink individual branches per system; allow an implementation of new systems and new technology into the existing design without requiring a massive rework of the entire tree.
Reference image 1 : http://i.imgur.com/CLbT99f.png
Note here, that the “Support”, “Mobility” and “…” branches of the main mech, are separate “cores” with branching nodes.
Not all optional skills should be “worth” taking for everyone, make them optional so that people who want it, have access to it.
There will NOT be 91 skill points, far less. I’d imagine somewhere between 40 and 60, perhaps. I simply don’t have the time to do a full research on how many skill points would be optimal.
2. Important pillars and core concepts
For me, I will place priority on some different pillars first :
- A dynamic, modular, tree system with a focus on future implementations
- Ease of access for current and future employees
- A logical design system
Our main goal should not only be the implementation of A skill tree, it should be an implementation of a tool we can utilise in the future and makes our life easier in the long run. We should avoid having to retrace our steps on something which should already be finished when we’re 8 months down the line.
If our base tool is solid, it will allow for more options to deal with possible problems as they show up.
- A focus on battlefield roles
The concept would allow people to specialise in their wanted role, alongside the required changes to make the other roles more viable, while not obstructing them with “filler” nodes. Their choice would be between apples, pears, grapes, bananas, lichis, kiwis, … but they will be unable to get everything.
- Investments towards more general roles
This, for me, is the pillar that needs to be removed; it is obstructing our design choices, limits the actual goal of role diversification and turns everything into a “Kinda similar but the same”-mentality.
For this reason, the firepower tree needs to be a separate entity, split off from the entire remainder of the tree, besides selecting how much points you wish to select in each weapon. [more on this later, since this is a big change]
- Significant investment in “high value” stock / trade-offs
One perk point should always stay one perk point, if one has 40 points to use, then allow them to take 40 nodes. Make the important systems a choice, and do not try to decide what is important for someone else.
What can be changed, is to make “overperforming” systems, cost more nodes to fully implement; say 5-6 nodes to get the full 100% of the ability; the players will then have to choose between fully investing, half-investing or not investing at all if they deem it’s not worth the points they have to spend.
The difference here, is that we are not forcing people to take things they don’t want; everything should be accessible, with the invested value being different according to role and usage.
- A sense of progression
A player needs to feel that each point they invest, has some sort of effect they wish to have. Therefore, by splitting up, we can make each point a valuable investment the player chooses to have. Even if the initial point feels “lacklustre”, they know that they can spend one or two points further to gain a bigger effect. This also allows experimenting to see just how much of a boost they need to certain systems and make each mech feel unique to the person piloting it. Yes, there will still be “meta” builds, but allow people to experiment and feel what they find best; you cannot avoid “meta” builds, you also don’t have to actively disallow them either unless they drastically upset the balance of the game [which is unlikely, given the concept we are currently working in] and if they do, we can adjust the troublemaker mechs or trees individually.
- The firepower tree
Here is a drastic change; I want people to be able to decide how many points they want to invest in a “general” weapon-system node on the main tree branch. Each mech would have a different maximum value, which we could change depending on the performance.
Reference image 2 : http://i.imgur.com/fgxIIqI.png
To avoid giving everyone X points to automatically spend in the tree, we shall give people a choice on how many nodes they wish to dedicate for each weapon system. This weapon system would be present on a separate tab of the skill tree, and would base itself on the currently equipped weapons.
In the following example, we have a Dragon with AC5, a PPC and one medium laser, the player has decided that they want to spend 7 of their total amount of skill points on their weapon systems, choosing the other points to go elsewhere, such as mobility or equipment systems.
Reference image 3 : http://i.imgur.com/iupZYd6.png
At most, this player would be able to spend 15 points in the firepower section, but, they decided otherwise and settled at 7. This allows them to spend 7 nodes in EACH weapon tree they have currently equipped. They won’t have to scroll down through 10 different weapons to find it, the only trees available are linked to the weapons you have equipped.
This both prevents stifling the player with too many trees on screen, but also allows us to make a modular tree for each weapon system, and adjust it accordingly at our needs.
Is the duration too short with the skill tree points invested? Adjust the nodes accordingly. We don’t have to think about the overall concept of ALL duration weapons, no, you just balance this PARTICULAR weapon system leaving the others untouched.
We do this, so, if the player chooses to, they can go full out on defensive and survival aspects, and don’t get free weapon bonusses; it must remain a conscious choice. The general decision on spending X points in the Firepower tree, allows “boating” without putting mix builds at a disadvantage.
You could have free points in this already, say 5 or something and this extra investment is just that- Extra, but that is not up to me to decide.
3. A means of balancing
With the above design, we have the opportunity to carefully and individually adjust components and sections of each part of the tree, without directly influencing any other parts.
We can individually adjust ECM, without having to take in account Radar Deprivation or Target Gathering.
We can implement an entirely new system, such as “Beagle Active Probe” range, by branching a new path from the main “Equipment” section, without having to relocate and revalue everything else currently existing.
If, we find that some tools are too strong; we can once more evaluate, locate the issue and adjust where necessary.
If, we find that some tools are too weak, we can adjust the total value of the branch, we can adjust specific nodes of the branch, or shorten the branch so less points have to be spend to get the total result. If “Beagle Active Probe range” is not good enough while spread over 4 points, simply make it 2 points, or even 1 point.
4. Implementation towards the future
We already know that new technology is incoming, and the current tree is unfit for said implementation. Now let’s consider a large change such as 15 new weapon systems being put into the game.
We design 15 small trees, most likely being able to copy over an existing tree and change the values. Say Rotary AC5 will have a lot in common “structure-wise” with an AC5. We copy the AC5 tree, adjust the nodes where necessary, remove or add a branch where necessary and then evaluate the system.
Upon release, we find that the rotary AC5 overperforms/underperforms, we adjust the weapon itself, or we can adjust the branch if the issue lays with the bonus being too powerful or too weak.
We have multiple options to deal with the same issue, a branch adjustment, a weapon XML adjustment, a mech bonus adjustment.
Now, let’s take a step back and look at my previous example, the “Beagle Active Probe range”. This branch would only come in effect for someone who has this probe active on their mech, it’s an optional piece of equipment with further optional boosts. Currently, we cannot implement this easily, because we’d have to fit this thing somewhere in the existing tree. In the implementation I am currently laying out, we can simple add a side branch and not worry about anything besides that specific branch. Is our new branch too strong, lengthen it, or adjust each value; once again, we don’t have to consider affecting ECM or AMS. The same goes for nodes such as Hill climb and Arm Speed. They should be present in the tree as optional nodes if people want them. Will some of these go underutilised? Sure. But does it matter? If the option is there, someone will eventually utilise it to make something work more akin to their wishes, without us having to have a say in it.
If that wish of the player makes something overperform drastically, then we can look at it when it occurs, adjust parts accordingly and we’re back on our way.
5. Further changes accompanying the tree and their use
For our “role diversity” and “roles on the battlefield”, we will have to implement multiple changes to how the game calculates success. There needs to be a boost of rewards for people who align themselves with support roles and systems, such as AMS and ECM. If you’re covering a mech currently under missile fire with your ECM, you should be awarded. If your AMS is protecting half of your team from incoming missiles, raise the reward for that player to actually reward them for helping. Currently the game only focusses on “Damage dealing” as a metric, and while it works for those specific combat roles, other roles are left in the dust.
______________________________________________________
Edits / further information:
- I left it the actual node count deliberately vague, you could have a different number of skill points available per weight class, or even more skill points for certain chassis, much like a quirk "+5 available skill points" or something.
- I forgot to mention, I would like this implementation of the tree to work together with the existing quirk system, so you can adjust the power of some mechs without affecting others generally. [something which the quirk system does well].
- There are multiple ways of balancing it, from stretching out the number of nodes, shortening the number of nodes; equal value per node, gaining more value per node, lowering the gain per node, ... It's all a possible way of balancing an individual part of the system.
________________________________________________________
Now, as far as branches and trees go, I would like to refer to So1ahma’s work once again [ https://www.reddit.c...ockup_proposal/ ]. My firepower section is completely different in implementation, but I cannot help but utilise some of his more pleasing imagery, which I will link here :
General tree parts :
http://i.imgur.com/hSz1K3c.png
http://i.imgur.com/7GbTa9l.png
http://i.imgur.com/dqTc3Is.png
http://i.imgur.com/zOWJOHw.png
Weapon specific trees layout or concept:
http://i.imgur.com/xdoyfkk.png
http://i.imgur.com/UPQBW06.png
http://i.imgur.com/Tx5kFow.png
In my case, the "/14", would be a maximum cap of the amount the player chooses to invest, where the player can decide just how many skill points they wish to implement.
_______________________________
Thank you very much for reading!
Edited by Anatidaephobia, 13 March 2017 - 07:43 AM.
