One user's unified solution for Use-based system

I am for hard caps so I entirely agree with you. Shroud's skills are not setup well for UO's system but some sort of system with categorical caps might be better than what we have( a weapon mastery and attack probably should not use the same pool in a skill cap).


@Moiseyev Trueden This is tangentially related to the thread, but I wanted to asked you about your perspective on macroing. I know macroing takes place in this game, but do you think that it really has as much of an impact as it would without xp pools? It does not seem to me that the players most developed are macroing, but rather those that have put in the most time.

That is not to say that macroing does nothing, but my experience in games like UO and Darkfall essentially separated the development rates into those who macroed and those that didn't. I don't get the same feeling of macroing dominating in SOTA.

The other thing that I like about the xp pooling(alluded to earlier in the thread) is that it acts as a soft deterrent for high level players farming low level spawns. The catacomb skeleton spawn might have been one of the best money spots, but the producer and adventurer xp meant that other spots were worthwhile even before balancing the loot tables. Giving people freedom to go where they want while stopping that issue getting too big is an accomplishment.

 

It was tough to get through the OP, there's a lot going on there. But I like this part the best (see quote above). I think it would help even out some of the powergaming that goes on. You shouldn't be able to farm mobs using your sword so you can push your fire inates up.

 

Yes. Macroing in and of itself isn't that big a deal. I don't use it because I find it pointless and boring, I play a game to PLAY not to watch my character play for me. Botting (programming macros to play for you or train when you are sleeping or afk) definitely is happening and our current system doesn't stop/prevent/minimize it in any way whatsoever currently. Although some of our high end players don't use it, that doesn't mean others might not be doing it. Using the gustball is not effective for skilling up, however, staying in the field while botting is definitely effective as it will keep your xp maxed.

The advantage of the idea in the OP is it would make it impossible (or at least significantly harder) to use one very high trait to power level lower traits (i.e. get tons of general xp by killing high end stuff with your blade and then gustball or power level life/fire/whatever by botting). It is still possible to bot even with the suggestion, but it would require those skills to actually be used in combat to build up the xp pool for that skill tree which might minimize or at least reduce the current bot/macro abuse. I'd actually be really curious to hear Themo Lock's opinion on the OP as he has far more intimate knowledge with power leveling to see if something like this would be a practical or viable option.

 

A macro isn't a big deal, but a well made bot is. A macro can't compete even by running 24/7..but a good bot can do anything a good player can and it doesn't need to stop to eat or sleep.

 

The problem is not that either solution would promote/prohibit bot-like behavior.
It only changes what you bot on, right.
Now you'll kill stuff to gain xp so you can raise all those skills you kept locked away so they can't fall, instead of running the bot to gain skill points.
In the end, you'll have bots running around doing the same thing for different reasons, but ultimately the same goal.

You will lose exp, because you have decay even while using a skill (!) actively all the time, which is like paying taxes, in exp.
While this is a punishing mechanic that's also forcing you to play a LOT (which most of us probably can't do - I'm living in Japan and spend most of my time at work and when I'm home, with my wife, so I only play a bit every day, if at all), which could be either interpreted as "encouraging usage of skills" or "penalty for not playing enough".

When you have a target template and your skills are too high, you may not be able to progress, because they eat a raising amount of xp per "tick" towards their next rank. You can only gain so much exp/time though, so, in order to have one skill raise beyond a certain threshold, you need to lock all the other "gas eaters", which will lead to you advancing in this one skill (which will continue to get progressively more expensive), while all the skills you locked now decay rapidly. You may even need those skills for your template, but you can't raise them all.

It's an exercise in futility, since all your locked skills, while not dropping in rank, will go into the negative. You'll have -x XP on the skill when you finally get around to leveling it a bit and need to use it forever to even see the green bar return. This is just totally frustrating.

With a system like UO had, just raising/falling skills and a hard cap with no decay on skills set to raise or lock, all this would not be a problem.

The macroing would then target skill gains instead of exp gain, but it would not change at all.

And that's what we've been trying to explain here.

 

