Announcement Making of the Ability Tree

Hello peeps!

Back in 2015 after the Gavel update, I posted a thread going into more detail about how the item system was created. In 2.0 I was designing the Ability Tree system and most of its abilities, so I thought it may interest some of y’all to see the process behind it!

Keep in mind this is only showing the system design side of it. A LOT of work went into the code, game design, testing and art as well, which was done by other very talented people in our team!

Be also aware that game design (or at least the way I do it) is quite messy in its early stage. You won’t be seeing polished things, numbers and ideas will be all over the place.

As it is usually the case with big projects like these, the Ability Tree was something we’ve been wanting to do for quite a while. It was also a recurring suggestion in the community. With large systems like this one, I generally start with problems I want to fix and that I think can actually be fixed with it.

Problem #1: The game’s class progression stops too early and is too slow.

Back in 2013-15, the content of the game basically ended in the level 70s at best. Unlocking your last upgrade at level 66 was fine and made sense. That ain’t the case anymore, and level 66 is now merely mid-game. Getting 1 upgrade every 10-15 levels was also much too slow.

Problem #2: Spells are outdated.

Not only did spells not look cool, but they were also really lacking and outdated in general. A strangely important but subpar system when compared to everything else. It needed something rad with more variety.

Problem #3: Items are too complex and builds irrelevant until endgame.

If you’re a long-time Wynncraft enjoyer you might disagree with the complexity problem, but it is an issue that’s grown to affect the early and mid game more and more over the years. The item system is loved by many and allows a fair share of fun diverse builds, but is also riddled with unclear combos that increase the complexity and require some learning. This is not a bad thing in itself necessarily, but the fast progression of the game makes it useless to learn any of this. In the end, it led to players not really interacting with the system as much as we would have wanted.

I’ve always hated seeing new players ask questions about items and build, and getting told to not worry about it until the endgame. Most players never even come close to the endgame! It is a bit of poisoned advice that guts the fun out of the game for them.

Now obviously, the Ability Tree doesn’t really change this that much, the item system is still quite complex. But if you start seeing this as not an item problem specifically, but a build-making problem, then it makes more sense how the AT could fix it.

Those were the top problems I believed the Ability Tree could fix, or at least improve.


One of the first things I did (one week after 1.20 came out) was ask the Content Team to send all of their upgrade ideas. I would end up using this list quite often. In the end, it had a total of 460 submissions! Not all of them got in as-is, but nonetheless, they were all useful in one way or another.



At this point in development, it’s not the time for balance or anything too deep. It’s brainstorming and throwing things at the wall until it sticks. No numbers allowed! Only figuring out what the Ability Tree will be, and what fantasy we can achieve. No code is being written until we have a solid base.

What do I mean by fantasy? Well, the idea is that game systems should encourage players to play and feel a certain way. If you pick up Fallen for example, you MUST feel like an aggressive berserker dealing massive damage. It’s what the archetype promises and the abilities must work in a way to encourage this. It’s an important step that is easy to forget the more you work on it. People play MMORPGs to get into a role in a living world, if they only cared about numbers and balance they would play barebone incremental games.


Once I started getting ideas, I got going on Warrior abilities as a proof-of-concept. At that time, I didn’t know how the Ability Tree would work or look, or even progress. The only thing I knew 100% was that we should keep the simplicity of having only 4 spells.




You can see here that some of the Warrior abilities were already there, though in different forms. Originally I wanted to make a Drunk Warrior gimmick, but it ended up becoming the Berserker (later Fallen) archetype.

Some of the ideas/concepts figured out at this point were:

• Conditional abilities (when X… after Y…)
• Ability tiers and their differentiations (What makes a low tier ability different from a higher tier one?)
• Convertor abilities (For every X item ID, gain Y)
• How abilities were worded. It sounds superficial but it is important in order not to make the system hard to learn.

I also wrote some more conceptual ideas to use later down the line.



At this point I was satisfied with the early Warrior abilities and the possible fantasies and gimmicks. I started drawing diagrams of what the Ability Tree could look and how it could work. A lot of them.

v1


v2


Around this time (summer 2021) we started coding the behaviour of the Ability Tree. Nodes connected together that can be unlocked and flow downwards. We made sure to make the system easy and quick to edit by making the connections between nodes automatic. It has its limitations, but overall it saved us a lot of time.



nice!


not nice! that’s what automatic connections get ya sometimes

v3



At the time, each archetype was planned to be separated into its own tree (after unlocking Bash). I ultimately decided against that later down the line, I’ll explain why later.


every new CT member laughs when they see we use shitty MS paint drawings to plan things, but they always end up doing the same. always. creating a visual representation of what you want to do is surprisingly helpful

v5 (v4 was nothing special)



v6. At this point, I started experimenting with having a single tree per class. I also started writing random notes to myself, which shows I was spending way too much time looking at diagrams.


v7 With an emphasis on progression instead of abilities


This is probably the most recognizable version of the tree so far. The early game AT progression is slowed down, spells unlocks are together on page 2 with other minor abilities, and the elemental upgrades on page 3 are there. It’s not shown, but the 3 archetypes are also mostly decided: Berserker (Fallen), Monk (Battle Monk) and Tank (Paladin).

