Don't Build Login Forms

How many times have you logged into a website? If I asked you to think of what a login form has on it, you probably have a pretty good sense of this:

• Username
• Password
• Submit

Every SaaS website in the world needs one of these, and over time we slowly started adding more functionality to the humble login page. We added a forgot password link. We added a Captcha option. We added OKTA, SSO, Show Password, Password Hints, Login with Google.

The Instagram Problem

All of those things are, more or less, easy for a Backend Engineer to implement. When Instagram was getting pitched no one spent very much time talking about how people would log in to it, because it’s a solved problem. But then someone had to sit down and actually write it.

This wasn’t a complicated task. Someone did it, they pulled in a UX designer to figure out how to plug it into a site. They looked up the best way to add a salt to your password so you don’t store it in plaintext, because they couldn’t remember EXACTLY how to implement it, but they’re a smart engineer working for Instagram so they figured it out. Then Instagram went on and did everything else.

But Instagram didn’t roll the only login page. Facebook needed one. So did Google and Intuit and DeviantArt and Riot and Battle.net, etc etc. But a Login page is easy, so they just made one. It took everyone a week or two to re-implement the exact same thing, every time.

The Video Game Settings Page

You’re going to need a settings page. You’re going to implement it, and you’re going to occasionally add stuff to it, and when you set it up you’re going to have to re-remember a bunch of things that you never really retain because you only set up a settings page once per project.

“How do I make sure I gracefully freeze and unfreeze the whole game again? I need to go re-watch that 10 minute video on how to blur out the background behind my Options menu.”

What Am I Getting At?

UI Implementation is easy to talk about because the problem space resonates well. A lot of these problems are solved problems. Doing INVENTIVE UX is a totally different thing but I’m talking about the Path of Exile settings screen. About Counterstrike’s Server Selection Screen or Valheim’s Character Select. These are screens that get the job done that just need to get implemented in order to get the game out the door.

In today’s modern game engines, this SHOULD be trivial. This CAN be trivial. Both the Unity and Unreal asset stores have these as options you can download and install for about $20 each. The issue in all these cases is there are almost no standards, and too much choice.

The Open Source Mindset

At Manafold we think using an Open Source mindset to implement solved problems is the key to many of the games industry’s problems. By creating a modular set of UI, added when a game is generated with the click of a few buttons, we believe that we can let the implementation teams save that time and focus instead on building out the core functionality they’re excited about.

This might not seem like a lot, but when you’re a new team bootstrapping a game from nothing, the cognitive load that you’re under is extreme, and if you can table problems indefinitely it lets you save that mental space for other problems. This particular example also helps solve strange pipeline problems that occur as now you can begin working with a UI artist to art-ify all of your UI starting on day 1 of your project.

We don’t think this problem exists just for UI, but we want our implementation teams to be able to find the fun quickly, and not spend their time reinventing the wheel. We don’t want ANY game team to have to reinvent the wheel, so our goal is to build the Login Form once, share it with the world, and let the artistic expression come through in other ways.