Previous attempts at the build interface were mostly just conceptual explorations. Now that we’re very close to having a complete spec for V1 of the game language, I had to start thinking seriously about this experience.
I started with the basics: how to create, connect, and populate rooms. Clicking on a blank space (the darker squares) creates a new room. This is represented here by the box in the top right, with a plus sign (that being the hover state). Drag new items & characters out of the black palette bar (top left) to add them to a room.
The checkerboard layout has no semantic meaning, it’s there to keep the interactions constrained, as well as to let writers organize their rooms. How the game handles > 25 objects remains to be seen, I have sketches but nothing has quite clicked.
You might recognize snippets here from 37Signals apps, Google Maps, and Photoshop. My general attitude towards interface design is to use established patterns unless you have a very good reason not to1, especially in your early versions. In our case, we want to get out of the writer’s way and let them focus on making the thing. Familiar patterns are the fastest way to get there. It also tends to make development cheaper, and we like things pretty scrappy.
I’ve felt out of my element throughout this project — designing the play interface without any background in game UI, for example — but this, specifically an authoring tool, is a challenge I’m comfortable with. Next step: how you actually change the properties of these objects.
-
One good reason: if your product is primarily differentiated by its UX. ↩
-
lsirivong liked this
-
coldbrain liked this
-
vorpaldinger liked this
-
picaro posted this
