errorcraft - Tumblr blog

[errorcraft]

It Turns Out That...

... Global prompts have not been working on console for some time.

OOPS! But at the same time, this is fortunate because I need to change the way that global prompts work anyways!

I’m trying to make them more robust, because the way they are now only lets us use preset strings from a specific translation group in the database. I need to be able to dynamically append values for one of the global prompts, and coworkers have been asking for a way to do this for regular prompts recently as well.

GLOSSARY

Button Prompt: A display that shows a controller button and a brief description of what action that button currently does. Used mostly for menus

Global Prompts: Button prompts that display at the bottom of the screen that should be present in most, if not all, screens. Typically things like Party, Friends, and Options should show here

[errorcraft]

Zombie Code

You may hear me complain from time to time about “Zombie Code.” It sounds super badass, right? Could I be fighting off undead remnants of old, forgotten features? Or maybe fending off hordes of vicious, hungry bits seeking a nibble.

If only it were that badass. Unfortunately, Zombie Code is a term I coined for code created by a company whose name formerly was involved the word Zombie; a company my employer had previously outsourced some work to. Zombie code is objectively, technically, and unequivocally… Absolute Putrefied Garbage.

That’s the technical term, I swear!

“Ok, so… What’s so bad about it?”…

… I bet you’re wondering.

Well, let’s just say you want to tie your shoes. Most people would thread the laces evenly back and forth through the brim of the shoe over the tongue, right? Then cross and knot at the top for security. Each piece has it’s set duty and is used as intended.

But then a zombie tries to tie their shoe, and between a lack of dexterity and functioning understanding of the meaning of love, they somehow end up with the laces winding through all of existence. Some go over the tongue, most go under it. There’s a portion of the lace that goes around their ankle and under the heel. At some point their sleeve got roped into the mess.

Here’s an artist’s interpretation of the above visual:

It just looks like a mess. Threads everywhere, I don’t know who gave them a lace long enough to make all of those loops and knots. I’m not even sure which knot’s not knotted correctly.

Seriously though, what we’re looking at is a dependency graph of different UI elements in an in-match game info screen. There’s a ton going on, but I want to make a few key notes plus add some info on what the dependencies are:

There’s a View Container, but it does nothing. It simply exists to hold the children

The Scoreboard sub-view controls most of this scene, including navigating between it and its siblings, handling input on all sub-views, and managing the navigation bar state.

There are a ton of calls to global data and the managing C++ layer. This is especially painful for things closer to the bottom, because they’re furthest from where they can access C++ and have to do so through a direct call to the parent element. (EWWW)

The player, mute button, team, AND scoreboard all make global and C++ calls. Many for the same event- a button press to view a player’s profile, for instance

Teams reference eachother directly and interfere with eachother’s input handling based on the parent’s state

The player object is a bar that can be focused, but it relies on the mute button to take focus, then deletes all of the mute button’s input handling so it can take priority: all despite our APIs having more natural means to do so.

All-in-all, this is super gross. It’s difficult to tell where something is happening when you need to fix a bug, and what might break if you change anything.

How It Should Be

After laboring over this mental death trap, I managed to organize things much more reasonably. It’s by no means perfect, but is a much better solution in my opinion.

TA-DA!

Vastly easier to follow!

In short, I gave life to the View Container, and followed a pattern of having the parent manage its children by listening to their dispatched events, and most elements are fairly self-contained. This way, you can easily find where interactions occur and know exactly who should reference what. It’s also amazing for long-term maintenance due to the ease of swapping out one element for another, so long as the new one dispatches the same events.

I also made the dummy mute button handle NOTHING, it exists purely for visual feedback on selection state, but Player can now be focused without focusing the mute button, so it just sets the display state when focus is gained.

Unfortunately because of how we currently handle player actions, the player button still needs to call some global scripts directly for some of its actions, like mute, view profile, block, etc... BUT now those are all in one place, and we can easily assume that player would handle that, anyways.

Sounds Like a Pain

YEAH!!!... IT IS!

Even better is that the company who did this has done too much work on our game. There are tons of scenes similar to this one, most of which are worse.

Fixing bugs in Zombie code is an uphill battle. Most of the time the bug is the ENTIRE code base for a feature. Unfortunately, because they’re so large and spread, and we’re always cranking out new content, we never have time to fix any of them. It’s not unusual for a new feature to be canned because it would be too difficult to work into this code.

Please, please, PLEASE take this to heart. Don’t write Zombie Code. Organize your logic, hold yourself and your coworkers to standards... It might take longer initially until you get a rhythm...

... But in the long run you’ll lose fewer computers to fits of explosive rage.

[errorcraft]

Hello_Space

As a first post I thought I’d introduce myself.

I’m Error_Craft, a recently-professional video game programmer (For almost a year now?) and complete nerd.

At the moment I’m a UI/UX programmer for a moderately popular MOBA, working in C++, ActionScript, UnrealScript, and SQL. On the side, I’m developing my own games in C# on Xenko.

I thought I’d make a new blog for my more... professional pieces, and also as a sort-of confession blog for all of the glorious Errors I introduce to the games I work on!

If you’re interested in the high-level goings-on in video game development, please give me a follow. Nothing too low, because NDA and such... Any fellow game devs I will likely follow back, so please hit me up!