The ENTIRE Skill tree system needs to be completely redone. Over 40% of interactions don't work/broken, 70% Useless. (Rant warning, I quit, this game will be at ~100 players in 8 months))

You’d do that basic test. Then if it turned out that Vengeance’s Ripostes and Iron Blades aren’t adding stacks as melee attacks, then the player who notices this should report it because it’s not functioning as intended.

This idea that a QA tester doesn’t know what to test is extremely silly.

In most cases, it’s literally written on the skill. Not to mention that test analysis is also a part of a QA tester’s job. Asking a coworker for clarification is also a thing. Please go away with these silly assumptions.

Proper Q/A over a period of 4 years would have eliminated all bugs. Even if it was 1 devs doing this for 8 hours a day for 365 days per class.

I played 300 hours only and found lot of bugs that anyone could test in hours if you had Q/A. No excuse for things not working.

LE has 100 people. Not 5 not 10. It’s bigger then Larian was with DoS2. That game was almost flawless on launch by comparison.

I will not carebear for what should been an easy thing to prevent

2 Likes

Agreed, mostly. If you have an experienced/qualified QA tester and not use regular Dev B to fill the role as a site gig, they will know how to do their job.

But not everyone knows how to do their job, even if hired as an QA employee or put in the role.

What I wanted to say: EHG seems to lack (or lacked back then) actual QA employees who know what they are doing, I am afraid to say.

Proper QA would have prevented a lot of the bugs, but unlikely all. A year has more like 220 working days with 4 weeks of holiday and the average one or two weeks of sickdays.

How much wage does a full-time QA tester cost over 4 years? How much spare funds did they have?

LE has 100 people, supposedly. Nowadays. They had not that many four years ago. Larian was not a new, but an established and experienced studio, with multiple games to their name, established structures and business contacts. Apples and oranges.

Bugs suck, and LE has far too many. Those that are known were left untouched for too long. The customer can rightfully be pissed about this, no matter the circumstances that lead to this point. I don’t excuse them for this. I just try to show some explanations.

Perhaps things aren’t always as easy as we as outsiders think they are.

3 Likes

My unwanted opinion! You’re welcome!

If a developer creates a game that they are unable to do functional testing on, then that developer made a mistake creating that design. If you create something so complex that even you, the creator, have no idea how to test it… whoops! But it’s probably really cool, so maybe enthusiasm can get us out of this rut.

If your testing solution is human testing, and you simply cannot hire enough humans to test your product, then you needed test automation to be an up-front part of your design. Whoops^2.

But not completely unrecoverable! We live in the age of crowdsourcing. With a motivated player base this jam is not unsurmountable if the company puts effort into managing, supporting and encouraging the player base to test and report errors. Galaxy Zoo is a thing! So if you can’t do in-house testing, and you can’t figure out how to do automated testing, then you should try to work with motivated players to help you out. It certainly isn’t a player’s duty to do that. But for the players that do help out, especially those that go so far as to test, document and report, the developer definitely should go out of their way to make those players feel appreciated. Those players should, in fact, be appreciated.

BUT, if it seems like the only bugs being worked on are those that get visibility online, and if bugs languish for years, and if fixed bugs return from the grave, well then that is WHOOPS^3.

WHOOPS^3 is a bold move Cotton, let’s see how it works out for them. :popcorn:

3 Likes

I mean, this is the whole basis for the AI we have now :stuck_out_tongue:

2 Likes

Typhon, even if I don’t always agree with you, I’m always happy to hear your opinion. Thank you and share away.

Also, obligatory “what can I say, except ‘you’re welcome!’”

2 Likes

I assume you basically ignored the second sentence in the pic you linked.

So you’ve never had a job in game development then. Which is fair 'cause neither have I, but I have done closed testing & it’s not as quick/easy as you think it is.

Oh, you don’t want to know about pertinent stuff so youcan carry on in blind ignorance? Ok!

Levelli g & trying odd shit is just as important as tryi g what apoears to be the most meta approach. Plus you need to test that each point actually does what it says it should in every simgle combination.

You have no experience with what yhat actually means, you’re taking a “player perspective”.

Yes & games have become significantly more complicated in the past 30-40 years, but that requires understanding & nuance.

How much resources do you think Square Enix had to put into game dev compared to EHG. Do you think that they are slightly comparable? 'Cause all you’re saying is that if you have a lot of resoyrces you can put a lot into testing. Also, wasn’t ARR the second attempt to release ff14?

Which defeats one of the major points of testing.

People asked for pinnacle bosses, just not you (which is fair, not me either).

