The character animation in the game is impressive when it works, which it has until recently. The game mechanics are not that tough though, and it sounds like your architecture is a monolithic mess.
Kabam, ask your developers about technical debt, and why it needs to be addressed before the whole system comes crashing down. Alternatively, consider a service-oriented architecture.
So the Kabam MCOC "Sigil Membership" price has not been announced AFAIK. I'd be willing to pay $1 per month. Each new version comes with more bugs, and they just keep getting worse. The Jugs fiasco is the cherry on top. I've developed software and I know it shouldn't be difficult to keep things working if you don't touch unrelated stuff. Any reasonable programmer would know this. And, good software goes through QA to limit the number of bugs that get out. Instead we are left to QA the game. Maybe Kabam should pay us instead!
As an engineer working in a multi billion dollar company, and also a mega whale supporting this game, here’re my two cents:
I agree with the QA part. They either have a flawed QA process or don’t test every hero with new changes. If a change breaks a character, they shouldn’t push the new code or revert it. Either they lack developers or management is broken, affecting developers.
They initially pushed shading problems with characters, indicating their QA wasn’t testing every hero. However, they haven’t changed anything since then, pushing the same issue to additional characters this month.
Spiral whiffing her sp1 is another grave mistake. Engineers should test their features before QA does a thorough test. Neither happened in both situations, leading to this point.
"I developed software"... Well I played soccer in college; but I don't think I can tell Messi how to do his job... OP which multi million dollar earning game have you developed? Maybe we can play it and see that its flawless.
Alot of the bugs that occur in game only occur once it hits the live server after they've tested it extensively.
Since I know nothing about developing software at all, why would the bugs only hit the live server, but not be there during their own testing?
There can be environmental dependencies in development code and in system testing (stage-2) they may rely on mock mechanisms (filling in server related varibles) and those may not be accurate. This can be expected in large projects. However those should be caught in later stages of testing. Here’s a rough recap if you want a read about it: https://reliasoftware.com/blog/levels-of-testing-in-software-testing
On paper, sure. In practice, I know of very few projects actually managed that way successfully, especially large enterprise ones you'd expect to most have the resources and the scope to do it in the first place. See: all health care vertical software, everything ever touched by an Oracle developer, everything Microsoft makes that isn't sold in a box at Best Buy, most pos POS software.
In my experience the real problem in a lot of game development is the fact the software is often layered, with different people working on different layers simultaneously. You have programmers working constantly on the core engine. You have people working on the engine metalayers. And you have people working on the content/data. In a perfect world you wouldn't touch multiple layers simultaneously. You'd make changes to the engine. Then you'd propagate those changes to the meta layer. Then you'd port the data to the new engine. Then you'd repeat. If there is a game studio that does that anywhere in the world, I've never heard of it. The development cycles in games are just too short for that to be practical. So you actually have work being done at all layers simultaneously. That creates a lot of potential for a problem to surface when those layers are merged.
Excellent QA can catch a lot of it, but then you have the last little bit of extra problematic pipeline: it is extremely difficult to do the normal test/dev environment thing when your production environment is in a third party cloud and your clients get pushed through app stores with separate approval timelines. Not impossible, but that's additional time pressure being applied to an otherwise relatively fixed development cycle.
Unity itself, the framework that MCOC is built upon, adds extra complexity because of the way it works. The meta layers in a lot of Unity projects, MCOC definitely included, is not strongly separated from the core engine. But that's a whole different bag of cats.
"I developed software"... Well I played soccer in college; but I don't think I can tell Messi how to do his job... OP which multi million dollar earning game have you developed? Maybe we can play it and see that its flawless.
"I developed software"... Well I played soccer in college; but I don't think I can tell Messi how to do his job... OP which multi million dollar earning game have you developed? Maybe we can play it and see that its flawless.
I never expected cultists here. Sad.
You are not expected or wanted to buy a membership either; but here we are on this crossroad...
Comments
Kabam, ask your developers about technical debt, and why it needs to be addressed before the whole system comes crashing down. Alternatively, consider a service-oriented architecture.
In my experience the real problem in a lot of game development is the fact the software is often layered, with different people working on different layers simultaneously. You have programmers working constantly on the core engine. You have people working on the engine metalayers. And you have people working on the content/data. In a perfect world you wouldn't touch multiple layers simultaneously. You'd make changes to the engine. Then you'd propagate those changes to the meta layer. Then you'd port the data to the new engine. Then you'd repeat. If there is a game studio that does that anywhere in the world, I've never heard of it. The development cycles in games are just too short for that to be practical. So you actually have work being done at all layers simultaneously. That creates a lot of potential for a problem to surface when those layers are merged.
Excellent QA can catch a lot of it, but then you have the last little bit of extra problematic pipeline: it is extremely difficult to do the normal test/dev environment thing when your production environment is in a third party cloud and your clients get pushed through app stores with separate approval timelines. Not impossible, but that's additional time pressure being applied to an otherwise relatively fixed development cycle.
Unity itself, the framework that MCOC is built upon, adds extra complexity because of the way it works. The meta layers in a lot of Unity projects, MCOC definitely included, is not strongly separated from the core engine. But that's a whole different bag of cats.