kbrecordzz
Home - About - Contact - Overview - Resources
Great user design is when there's no user design at all. Any user interface (buttons, menus or whatever) is one step too much between the user's wish and a result. Earlier I talked about making games that start fast, and I think the programmer John Carmack said something like (can't find the quote!) "In the end, they wanted to play a game and you made them wait" about adding loading screens while you wait for a game to start instead of just starting the game faster, and about user interfaces I want to say "In the end, they wanted to do something and you made them take some unnecessary steps to get there". A user should never have to figure out which key to press when they start playing a game. You should be able to predict what they probably want to do and which keys their fingers probably hover above, and remove the steps between their wish and the result.
But that's easier said than done at a place called The Internet, which is where I'm publishing my game (the link is to a demo, or if you're from the future maybe to a finished game?)! First of all, people are different. Second, things change all the time. Third, France has their own weird "AZERTY" keyboards for some reason. Fourth, this list can go on until the end of numbers. Predicting what people want and where their fingers are is hard when the system they use is built to be unpredictable. A Game Boy Advance on the other hand has only six buttons and a navigation pad and you know they'll press "A" or use the navigation pad if they don't have any better idea, so if you're smart you assign the game's main actions to these buttons, and the player can start playing without wasting brain power. Game Boy Advance is good user design, you insert a game, start the console and then you're inside the game. There's almost nothing between your wish (to play the game) and that wish being fulfilled (you playing the game). It's everything the internet is not, and it's everything I want the internet to be. So, my plan is to design my game so it gives you the same feeling as when you pick up your old Game Boy Advance, turn it on and know it will work exactly like it always has - clean, distraction-free and bug-free - even if it's been in your drawer the last 20 years.
Why am I making a game for the web? Because 1: The web browser is the universal interface, it's what everyone uses, and 2: You can start playing instantly (who wants to download and install stuff?). The problem is that the web is an annoying place where it's standard to ask users for stuff all the time. While consoles are nice because they give you what you want and don't ask you for anything. That last part (give the user what they want and don't ask them for anything) is in my eyes the perfect user design, and what I want to recreate on the internet. This kind of uncompromising user-focus is rare on the web, especially in the web game community (they don't dislike semi-unethical user monetizing), and since I'm not only trying to release a cool game but also inspire the whole game development community, I have lots of work to do. But I have a plan, and the most important part of it is: "Believe in yourself!" I'm trying to achieve something different here, so I need different methods than all the others. What is seen as the best way to do things is often what the majority thinks is best, but I believe the majority of people enjoy being lazy in their sofa more than changing the world, so the most upvoted answer to your programming question on that Q&A site is probably promoting mediocrity rather than true genius. Shortly said, if I do things in the same way as others I'll get the same results as others, but I want better results than others, so I have to go my own way. Here's my plan in practice:
#1. I have to not get tempted to earn money. That's asking the user for stuff.
#2. I'll keep my programming minimal. This makes the game more predictable and bug-free. As I said in my last text: "For every new concept you add to your game its complexity increases logarithmically, because one thing can affect another, that can affect a third thing, and in the end so many things can affect each other in so many different combinations that the number of possible things to do in your game get close to infinite. No programmer can keep track of an infinite amount of possible events, so then you're forced to accept there will be glitches and loopholes caused by imperfect code that you may never know about." That's what we DON'T want. But I'm divided about this because I'm not sure if games should be predictable and bug-free (it's through the cracks that the light shines through?) or not, but at least it's a good way to keep the game running for a long time without turning into a dead "error 404" page.
#3. I have to not get tempted to get help from useful tools and programs. It will give away control from me to the programs which isn't good long-term. Yes, game engines are helpful but will they be in the future (will my project file still work when a new version of the engine comes?)? Will they even exist in the future? If I depend on external factors and these factors change, my game will change and maybe break completely and you'll lose trust in it, in a way you almost can't lose trust in a Game Boy Advance. Engines, tools and even high-level programming languages help you get started quickly at the expense of control, while working in low-level languages and creating everything from scratch gives a slow start but repays you with time, if you manage to overcome the high threshold and are actually good at programming.
#4. I'll focus on what everyone has in common. Make the game for the worst imaginable computer instead of the opposite. We can probably assume all people have at least 250 MB of RAM in their computer or phone, some way to navigate and do actions on their screen, and at least a super-super-bad internet connection (we have to assume the worst here). If we imagine we're making our game for a console with these specifications, the unpredictable mess of the internet can turn into something we can understand and predict.
#5. I have to learn how to predict the future. My game shouldn't only be stable, but stable forever (or maybe for 50 years?). Smartphones came somewhere around 2007 and almost killed layout as a concept, and suddenly the websites' images and text didn't fit on the screen anymore. How do you make a game, or anything graphical, in a world where things like this can happen? Such paradigm-shifts are impossible to predict. Some things are timeless, like the need for human connection, great stories and rectangular screens to look at entertainment on (at least they won't disappear, or turn elliptic, in the next 50 years), some things develop incrementally (computers slowly get more memory, disk space and CPU speed) and some things come from nowhere and change everything, like smartphones or AI. I can't include these sudden revolutions in my calculations because it won't work. If we look into details, I'll use programming languages, standards and concepts that have been around for a long time without changing much, because then they'll continue to be around for long while the trends drop off one after one, I believe. HTML and Javascript have been top dogs since they came, the graphics standard WebGL is based on OpenGL which has functioned since 1992 so I'll ignore news about the supposedly "better" standards Vulkan and WebGPU, and text-based interfaces will survive all cool graphical interface trends (yes, that's why I program my whole game in the most neutral and feature-less version of vim, it may look stupid and I may be unable to use my mouse to scroll through the file, but it's a long-term investment!).
All this is inspired by gaming consoles in general and the Game Boy Advance in particular. Game Boy Advance doesn't ask people for stuff (#1), it's a small unit that is ONE thing consisting of only a few parts where each part only consists of few small and simple parts (#2), it's independent of external factors (for example, it's not connected to the internet) which makes it stable and unchange:able long-term (#3), and its programmers could tailor their games perfectly for it because they knew exactly what hardware constraints they had to adapt to, which is something I'm trying to recreate with #4 and #5. This created an amazing user experience both on the surface and deep inside the players' feelings, and now I'll create my version of that experience on the web.