First Subnautica XB1 patch in testing
Flayra
Game Director, Unknown Worlds EntertainmentSan Francisco Join Date: 2002-01-22 Member: 3Super Administrators, NS2 Developer, Subnautica Developer
Game Director, Unknown Worlds EntertainmentSan Francisco Join Date: 2002-01-22 Member: 3Super Administrators, NS2 Developer, Subnautica Developer
Hey everyone,
Just a quick update. We've gotten our first MEGA patch to Subnautica through Microsoft certification! This is a week-long process, even in Game Preview. We have to apply for a certification window (takes days), send it in, then wait. It's through now, but we want to test it more.
If we're lucky, we will have overall improved the game a lot. But if we've made the performance worse, or introduced some other nasty bugs, we will hold it up again until it's ready to release.
I'm testing it now, fingers crossed...
Just a quick update. We've gotten our first MEGA patch to Subnautica through Microsoft certification! This is a week-long process, even in Game Preview. We have to apply for a certification window (takes days), send it in, then wait. It's through now, but we want to test it more.
If we're lucky, we will have overall improved the game a lot. But if we've made the performance worse, or introduced some other nasty bugs, we will hold it up again until it's ready to release.
I'm testing it now, fingers crossed...
This discussion has been closed.
Comments
He's right you know!
So we're back to fixing those things and will then submit another build to CERT.
Not trying to be rude/snarky/whatever, but I was under the impression you guys were testing the crap out of the patch so that you ironed out major issues like this before sending it off to cert - what happened?
to give them credit I'm sure playing the new version from an Xbox proxy server directly from development is much different that the final product going through all phases of server transmission from Xbox down to console. This is unknown worlds first venture into console gaming and I'm sure there's a few tricks to learn regarding deployment even if it looked good in house before being sent off. Thanks for the hard work
Awwh.
You guys got this. People will be impatient but it's better that you all get it all thoroughly fixed than to cause more issues for yourself. Good luck with the bug hunting
The people that want stuff sooner and get impatient often seem to fail and realize that if they get things sooner, it frequently means more bugs. Do they want it NOW and bug-ridden, or do they want to WAIT and have a higher quality product?
It'll be at least another week or two then, taking cert. into consideration.
Hopefully players will stay relaxed, get some projects done, go socialize with the human race, do something that does not broadcast to the rest of the gaming community that the only thing they got in their life hinges on each update and how fast it gets out so that they can be entertained once again. If anyone thinks this hits too close to home and is angered by my statement, get up from your keyboard right now and instead of typing a response of where I can stick my controller, go tell someone you love, hello and then you will remember oh yeah, I guess I can wait and it's really not that important. I implore my fellow gamers to not be a spoiled Veruca Salt and start making new threads of how dissappointed, angry, or leaving the game forever tantrums in the "don't care how, I want it now!" fits that often result in new unexpected delays.
It wasn't too long ago when updates and patches were only a few Kb or maybe a meg or 2. But I can also remember floppy disc drives and the years before internet.....
How come whenever someone says "not to sound like an ass" it is always followed up with them sounding exactly like an ass?
Do you have any idea how code works? When you change even small things, it can have wide reaching consequences for existing code. Unfortunately, it's quite common not to notice those consequences until it's too late, especially for a game like Subnautica that has so many complex features.
I'm really impatient for the update too, but it's better that it's 100% ready to go before they release it rather than having a ton of issues that need fixing in yet another patch.
Not sure where you got the idea that they somehow shafted console users - sounds like they're doing their best at the moment. Don't forget it's a small team who have never worked with consoles before
I am very familiar with how code works, and I have to disagree with you somewhat. My money is on the cause being drift between the parallel code bases, i.e. the split and eventual merge. Not the changes in and of themselves, which are really not inherently dangerous.
Super simplified example:
Algorithm A is designed to work with Algorithm B and does so damn well
CODEBASES SPLIT
PC - Moves on to use Algorithms C and D which do the same things as A/B in different ways
XB1 - Algorithm E has to be developed to replace Algorithm B, which does not work so well on XB1--but does essentially the same thing and works great with algorithm A
CODEBASES MERGE
Now you have algorithm C working with algorithm E
- They were never designed to work together
- They APPEAR to work because they perform the same basic tasks as algorithms A and B respectively
- However the way they utilize one another causes problems -- performance, stability, who knows?
This is a sort of problem you can realistically expect to happen. There are variations on this scenario--new features added to any particular algorithm etc, but a lot of it will still boil down to the above.
It is very different from the magical coding butterfly effect people are fond of talking about. When a developer is authoring a new change, he is likely to account for the systems that depend on whatever he is working with. Moreover, he will know exactly what characteristics of the code/execution are changing and can/will test those rigorously. This is why in the course of normal development you do not usually see issues like this unless you are dealing with amateur developers who have not yet developed "the sense". Things change when you try to merge parallel projects that have had time to drift. Nobody remembers *precisely* the characteristics of each change, what needs to be verified or tested, how it all relates, etc. Without the laser of focus of the developer at the moment of the code's creation--without the power of "the sense" in full effect--the effort to merge can become a bit... murky? Uncertain? At this point, it can be a bit like someone took two versions of the same book, tore out random pages, partially shredded them, and then asked the authors to reassemble them into a unified book worth publishing. It is not always like this, mind you, but the potential is definitely there. All I can say is... have fun, glad it isn't me, and THANK YOU for doing it!
I am probably totally wrong, but this is my two cents based on my own experience. Progressive changes are generally not a problem, at all, ever. But merging parallel codebases can be a real nightmare.