Then real development began. Zeer and I spent hours every week in calls implementing, testing and changing things. Since there were many unknowns still, only he and I were working on it. I generally prefer to work with very small groups of people to start with, until the idea is solid enough to be open to criticism from the team. Ideas are very fragile in the beginning, so it’s important to be careful when showing it off, even to other people in the team. You need a good base for others to truly get it.


v1 of the ability tooltip. a little too colourful

Once we had a dozen or so abilities, I started working on a short design doc to explain to the CT how the tree worked and the concept of “Islands”.




I also locked in some rules about the design of the AT GUI, such as:

• Abilities are never on the first row of the page.
• Abilities are also never on the last row of the page, unless the branch ends on that ability.
• Ability connections flow downward or sideways, not upward.
• Abilities with archetype requirements should always be unlockable with the abilities above it (aka don’t put an ability with requirements so high people can only unlock it much later).
• Abilities shouldn’t be right next to each other, even if they are connected. Show the connections at all times.

I had multiple choices for how the tree could work and look, and I ultimately decided to go with the one tree per class with an island system.

• It made it easier for players to combo different playstyles
• In Minecraft, we have very limited options for GUIs and having to fumble around multiple different menus isn’t optimal and becomes a chore when you have to do it often.
• Allowed us to make some more generic abilities that don’t necessarily fit with any archetype
• This one wasn’t originally planned, but I noticed once it was working that it also made the tree look a lot more filled in general. There are a lot of pages and a lot of abilities per page. Player perception is important in game design too!

Some other ideas were:

One separate tree per archetype
Discouraged combos too much. The early abilities had to be weaker than the latter ones, so if you already invested a lot of points in an archetype tree it didn’t make sense to spend points in another one because you’d get weaker abilities to start with.

One separate tree per ability
Made it too easy to “one-trick” a single spell, I was afraid this would encourage stale gameplay.

Midway through development we realized the old damage system Wynncraft used was slowing us down a lot. We spent almost as much time dealing with it as coding new abilities. So we decided to take a month off to rework it. This was by far the worst part of the development process but it ended up being worth it. There isn’t much to show from that time except some disgustingly complex docs.

I do have this design diagram that wasn’t as useful as I had hoped (and is a bit outdated now), but at least it looks cool and I can use it to show how complex the Wynncraft damage system can be.


Now that we’ve got the base Ability Tree system and a bunch of abilities, it’s time for the design -> implementation -> iteration flow. Each week we designed and coded new abilities, then went into a 2h call with the CT to talk about it and improve based on feedback. It’s a very repetitive process and went on for about 8 months.

Although I was the one designing abilities, it doesn’t mean I did everything by myself! Here’s some of the chat I could get back from that time.

Warning, the language can be a little rough.


Designing the guardian angels ability



Testing stuff with the CT during our weekly calls. I don’t know why we destroyed detlas for this


Finding a good name and theme for an ability


Showing the trapper’s wolf


Figuring out how to make a complex ability sound less complex


Testing the fallen archetype


Showing the trickster’s clones


Notes about animations we needed with the help of terrible MS paint drawings again


Feedback about the potential viability of an ability


Zeer and I teleporting into a house in Ragni for hours to polish the teleport spell and making it un-abusable. We had to recode every existing ability for the ability tree.


Coming up with the riftwalker archetype


Working on the tangled trap ability with random particles



Figuring out a name for the summoner’s crimson effigy

Let’s finish this by going back to the original 3 problems I wanted to fix/improve

Problem #1: The game’s class progression stops too early and is too slow.
You now continuously get points until level 104, and gain them much faster (especially in the early/mid game). Great success! It can even be extended easily if necessary.

Problem #2: Spells are outdated.
Abilities look cool! Partly due to better gameplay and design, but also because of the awesome particle effects created! A lot of people worked on those, but I want to highlight fishcute in particular who really did a ton of them. Zeer also did a surprising amount of them by himself!

Problem #3: Items are too complex and builds irrelevant until endgame.
I can’t say this has been dealt with 100%. As I said earlier, items are still about just as complex. We did improve and fix the compass damage calculations to help with that, but it can only do so much. What the AT did however, is create a second build-making system that is much less complicated. You generally only have 2-3 choices at once and are encouraged to follow your archetype’s path. Instead of being a puzzle with 3000 pieces working together, it’s now a 10 piece puzzle that can feel rewarding without too much work. The choices you make matter for the entire playthrough.


That’s it for this time! Hope you guys found this interesting. Game Design is still not a perfected art and there are many ways to go at it, it’s just the way I personally like to do things. Don’t take this as THE way to design things.

 

pretend i said something funny and/or witty here

 

you're not completely wrong but honestly, i think we did alright balance-wise knowing we had to switch from 16 to 80+ upgrades per class. this shit gets really tricky when you start thinking about how all level ranges are affected and need to be balanced properly for various playstyles.

 

Oh yeah, only me and salted know the time I spent trying to make the jump feel good and go in the direction the player expects it to but still respect the wall.
We were on an ability development call for like 4 hours and he was having a meltdown because I wasn't satisfied with how it worked lmao