Fixing other bugs, just not those ones. I’m not going to ask you to read through all the patch notes, but would you accept that they do contain quite a lot of bug fixes?

1 Like

I genuinely laughed out loud. That’s such a fantastic point that didn’t even click with me at the time.

Game was so broken they had to have a demi-god nuke it from low orbit. (absolutely one of the coolest and most cinematic server shutdowns I’ve ever seen though.) It’s a great game now, but 1.0 was… It was something.

1 Like

I don’t know about great but it’s decent. FF14 online I played it and found it very boring. Far worse then most Free to play alternatives.

All the things you need are shown on the bottom part of every skill node. Which is what that skill does exactly. The above, is just a detailed text of how the skill functions. For someone like me who makes lots of builds, I just need the bottom part to know whether I need the skill or not. It saves time. Was it my mistake for not reading the description? Yes. Is it correct below to say “benefits” before the subject of a skill that’s not even inside the tree you’re speccing? No. From that text I assumed that thorn totem benefited from healing totems. Which didn’t make sense if you think more on it, but for someone rushing to farm the skills again and again and again, it’s an easy thing to miss. Especially when it’s badly written.

No I haven’t, but I do have a bf who does exactly that. I never use his stance in any argument because it’s probably not a general truth. But at the place he works they don’t do shit about testing. They’re given a script like thing, that says: Make this skill do this, this way, and they coordinate between themselves to code it right. Nobody is testing at his workplace. They don’t test. Do they test at EHG? I have no idea. But I do know given the resources they can give a tester, you’d need exactly a single person per class over period of time to figure out all the gimmicks and tricks and skill interactions and whatnot in a short time, over a period of a month if not less.

Out of context sarcastic remark that has no bearing on anything said here. The said scale was overblown out of proportions when in fact skills have limited interactivity with other skills, and testing for logical valid builds that every player who has a single neuron in their head will select, will in fact not take up much time.

This is a conversation about skills not doing what they’re doing, nothing to do with the leveling process nor quests being bugged.

Just your arrogant opinion.

They have become cheap and lazy, cutting corners everywhere. This is why we get things like these. Not because they’re “complicated.”

1.0 was a disaster, and it crashed and burned. ARR didn’t have many bugs, it’s why its survived. Not a single person would’ve given SE a second chance had ARR been half as bugged as LE is currently.

No it doesn’t.
The leveling is killing monsters. You don’t need to see each level pop so you can put a point somewhere. You can give yourself all the points all at once and put them in your build and see if they do what they do. This is just nonsense.

Yes, they fix bugs people complain the most about because they’re the meta and people sure do love their meta builds. Everything else doesn’t matter right?

1 Like

I would like to have the devs take a few days and just update the tool tips by providing us equations and wording properly.

I played a lot of games. A lot of those are ARPGs and I get confused almost all the time in LE because of wording.

**Nomenclature **

Somewhere in every skill clarify explicitly if:

Base Skill is:

On USE, ON RELEASE, on ACTIVE skill component, on Trigger (attack/hit/on element ) on ailment applied to (PC/E), on condition to player (hit, heal, on ward gain, on Y)

Also: skills BASE + how much Scaling (not tags), critical chance, critical multiplayer, can skill prock? Can skill leach?

Separate DOTS, Ailments, Multistriking Hits (hits X times per second), auras, and their respective hybrid combinations.

Each tool tip should reflect 3 numbers. The damage dealt ON HIT, (initial), damage over time (if applicable), and damage from follow ups as separate.

Eg: I use infernal shade. Infernal shade

Front up damage=0
Dot damage= X
Explosion= Y

I don’t want to see these numbers combined as it’s impossible to now at a glance what you should scale.

Eg: I use an attack that applies poison and ignite and also applies blind. I should see:

Tooltip:

Poison: (X stacks): damage will be X
Poison: current chance to apply poison

Ignite: (Y stacks): damage will be Y
Ignite: current chance to ignite

Blind: (is X% to apply)

**No for skill nodes **

If a skill node ADDS / replace a tag: it should state this and update on tool tip. So if I use meteor, and I got lighting set rod. I should now in tool tips see (lighting) not fire tag

If a skill removes a function. Update tool tip:

