Maybe so. But some of this is also your lack of understanding about how collaborative code projects work and differences between test environments and live servers.
How to plan for a change to the jump animation: a deeper look into a software company with 20 years of experience.
step 1: “how long does a jump last on TQ?”, some basic testing or checking of server stats gives the answer
step 2: “hey animator, your cool new animation should be this long but not longer!”
The end.
This was a very amateuristic update. You’re defending a really easily preventable problem for reasons I don’t understand and quite frankly don’t care for.
Not sure I have seen a game cause as much tears as Eve updates
So… let’s imagine it’s between 1 second and 60.
Because I’ve had nearly that whole range myself.
Do you now start to understand why you are taking an unrealistically simplistic look at it?
Holy ■■■■.
- They KNOW the length of their old jump animation, that one works fine and has worked fine for many years
- therefore they KNOW the length of the NEW jump animation: EXACTLY THE SAME LENGTH
How much of a muppet are you? Wait, don’t answer that, it’s almost as if you’re a DEV yourself. You surely follow similar logic.
In a well run development shop, you have a minimum of three environments: DEV, QA, and PROD
- DEV where actual development/tweaking of code takes place - you might have ‘partial’ builds of things in flight alongside your almost-ready-to-launch code, because you are working on multiple efforts at once.
- QA is where the completed software package for your update is installed in an environment that perfectly mirrors PROD except for the new code - after every successful install, re-mirror codebase from PROD to QA to ensure there are no discrepancies.
- PROD - aka your live, production environment that end users access. This should only receive code updates that have been thoroughly vetted in QA.
Some shops have reason for a stage between QA and PROD for UAT (user acceptance testing) - which would be SiSi for EVE, where you get a bunch of end-users to stress-test the code and identify ways in which the intended behaviors have unintended consequences.
Nothing should be different code-wise or infrastructure-wise between QA, UAT, and PROD environments - barring a reduced resource allocation for QA/UAT when you are not doing load testing. They should run on the same server software, same database infrastructure, etc.
Doing anything else is asking for messes.
1 Like
That’s a nice theory.
But in reality when your prod environment is an experimental level of large tech like TQ3 your QA environment is always going to be different.
It’s not the same scale, it’s not the same active loading, it’s probably not even the same server tech. Sure it will run on the same system… But yeah…
You see this an example of “overdemocracy”. They think they have their finger on the pulse of the players because of the CSM. But thanks to have a CSM, you have a situation where assumptions get made about what the players want while believing that they are represented (by the CSM).
All it would have taken was …sit down before you read this… asking the players. Not, not the “representatives”. The actual people who have to use these features.
I know that’s really hard these days. People are scary.
1 Like
Amen. There is the lesson and the answer.
1 Like
I happen to like the animation. That said, I don’t like the consequences. Hopefully they’ll fix. 
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.