Me personally I think the input issues are coming from kabam changing the AI profiles per difficulty like in AW or thronbreaker event contest with 7stars. I believe they speed up the AI as well as they allow the AI to hit you for instance with hit like a heavy or special by making them step towards you more drastically to be able to hit you. Or the AI knowing your next input like you about to release a block and it hits immediately after, or you dashing forward and it intercepts you. I think that's causing issues in the game because ive use 4 different phones ios and android and it's worst now since this months update then the last 3 months. I also wonder do the dev team play the gamw on a regular basis? If so I'm pretty confident they would understand the issues we are getting. If they don't have someone who's playing the game on a regular basis I would prob say that may be something to look into and maybe that would alleviate most of the confusion.
So you stop getting info that you need and instead of making something interesting for players, you just threw us into the control issues hell? Why not make some rewards for "bug hunters"? For example, you get helpful info about bug (with descriptions you need and video with recording taps and swipes) and give player for that titles or profile pic or tokens that can be exchanged for some gold or iso maybe? Why you want to get required info from players suffering?
Good point, you’d think the “cost associated to experiencing this bug” might be if interest to the team too, but that’s left out as well.
Also, why would the input reactor effect champs months down the road? That doesn’t make sense with what we’ve been told either
The "input system refactor" is a bit of a misnomer. It technically describes what was done, but it doesn't properly evoke the scale and scope of what that means if you don't understand how input systems work in game engines. If I said that what they needed to do after the Unity engine update that changed the behavior of iOS timestep calculations as "changing how the game processes the timing of all events relative to how players interact with the game" I think that would better describe the scope of the change to the game.
The engine update altered how the game processes time. This altered the precise moments when things designed to happen in specific time sequences occurred. This caused the relationship between when inputs were processed as happening in the engine relative to when internal events were sequenced to occur. This caused problems ranging from inputs registering at different frames relative to animations (which would cause time-sensitive events like Parry from not occurring) to inputs not registering at all because they occurred during windows where such actions are forbidden, even though the animations would visually suggest they were allowed, to inputs being processed differently because input queues now behaved differently, to effects interacting in different ways independent of inputs because their relative timing was now shifted, which then meant future inputs would not generate the behavior that was originally intended or expected.
What changed was not something like the game needed to process taps and swipes differently. What happened was the game's sense of time changed, and with that everything that depends on time also changed. Which is potentially: everything. Not only everything that exists now, but things designed in the future that use the same design rules that worked in the past might break in weird ways that didn't happen before, but now can happen.
What makes this a lot more complex than people think is that we experience time continuously but the game experiences time discretely, in ticks of the clock. Everything that happens 0.5 seconds later and 0.533 seconds later happens at the exact same moment to the game engine (15 frames later). Assuming game frames are being processed *exactly* when they should, which in practice never happens. So sometimes frame 15 happens 0.5 seconds later and sometimes 0.501 seconds later. When that happens, the event that is supposed to happen 0.5 seconds later and the event that is supposed to happen 0.51 seconds later no longer happen in the same frame. Or maybe they do because the game engine tries to compensate for this. Honestly, I've seen Unity documentation go both ways here.
Most games do not need to care about this kind of stuff, because precise timing doesn't really affect them. Whether something happens now or one frame later will not do something that a player will notice in an FPS shooter or a side scroller. It is only games that require this event to happen at the exact same time as that event that will be affected in a noticeable way. MCOC happens to be one of those games.
Also, why would the input reactor effect champs months down the road? That doesn’t make sense with what we’ve been told either
The "input system refactor" is a bit of a misnomer. It technically describes what was done, but it doesn't properly evoke the scale and scope of what that means if you don't understand how input systems work in game engines. If I said that what they needed to do after the Unity engine update that changed the behavior of iOS timestep calculations as "changing how the game processes the timing of all events relative to how players interact with the game" I think that would better describe the scope of the change to the game.
The engine update altered how the game processes time. This altered the precise moments when things designed to happen in specific time sequences occurred. This caused the relationship between when inputs were processed as happening in the engine relative to when internal events were sequenced to occur. This caused problems ranging from inputs registering at different frames relative to animations (which would cause time-sensitive events like Parry from not occurring) to inputs not registering at all because they occurred during windows where such actions are forbidden, even though the animations would visually suggest they were allowed, to inputs being processed differently because input queues now behaved differently, to effects interacting in different ways independent of inputs because their relative timing was now shifted, which then meant future inputs would not generate the behavior that was originally intended or expected.
What changed was not something like the game needed to process taps and swipes differently. What happened was the game's sense of time changed, and with that everything that depends on time also changed. Which is potentially: everything. Not only everything that exists now, but things designed in the future that use the same design rules that worked in the past might break in weird ways that didn't happen before, but now can happen.
What makes this a lot more complex than people think is that we experience time continuously but the game experiences time discretely, in ticks of the clock. Everything that happens 0.5 seconds later and 0.533 seconds later happens at the exact same moment to the game engine (15 frames later). Assuming game frames are being processed *exactly* when they should, which in practice never happens. So sometimes frame 15 happens 0.5 seconds later and sometimes 0.501 seconds later. When that happens, the event that is supposed to happen 0.5 seconds later and the event that is supposed to happen 0.51 seconds later no longer happen in the same frame. Or maybe they do because the game engine tries to compensate for this. Honestly, I've seen Unity documentation go both ways here.
Most games do not need to care about this kind of stuff, because precise timing doesn't really affect them. Whether something happens now or one frame later will not do something that a player will notice in an FPS shooter or a side scroller. It is only games that require this event to happen at the exact same time as that event that will be affected in a noticeable way. MCOC happens to be one of those games.
I appreciate the thorough response but a year later why are things getting worse not better?
Also, why would the input reactor effect champs months down the road? That doesn’t make sense with what we’ve been told either
The "input system refactor" is a bit of a misnomer. It technically describes what was done, but it doesn't properly evoke the scale and scope of what that means if you don't understand how input systems work in game engines. If I said that what they needed to do after the Unity engine update that changed the behavior of iOS timestep calculations as "changing how the game processes the timing of all events relative to how players interact with the game" I think that would better describe the scope of the change to the game.
The engine update altered how the game processes time. This altered the precise moments when things designed to happen in specific time sequences occurred. This caused the relationship between when inputs were processed as happening in the engine relative to when internal events were sequenced to occur. This caused problems ranging from inputs registering at different frames relative to animations (which would cause time-sensitive events like Parry from not occurring) to inputs not registering at all because they occurred during windows where such actions are forbidden, even though the animations would visually suggest they were allowed, to inputs being processed differently because input queues now behaved differently, to effects interacting in different ways independent of inputs because their relative timing was now shifted, which then meant future inputs would not generate the behavior that was originally intended or expected.
What changed was not something like the game needed to process taps and swipes differently. What happened was the game's sense of time changed, and with that everything that depends on time also changed. Which is potentially: everything. Not only everything that exists now, but things designed in the future that use the same design rules that worked in the past might break in weird ways that didn't happen before, but now can happen.
What makes this a lot more complex than people think is that we experience time continuously but the game experiences time discretely, in ticks of the clock. Everything that happens 0.5 seconds later and 0.533 seconds later happens at the exact same moment to the game engine (15 frames later). Assuming game frames are being processed *exactly* when they should, which in practice never happens. So sometimes frame 15 happens 0.5 seconds later and sometimes 0.501 seconds later. When that happens, the event that is supposed to happen 0.5 seconds later and the event that is supposed to happen 0.51 seconds later no longer happen in the same frame. Or maybe they do because the game engine tries to compensate for this. Honestly, I've seen Unity documentation go both ways here.
Most games do not need to care about this kind of stuff, because precise timing doesn't really affect them. Whether something happens now or one frame later will not do something that a player will notice in an FPS shooter or a side scroller. It is only games that require this event to happen at the exact same time as that event that will be affected in a noticeable way. MCOC happens to be one of those games.
I appreciate the thorough response but a year later why are things getting worse not better?
I haven't personally noticed them getting worse. It seems that different players see different things. But to the extent that people have been seeing things apparently getting worse, Kabam is clearly still refining the system. Presumably those refinements are changing things in ways that players are noticing as regression problems, or as different problems that just seem to be a recurrence of the same problem.
It is also possible that besides the game engine changing and the data changing, the design rules of thumb themselves have to change with the new systems. In the same way players have to fight muscle memory when the game changes behavior, devs have to change their rules of thumb for how to make things or change things or adjust things. Those design rules may not have fully adapted to the new game engine behavior, so sometimes we see regressions.
I guess the question I would ask is can the newer system be tuned more to what was more accustomed to?
From what I understand, only to a point, but not perfectly. I wouldn't take this literally, but sometimes the old engine made "mistakes" in our favor, generating behavior we grew accustomed to. The new engine cannot replicate that behavior not because it was "wrong" but rather because it wasn't deterministic. The old engine would do this in this circumstance and that in other circumstances. The new engine can only do one or the other, without putting so many exceptions into the engine that it would collapse under the weight of the extra complexity. The old engine didn't have two behaviors because it was more complex, but because the engine didn't behave consistently across all circumstances. It only behaved consistently to the players, because the players learned how it behaved in every circumstance.
To the players, every situation is unique. But to the game engine, there's only one situation with a few variables. When it starts behaving differently based on situation when no code tells it to do that the players learn how the game works in a way a new engine cannot replicate.
One of the most famous examples in video game history of a behavior players just assumed happened by design but was actually originally a circumstantial inconsistency (which was exploited by the game designers during implementation) was the behavior of the alien invaders in the classic Space Invaders game. In Space Invaders, the more enemies you kill the faster the remaining ones attack you. Everyone assumed this was programmed deliberately, to make the game increasingly fast paced as it went along. As it turns out, that wasn't an original intent of the game programmers. Instead, the problem was the game hardware was so underpowered that it literally took longer to draw the alien ships than it took to refresh the screen, so when there were a lot of alien ships they moved slower on screen because that was as fast as the hardware could draw them. But as the player killed them, the number of aliens the hardware had to draw dropped, and it could draw them faster, and so they moved faster on the screen. During development the creators of Space Invaders decided to exploit this behavior rather than try to fix it, and the rest is history.
You can stare at the code of Space Invaders all day and not see the speed ramp up, because it doesn't exist (well, technically it exists in the sound synchronization code for the game). One of the most famous aspects of the game, a feature that is often credited with *inventing* the game design idea of difficulty ramp up in video games, was a side effect of the hardware being too slow to run the game properly. Today we can reproduce that behavior exactly with modern computer hardware, but at the time this would have been difficult to reproduce *exactly* because Space Invaders itself wasn't doing it deliberately.
@DNA3000 again, thanks for weighing in, at the end of the day, if they knew that this was the case and that we as players would have to trouble shoot all this… my position remains unchanged. The bug report has a glaring hole it in regards to the cost of the bug to the player, and if what you hypothesize is true then it’s poor form that compensation for the input/timing issues was ceased.
@DNA3000 again, thanks for weighing in, at the end of the day, if they knew that this was the case and that we as players would have to trouble shoot all this… my position remains unchanged. The bug report has a glaring hole it in regards to the cost of the bug to the player, and if what you hypothesize is true then it’s poor form that compensation for the input/timing issues was ceased.
I get it. In fact, I've been working on a post detailing my position on the true cost of the input system issues. There's one problem that affects me personally and I suspect affects many players, but it isn't discussed directly often, and isn't one that is fixable by just tweaking the new systems.
@DNA3000 again, thanks for weighing in, at the end of the day, if they knew that this was the case and that we as players would have to trouble shoot all this… my position remains unchanged. The bug report has a glaring hole it in regards to the cost of the bug to the player, and if what you hypothesize is true then it’s poor form that compensation for the input/timing issues was ceased.
I get it. In fact, I've been working on a post detailing my position on the true cost of the input system issues. There's one problem that affects me personally and I suspect affects many players, but it isn't discussed directly often, and isn't one that is fixable by just tweaking the new systems.
Ok thanks for the great explanation. It's better than the scripted "restart your device" by the support team. I hope these issues can be resolved.
In the meantime, these issues are currently still affecting players and causing unecessary losses, especially in competitive parts of the game. This can also cause a drop in rankings.
So what are players to do Kabam? Do we keep spending money and units on revives and health pots to get through fights with confirmed bugs and issues, or do we quit playing the game?
What do you want us to do? Because I'd like for y'all to help us out here by compensating us some free, generous amount of progression based revives and health pots for dealing with these issues all these years.
I said it last year, and I ll say it again: if they started making their system and AI programming from scratch, 2 years ago, now we will have a nice running game, without 90% of the players complaining, without all this frustration, and without kabam employees having to deal with us, and trying to fix the unfixable.
I said it last year, and I ll say it again: if they started making their system and AI programming from scratch, 2 years ago, now we will have a nice running game, without 90% of the players complaining, without all this frustration, and without kabam employees having to deal with us, and trying to fix the unfixable.
That is in effect what they are doing. The problem is that the new input system has an extra burden you don't list: matching the expectations of the existing players. If they started literally from scratch, with a new game engine with new input system and new data and new players almost all these problems would be gone. Because the new players would only have known the new systems, and have nothing to compare them to.
We will always be the last legacy system that doesn't match the rest of the game.
I get used to changes in timing, but now system defines action and reacting wrongly. Maybe some methods or events may not had time or info to properly respond. It happens when i try to dex while blocking. Main question - what's next? Like they said last time: "avoid hard content"? Or we can get back button to turn this off and team will find another way to communicate with us for bug info?
I said it last year, and I ll say it again: if they started making their system and AI programming from scratch, 2 years ago, now we will have a nice running game, without 90% of the players complaining, without all this frustration, and without kabam employees having to deal with us, and trying to fix the unfixable.
That is in effect what they are doing. The problem is that the new input system has an extra burden you don't list: matching the expectations of the existing players. If they started literally from scratch, with a new game engine with new input system and new data and new players almost all these problems would be gone. Because the new players would only have known the new systems, and have nothing to compare them to.
We will always be the last legacy system that doesn't match the rest of the game.
I think if a completely new system appears, free of bugs etc, people will eventually be happy after spending some time learning it. After we learn the new time/screen reactions etc, we ll be able to play smoothly at last, and everyone will be happy in the end. It will be like learning 250 Quicksilvers
Kabam employees, do you even play this game? If so, do you never encounter bugs such as these?? You're asking us to record and send you videos, but even playing for 10 mins you will face them, because every mode is full of lag, weird and jacked up AI, parry dex issues and so on, even fricking Arena, lol... And what about Battlegrounds? At this point i don't even care about modders (haven't met that many, i'm just thronebreaker..), because so many times the game is just unplayable... i have lost so many Bg matches because of bugs, but i also won some due to them A few days ago i submitted a ticket asking about the status of Season 5 compensation, and they requested proof, LOL!! What do you really want from us?? To record hundreds of fights and send them all?
New aw season is coming up and inputs are still horrible. When we can expect any updates on situation? It will be nice to know if i need to look for lower tier alliance
Comments
The engine update altered how the game processes time. This altered the precise moments when things designed to happen in specific time sequences occurred. This caused the relationship between when inputs were processed as happening in the engine relative to when internal events were sequenced to occur. This caused problems ranging from inputs registering at different frames relative to animations (which would cause time-sensitive events like Parry from not occurring) to inputs not registering at all because they occurred during windows where such actions are forbidden, even though the animations would visually suggest they were allowed, to inputs being processed differently because input queues now behaved differently, to effects interacting in different ways independent of inputs because their relative timing was now shifted, which then meant future inputs would not generate the behavior that was originally intended or expected.
What changed was not something like the game needed to process taps and swipes differently. What happened was the game's sense of time changed, and with that everything that depends on time also changed. Which is potentially: everything. Not only everything that exists now, but things designed in the future that use the same design rules that worked in the past might break in weird ways that didn't happen before, but now can happen.
What makes this a lot more complex than people think is that we experience time continuously but the game experiences time discretely, in ticks of the clock. Everything that happens 0.5 seconds later and 0.533 seconds later happens at the exact same moment to the game engine (15 frames later). Assuming game frames are being processed *exactly* when they should, which in practice never happens. So sometimes frame 15 happens 0.5 seconds later and sometimes 0.501 seconds later. When that happens, the event that is supposed to happen 0.5 seconds later and the event that is supposed to happen 0.51 seconds later no longer happen in the same frame. Or maybe they do because the game engine tries to compensate for this. Honestly, I've seen Unity documentation go both ways here.
Most games do not need to care about this kind of stuff, because precise timing doesn't really affect them. Whether something happens now or one frame later will not do something that a player will notice in an FPS shooter or a side scroller. It is only games that require this event to happen at the exact same time as that event that will be affected in a noticeable way. MCOC happens to be one of those games.
It is also possible that besides the game engine changing and the data changing, the design rules of thumb themselves have to change with the new systems. In the same way players have to fight muscle memory when the game changes behavior, devs have to change their rules of thumb for how to make things or change things or adjust things. Those design rules may not have fully adapted to the new game engine behavior, so sometimes we see regressions.
To the players, every situation is unique. But to the game engine, there's only one situation with a few variables. When it starts behaving differently based on situation when no code tells it to do that the players learn how the game works in a way a new engine cannot replicate.
One of the most famous examples in video game history of a behavior players just assumed happened by design but was actually originally a circumstantial inconsistency (which was exploited by the game designers during implementation) was the behavior of the alien invaders in the classic Space Invaders game. In Space Invaders, the more enemies you kill the faster the remaining ones attack you. Everyone assumed this was programmed deliberately, to make the game increasingly fast paced as it went along. As it turns out, that wasn't an original intent of the game programmers. Instead, the problem was the game hardware was so underpowered that it literally took longer to draw the alien ships than it took to refresh the screen, so when there were a lot of alien ships they moved slower on screen because that was as fast as the hardware could draw them. But as the player killed them, the number of aliens the hardware had to draw dropped, and it could draw them faster, and so they moved faster on the screen. During development the creators of Space Invaders decided to exploit this behavior rather than try to fix it, and the rest is history.
You can stare at the code of Space Invaders all day and not see the speed ramp up, because it doesn't exist (well, technically it exists in the sound synchronization code for the game). One of the most famous aspects of the game, a feature that is often credited with *inventing* the game design idea of difficulty ramp up in video games, was a side effect of the hardware being too slow to run the game properly. Today we can reproduce that behavior exactly with modern computer hardware, but at the time this would have been difficult to reproduce *exactly* because Space Invaders itself wasn't doing it deliberately.
But that's probably a Monday thing.
The AI detects and immediately chases evades now.
I noticed this as means of the AI to throw specials, effectively trapping the player.
But now this is happening on basic attacks.
Had Iron Fist in AQ just beat me using this technique.
I think the players notice this because the game is already a game of inches in which we are required to play at such a high level.
Please stop “improving” AI for your benefit.
No one but the ai can chain heavy and sp without a second of recovery…but of course the AI were not improved…
In the meantime, these issues are currently still affecting players and causing unecessary losses, especially in competitive parts of the game. This can also cause a drop in rankings.
So what are players to do Kabam? Do we keep spending money and units on revives and health pots to get through fights with confirmed bugs and issues, or do we quit playing the game?
What do you want us to do? Because I'd like for y'all to help us out here by compensating us some free, generous amount of progression based revives and health pots for dealing with these issues all these years.
That's only fair.
Please increase the evade window!
I get it, your AI wants 7 evades now instead of 5.
I just can’t keep up.
We will always be the last legacy system that doesn't match the rest of the game.
It will be like learning 250 Quicksilvers
You're asking us to record and send you videos, but even playing for 10 mins you will face them, because every mode is full of lag, weird and jacked up AI, parry dex issues and so on, even fricking Arena, lol...
And what about Battlegrounds? At this point i don't even care about modders (haven't met that many, i'm just thronebreaker..), because so many times the game is just unplayable... i have lost so many Bg matches because of bugs, but i also won some due to them
A few days ago i submitted a ticket asking about the status of Season 5 compensation, and they requested proof, LOL!!
What do you really want from us?? To record hundreds of fights and send them all?