You chose: eg: Chariot. Skill function is replaced. If nodes conflict [highlight them In RED and out a giant red :x: on tool tip to alert player they messed up.

If a skill has multiple elements: you should see the tool tip broken into X rows.

Eg: Elemental Strike

Fire: X damage
Ignite damage: Y
Ignite chance: Z

________________ (put a line to separate)

Cold: X damage
Freeze chance: Y
Frostbite Damage: Z
Frost bite chance: X

____________ (put a line to separate)

Lightning damage: X
Shock chance: Y
Electrocute chance: S
Electrocute Damage: Z

Each tool tip should be clear. If they are messy your Q/A testers will miss things and so will players. Each source must be clear.

What I learned from doing YouTube: assume the viewer is 7 year old child. Make everything crystal clear and easy to tell apart

1 Like

That is honestly so excessive to what’s needed.

Screenshot-20241001-235916

Is more than enough with the actual in-game tooltip also showing the damage range for your equipped weapon in the “X% Weapon DPS” section. Like “430% Weapon DPS (X-Y)”

Edit: have a detailed tooltip like that for every skill node barring ones that simply add an effect like “can cleanse ailments” which you just have… “can cleanse ailments.” for the description and LE would be in a great place tooltip wise.

Exactly, the bottom row is a shortened text for the modifier, the descriptive text above goes into more detail. You appear to want a more verbose description on the bottom row which would make it wrap around onto multiple lines which would be bad & defeat the purpose of having a shorter text at the bottom. Plus the bottom row doesn’t always go over important things like whether the modifier affects just the skill hits or applied ailments as well.

Why? It quite clearly states which direction the benefit is going. If it was going in the direction you assumed then it would have said “thorn totems benefit from healing totem tree”.

It’s only badly written if you’re just scanning it & not actually reading it & taking the time to think, which is what I’d imagine is what happens if you’re making a build from scratch (that’s what I do, especially if you’re not necessarily very familiar with the tree & nodes).

It was perfectly in-context, thank you very much.

My egregious typos aside (damned phone keyboard), all skill nodes needs to be functional at all number of points (sometimes the first point works, sometimes that’s the only one that does), not just the ones that “every player who has a single neuron in their head will select” (thanks for denigrating anyone that isn’t a meta-slave, classy!). Things (including skills) need to work over the levelling process/early game, not just at the end game with maxced out/BiS gear.

Except you’ve just said that you don’t know anything about testing, nor does your bf because apparently their software never has any bugs, so by your own admission you don’t know how much time it takes per skill/node. Having done testing before & had to write up useable bug reports (not just “X doesn’t work, pls fix k thx bai”), it takes a lot longer than you’re thinking. Especially the documentation bit so that the programmers can have a better idea of what’s going on versus what should be goinb on in the code.

Plus, the scale that you decided has nothing to do with the issue at hand is very much pertinent to the issue at hand.

My experienced opinion plus "using your own spells words against you.

To some extent, yes. But if you don’t think that modern games are more complicated than they were in the 80s/90s then that’s just showing your lack of experience.

But how do we kill mobs? Do they just die & give us xp when we walk past them because they’re so overcome with our awesomeness? Do you not use skills while levelling?

Not all of them, no.

According to you, that is correct.

As would I, but I don’t think the tooltips are the place to have that when we have the in-game game guide which has more space.

I believe that Kiwitus said “beta test all of the skills and their interactions”, which includes testing skills at 1/X points invested.

As for “things”, they are not something you will test on a regular basis, because unlike skills, they’re not changing leveling process nearly every patch. IIRC we had leveling bugs on release and we still have them today as indicated by 1.1.7.2 Patch Notes, so it’s not as if their QA did a great job on leveling tests either.

You’re assuming a lot here.

The scale was absolutely blown out of proportions, we even got a “thousands of interactions” comment in here.

Not sure what testing you did, but in case of many skills it would absolutely take minutes tops. For example, a skill passive with effect “X% of attribute gained as Ward per cast”, your bug report would literally be

Skill name - Passive name

Passive X doesn’t give the correct amount of Ward. It gives Y, should give Z.
Attached:
2 screenshots OR log (if even required)

And writing a bug report definitely doesn’t take long. With proper testing environment, documentation is as simple as two clicks. Without it, manual log search is minutes tops. Not to mention you don’t always need it. Contrary to your experienced belief, sometimes just saying “X doesn’t work” really is enough.

And in case it matters, I do have QA testing experience.

Fair enough, I might have missed that when I hit the comment about players with brain cells making particular choices (“testing for logical valid builds that every player who has a single neuron in their head will select, will in fact not take up much time”), the implication being that other choices aren’t particularly important. Plus I accidentally hit post so I managed to skip ~30-40 replies… :roll_eyes:

Am I? They said that they don’t work in game development (fair, most people don’t) & that their experience/understanding of testing comes from their bf who works in a software company that doesn’t do testing. So surely to then say that “testing stuff is really quick” is a bit of a stretch? It’d be like me saying that heart surgery is really quick & easy 'cause my dad had heart surgery & I had surgery on my collar bone & that didn’t take long.

Closed testing of new characters/skills. Putting a point in a thing & seeing if it does what you’d expect it to. The time consuming part is if it doesn’t, trying to work out what it is doing & why it’s not doing what it should, narrow down the parameters of where it doesn’t work as it should then type it up in a concise manner.

Testing stuff that works is quick, it’s when it doesn’t that it takes time (hence my comment that “X doesn’t work, pls fix k thx bai” won’t cut it).

:+1:t3:

While her chosen wording was pretty bad, she is partially correct.

You don’t test “valid builds” or “most played builds”, but instead you test the new functionality (NF) and retest the critical/core functionality (CF).

Using the recent Warpath change as an example, you should test:

  • NF - that Warpath now hits enemies as soon as the spinning animation comes into contact with their hitbox instead of there being an up to 0.3s delay like before.
  • CF - that Warpath still deals damage, that Warpath echoes still deal damage, that hits still summon Forged Weapons, apply debuffs, proc what they should proc, etc.

That CF example looks like there’s a bunch to test, but if you think about it, you can load any Void Knight save and test all of this in 5 seconds.


Usually there is also a prioritization system behind every test workflow, because you don’t have time to test everything due to lack of money, people, technology (automation), or all of that.

For example, imagine a basic popup window with buttons NEXT, BACK and HELP. We know that:

  • NEXT button is the most used button (70% clicks)
  • BACK is the second most used button (25% clicks)
  • HELP is least used button (5% clicks)

Prioritization says that testing NEXT and BACK button is more important than testing the HELP button. Depending on the context, you may completely skip testing the HELP button simply due to it being a minority case. You could apply this to “most played builds” too (but ideally you shouldn’t).

Similarly, if you make a small change (ie. the NEXT button sends you to a different window) in a future patch, you won’t be testing the HELP button again, because the HELP button has been there for many years and you didn’t touch it in this patch.

So basically yes, sometimes the other choices really are not particularly important.

Yes, you are. Let’s see…

  • You’re assuming that person cannot have knowledge on a subject without current or prior employment in the field.
  • You’re assuming that the software her bf is developing never has any bugs, while she only stated that they don’t do testing. (state of the software her bf is developing is completely irrelevant to the discussion btw., why even bring it up?)
  • And you’re assuming that because your prior experience included cases where writing a bugreport took you a long time, that there can never be a case where writing a bugreport takes a short time.

When I tell a random person to perform a heart surgery, that’ll probably end up very badly.
But when I tell a random person to perform a test of a skill in a game, it’ll probably produce some useful results.

So your heart surgery is “a bit of stretch” :slight_smile:

This random person will also be able to tell me how long it took him to write a report.

PS:

As you go through this sentence, it sounds less and less like QA test, and more like dev work.

The scale comment she made was in regard to my example of how scaling worked incorrectly for Exploding Ballista. She said:

The bold is in the original quote, but this, to me and apparently Llama, is her implying that the way skills scale with stats don’t matter because you can just give the testers cheats. Which is absolutely false.

Regarding your QA testing comments. I completely agree that you don’t need to test all 20k combinations every time. The first time you introduce a skill? Yes, you should test every possible combination and interaction, but that’s not always feasible so you can relegate some interactions as being the same as other skill interactions and assume they will still work here. In regard to situations like the recent Jehlkor’s Blast Knife Detonating Arrow bug where it’s not attaching traps from Explosive Trap. This was functional in 1.0 and is not functional now, but you wouldn’t have tested it because it worked before. I agree you shouldn’t have to retest everything, but this a clear example of something that was working no longer working after a patch that didn’t even touch either the weapon or skill node.

Edit: also I said earlier that I only found one bug with my Necromancer and technically I found two. The first was the Macabre Waltz node where, in specific situations, they’ll sacrifice ranged wraiths. The other is in regard to the Abberant’s Call staff. If you unequip the staff, Summon all of your permanent minions, and then re-equip the staff they won’t start losing 3% of their current HP per second. I haven’t tested if they still get the damage boost though.

That is because minions snapshot. It’s not really a bug. You don’t have the aberrant call, so when you summon them they take the stats of what you’re wearing, meaning they don’t lose the 6% (not 3%) life but they also don’t get the minion damage or the other stats from the staff.

You can also wear gear with full minion stats and lots of +skills, summon your permanent minions and then switch to full gear that has 0 minion stats.

So it’s not a bug, although it’s something the devs will likely want to change in the future. It’s also something that happens in most games.

1 Like

I figured it was a snapshotting issue! Thank you for confirming. It’s definitely something they’d want to fix I’m sure.

1 Like