In field botting is a huge issue that I would love to see the devs go after aggressively.

As for OP's system, most of my concerns are about implementation. Multiple pools per tree... That's a chunk of data getting updated constantly. Then you need to think about how you would split xp. Would you split by deciding by all skills cast during kills? By damage dealt? How do you handle multiple overlapping instances of combat?

Aside from the huge amount of data tracking this relies on in real-time, each xp splitting system has edge cases on skills that will get really poor ability to level.

I'm not against the idea that killing stuff with a sword for 3 hours not helping you cast fireballs, I just don't think the proposed system is practical.

I also don't like that he wants to remove even the option to micromanage. I like to do it, but I'm in here saying we need to help people that don't. Why should an improved system exclude me from doing stuff I like to do? I've already spoken to how there is logical basis for focused training, and even if I lose the exact system we have now I want some options to do similar things.

 

That's a fairy tale. Your fire skills raise when you use fire skills and only those that are connected.
Also your innates and the skills that raise your stats like str, dex, int, focus, hp.

You don't gain in fireball by whacking away with your word.

 

You could easily gustball fire magic using xp from fighting with swords. It might not be directly true but there is some interaction that functions similarly.

 

There's micromanaging and micromanaging.
I'm a firm believer in The Church Of Min And Max. I want to sit down with a pen and jot down what I need for my char to perform. I want to calculate how many points I need in what, how high I can go in this and in that to balance it so it feels just right.

That was possible in UO. Without XP, no decay. Instead it had stat and skill caps and means to train towards them and lock skills you feel are high enough. You could always untrain them later to reinvent your char, but you couldn't say "I'll be a mage today, a warrior tomorrow, a dexxer on Saturday and a mage tamer on Sunday, whee"
Which would be pretty insane anyways. Think about it.

 

That's probably a bug then, maybe with fire enchantment on your weapon.

Then again, who cares, it's a test mechanic for players to keep their engines running in a test environment, not some feature for the final release

 

It is not a bug- you just lock your skills while you farm and gustball other skills later. And if not this second we need to address the release design at some point.

 

I largely agree with you, however I can understand people having issues with it at points and the sword fireball example is one of them.

Also the system FEELS quite bad for those not micromanaging which I think needs to be addressed.

 

You can not lock a high skill and then gustball it later. I explained this above (scroll up till you see a reply with yellow and red). You'll be deep in the minus and all your exp from a full bar will be in limbo when you finally see that lost son again, the skill progress bar under the skill icon in the tree.

If you don't believe me (and I'd not be mad at you for that, after all, I'm a random dude on the internet), then try it out yourself.
Get whatever skill to 80, then lock it for a week, then gain xp till you're full, then gustball in some dark corner. Come back a few hours later and you'll find your skill grins at you funnily while your xp bar is empty.

 

I disagree.

 

The idea doesn't remove the option to micromanage. The focus is just on making sure the "off" skills are still getting SOME xp instead of a complete wasteland of 0 in order to prevent drain from affecting them and still have them slowly level up.

Honestly not sure on the best way to offset the splitting final xp concern you mention. I guess it would have to either track each ability used and portion it out, or adjust to give xp on a pure use (each time used) but then why both having xp at all. Curious problem there I didn't think about.

 

With what? Scrap exp? Players will howl? Can't make it right for everyone?
Either way, I'll adapt to whatever the game evolves, even if it's not what I envision - but it's also not my game.

 

I disagree and have already given issues in this thread.

 

You disagree about scrapping xp or you disagree about being able to make it perfect for everyone?

 

I know, Noric. And it's okay to disagree. That's why we're here, to find something that causes the least amount of headache.
For that, we need to identify the problems first, right.

At the moment, those are:
- the decay
-...
?

 

The first part of what you mention sounds like something easier to address with reformulating their xp distribution calculation and tweaking decay mechanics.

As for the "curious problem", that kind of thing is where OP's system has weaknesses. Their current system only needs to add to one pool and then subtract (and then divide what is subtracted) when things happen. That system is both trivial to implement and less intensive to run than the stuff OP's system needs.