**Mastery Loadouts**
Due to issues related to the release of Mastery Loadouts, the "free swap" period will be extended.
The new end date will be May 1st.
Due to issues related to the release of Mastery Loadouts, the "free swap" period will be extended.
The new end date will be May 1st.
Comments
Also, I don't use the reaction buttons. I wouldn't click disagree and not say anything. I'd rather respond than use a button.
Every action is a bit delayed.
If you parry a bit earlier than usual, it fits. Same goes for dex block and everything else.
1. Things like well-timed blocks (the mechanical basis behind the parry mechanic) are not expressed directly in code, at least not in the context being discussed here. There's no "well timed block" code that defines parry timing. Blocks are determined by event timing, and well-timed blocks by very small windows of timing built into the attack animations and collision boxes. A well-timed block is in effect an emergent behavior from the interactions between the character animations and the player inputs. Well-timed blocks are defined to occur when certain circumstances are met in the game, but the specific *timing* of when they happen or when they are allowed to happen is due to how the game data interacts with the way the Unity engine processes and manages time. In other words, if well-timed blocks exist anywhere, they exist in the code of Unity (which the developers can't really mess around with) and in the *data* of the game. Not in the code of the game directly.
2. Most of the player-facing functionality in a game like MCOC is built on abstraction layers. The game itself is built upon Unity, a single game engine that is supplied by a vendor (helpfully enough, called Unity). Constructed upon Unity is a game mechanical layer of Unity extensions that modify the game engine in ways that allow Kabam to customize and extend the behavior of Unity to basically make MCOC - this is how everyone does it. Unity is and is not modular; you cannot just rip it apart and keep some parts and modify other parts in isolation. Firstly the vendor won't let you. And even if they would, Unity is a tightly coupled constellation of code blocks that don't work in isolation. This isn't like a menu-driven ATM where each button causes the machine to do a completely different thing. It is more like an operating system where you can upgrade from Windows 10 to Windows 11, but you can't update your Windows 10 network subsystem to the Windows 11 one. The vendor won't let you, and even if they would it wouldn't likely work correctly. So basically, there's no way to silo MCOC "vertically" into functional towers, because it is actually built horizontally, in layers of lasagna noodles.
You could even go so far as to say that the way players normally think about the game in terms of different "parts" or "sections" is almost completely illusory, because while it might look that way to humans, to the extent that the game is modular at all it is modular in a completely different way that you need to be a developer to notice or understand. Parry is a thing to a player. It is a lot of different tiny things scattered throughout the entire system to the game engine that just coincidentally look like a Parry to the player. It is a prediction of a collision of certain kind of state circumstance after an input within a calculated window defined by a movement and animation sequence which generates an activation trigger within the ability initiation resolution system.
3. Most importantly, games like MCOC are generally developed with just-in-time delivery processes. The engine is constantly being modified. The content is constantly being modified. The content being written today must target the engine that is going to be released in four months, because it needs game engine features that are being added today to support the needs of the content being written today. If they did a tick tock development (where the game engine was modified but the content ignored those changes, then after release the content used new engine features but the engine was frozen), they might never be able to ship new content fast enough to support a games as a service game like MCOC. So when the new game comes out, it is running content that needs it. If you revert the game engine due to a bug, which I've already mentioned must happen all or nothing, you'll break a lot of the new content the game just released. This is impractical for a game that relies upon constantly releasing new content. A game as a service that is buggy is crippled. A game as a service that cannot release content consistently is dead.
How do I know any of this? One: I've been involved off and on with game design and development in some capacity for some time, which includes both studying the field as well as having the rubber meet the road by doing professional contract work for a shipping MMO in the past. Two: I've talked to multiple developers in multiple studios working on multiple games, including during the ramp up phase before shipping and during the support phase after release (which are completely different kinds of game development). Three: I talk to the developers of this game, so I know the things I'm aware of that are common in the games industry in general for the most part apply here as well. So none of these things are guesses. I do not, however, have a Youtube channel on coding. That would probably require me to read Youtube comment sections. Pass.
Also, there's a significant risk here because while it might seem like the only thing lost is access to the new content, that's not always the case. For example, there are times where if you're running the older version past a certain date the game servers block you from even logging in. This is probably a safety lock to prevent bad side effects or corruptions from happening due to the client mismatch.