Managing a space station
Starbase Devlog #2
I’m a big fan of simulation games
There’s one main issue with creating games with crazy simulations—they need insane amounts of interfaces! Everything selectable needs an interface to view and interact with its data and all events need to be available to the player for review. Luckily for me creating a simulation game on the web is easier because a website is nothing but interface! The hard part of creating this game isn’t going to be the coding of game mechanics (which will be challenging), it’s going to be designing and implementing the most intuitive and accessible interfaces. That’s what this post is going to be about!
This post is the second development log of my webgame Starbase. The last post was way more technical and goes into my programming setup, if you’re into that.
The core idea
You’re the manager of a space station that has three main components: individualized rooms, units, and space ships that can be sent out on missions. Rooms have slots where units can work and generate resources, and units have needs and a morale system that necessitates a break now and again. This leads for some interesting game design problems that I’ll go into for a later post. Let’s talk about controlling stuff!
Selecting units
Units, the computer terminals at which they work, and rooms are all selectable. I wanted a similar interface layout for each selectable object, and in my initial idea I had the interface compartmentalized into three main sections. The selected unit would be drawn in the left-most box, with a contextual quote of their feelings below them. Their main stats, progress meters, rank, morale system, and other stuff would be crammed into the center box. And finally on the right are our controls over the unit. Laid out in a two by two grid and ordered from most positive (promoting a unit) to least (firing a unit); represented as icon buttons.
This design has many problems, however. Having all of the main information crammed into one box is a major issue, but what’s even more problematic to me are the controls. Square icon buttons with little to no text and basically all crammed together; not only would the user have a hard time figuring out what each button did, they would accidentally hit the wrong button on touch screens.
Well, we already designed the buttons to be sorted by use, why not combine similar-use buttons and slide out more controls? Controls that slide out over the information content of what you have selected? I needed to come up with a better design. Because that idea sucks.
Design by iteration
That’s fine through, most first ideas do suck. What didn’t suck was the idea of compartmentization of actions; putting the upgrade buttons together and putting the edit buttons together. I liked the idea of having specific buttons be available when the user was in a certain mindset, so I came up with a design that compartmentalizes everything. Finally, room for button text!
This offers a lot of control as a designer. I can now section off content more easily, progressively disclose information to the end user, and keep the user focused on actions that are only relevant to the information they are currently inspecting. It also give us more interface room on touch screens!
The sections can be ordered by relevancy as to what is currently happening; information about current tasks to the left and information and stats about the selected object itself towards the right. In the minimized sections, small bits of information could be shown, like how many resources this object is generating. If the user wants the whole story, they can open the section.
Global Game Jam is this weekend!
Which is why this article is all about design and no code—I don’t want to get burned out before working all weekend on a new game! I’ll write about my experiences this weekend and further developments on Starbase next week. I’ll probably be jamming in Unity, which is exciting to be using a “real” game development environment again. Toodles!
