"The tall red boxes are standing cover (otherwise known as “full” cover, providing the most protection) and the smaller pink boxes are low cover (half-cover in-game). The yellow targets on each cover node show which angles a soldier can shoot from when placed in that cover node. The yellow curved arrows above some of the low cover nodes show that a soldier can vault over the cover node into a node on the adjacent side. Careful placement of cover nodes and strict adherence to the metrics is essential to create a clean, bug-free cover setup that works as players expect it to. If a piece of cover is too high then you will not be able to vault over it, and if a cover node isn’t placed correctly at a corner then the soldier occupying that node will be unable to shoot around the corner. Both of these examples create frustration for the player and must be avoided!"
We released [...] a fix for the dreaded "the game thinks my companions are dead" bug, which I believe I spent more time investigating than I have for any other individual bug in my career.The gist of the bug was that, for some players, a companion quest would be marked as Failed in the quest log, with the reasoning that the companion was dead -- despite the fact that the companion was very much alive and well. One reason it was so hard to pin down is that it was impossible to tell when the bug actually happened -- all of the cases we had were essentially "hey something bad happened in the last ten hours and now my quest is broken".Investigating it involved figuring out the location of every script and line of code that could possibly make the game think that a companion was dead. The only logical culprit was a bit of scripting that runs when a companion's health reaches zero: if they're in the party, it waits for combat to end and revives them; otherwise it marks them as dead "for real". [But] the only place in the game when a companion is present but not in the active party is when the player is on their ship. The problem is, when companions are on the ship, they are undamageable. Eventually we figured out that "undamageable" does not mean "invulnerable" -- they can't take damage from attacks but can still get hurt from other things. One of those things: falling a great distance.The problem with that is that there are no spots in the player's ship that are high enough to result in a lethal fall. So now we had to figure out how companions were mysteriously ending up way above the level. I looked into tons of theories, including "maybe their height data is preserved when fast travelling from other maps" and "maybe a physics interaction between two companions causes one to rapidly accelerate upwards". (My personal fav was "what if a companion is standing right where a cow spawns in during a random event and they're launched into space". Was genuinely bummed when that theory didn't pan out.) By this time, the game had come out, and all hopes of this being a weird fluke only a couple devs would ever see were dashed, as players all over the place started reporting their companion quests failing.Eventually, an offhand comment in one user's review mentioned seeing a weird bug where a companion was "climbing nothing", and this comment led me to figuring the whole thing out.On the dev side of things, the system for NPCs interacting with the environment is called "furniture". Sometimes this is literal furniture, like sitting in a chair, but it covers everything from using a terminal to leaning on a wall. Somewhere deep in the complex beast that is the furniture system, we had code that disabled all NPCs from starting new furniture interactions if the player was in a conversation.The problem was that using a ladder is considered two different furniture interactions: one for getting on the ladder and starting to climb, and one to stop climbing and get off. So, if someone started climbing a ladder and the player entered a conversation before they stopped, they wouldn't be able to exit the ladder, and, well…. -- Taylor Swope (@_taylorswope) https://twitter.com/_taylorswope/status/1205252714680045568
how to code a ceiling fanis vague in the worst way (which code language?) and specific in the worst way (you're hoping someone else has specifically built a virtual ceiling fan)
"unity" "c#" spinning object codeis technically specific (we only want Unity C# code) and helpfully generalizing (a ceiling fan is a type of spinning thing) and we can extrapolate from the generic example for our specific use case
game dev scripting objectives systemwill maybe tell you someone's opinion about how to architect an objectives system, but without any specific help. What type of game objective do you want to script, exactly? No search engine can design your gameplay for you.
"ue4" "blueprint" display text on screenhelps us figure out how to notify the player about an objective
"ue4" "blueprint" player enters triggerhelps us learn how to detect when the objective is completed, when the player has reached a certain location in the level, etc.