So, I feel I’ve been talking a lot about code lately, especially for someone that claims to be a game designer. This isn’t a bad thing—after all, I have to write the code myself, and designers really should, in my opinion, have enough grounding in not just code, but all aspects of game development to be able to knock out at prototypes, or at the very least communicate with specialists.
Game design, unfortunately, tends to be an area of development that is not treated very seriously. Often companies feel that game designers are unnecessary, perhaps figuring that since programmers used to handle these tasks themselves back in the day, that it belongs in their hands, or that game design means level design, or similar.
Despite my obvious state of opinionated disagreement, I’m going to leave that topic off for now. The point was just to say that I’m taking a break from talking about code for good reasons to instead discuss the design challenges thus far on bringing Nucleus to a phone device. Hopefully this will prove useful to others in their own projects.
Nucleus started out as a class project that was taken through to a reasonably-functional prototype state, so a lot of the basic game design work is already completed. The overall play model is established, it works reasonably well for the state it got to, et cetera. Naturally, that means a lot of those details don’t have much to do with the phone portion of things, but it’s useful to talk about a bit of it as background for the discussion ahead.
Nucleus was originally built in the Torque Game Builder, for use on a PC. This, naturally, had a few influences on how it was designed and built, and has some ramifications for moving forward, most of which are not entirely important. The most notable items are the mouse-based input model (which was based off of an existing game with similar needs), and the way the central “catcher” structure is laid out and presented. There are also a few other decisions worth noting, which we’ll get to later.
Usability, Use Context and Physical Limitations
One of the things that a good game designer is going to be concerned with is the user experience. Arguably, games are nothing but user experience—play, engagement, flow, et cetera—but we usually have some specific things in mind when we’re talking about User Experience in capital letters. This is where we start to get into the field of human-centered design considerations and so on, how our users interact with what we make.
I expect that of the three topics in the heading, the only one most people might not understand right away is use context. This is the sort of term trained design people like to use when talking shop, but it’s a simple idea that is basically what it sounds like. Use context is simply the context in which our end users experience our product—IE: the context for its use.
In Nucleus’ case, the original use context was a desktop PC, which sets a certain expectations in the user’s mind for how they are going to interact with it, based on natural inclinations and cultural conditioning. These expectations are things as designers we need to be very concerned with. We need to understand what they are so that we can either avoid breaking with them and causing frustration, or so that when we do break with them we plan adequately for re-training the user into new expectations. We also have to consider the limitations, particularly physical, of our context, because that will also affect how our product is interacted with.
Ring Ring, Neo
So, with that groundwork laid, let’s talk about Nucleus in its new use context: the phone. Specifically, Windows Phone 7. There are a number of design issues that come up in this new context, and probably quite a few more that will come up in the future.
The most obvious change people mention when I show them the prototype and the current progress on the new version is the design of the central structure. In the original, it is constructed of a set of many individual animated sprites arranged around a center point. This was done due to the nature of the TGB’s engine setup, where classes are affixed to visible objects and the easiest way to handle them on the code side is to keep each logical object in code associated with a visible sprite.
It works fine on a PC, which pretty much laughs at the idea of a couple hundred simple sprites on the screen. The phone, on the other hand, considers this a significant amount of work, and doesn’t require that every data object we want be tied to an actual visible object. So, bearing this in mind, I changed the way that things are done, and take advantage of it to improve some areas—most notably, the new structure layout is much more appealing than the old one, with nice curved lines and such. Possible with one large sprite, not nearly as easy with a bunch of them pieced together. Additionally, the developer no longer has to lay out that whole mess piece by piece. It’s a much faster job in Illustrator.
This is thanks to a physical limitation of the new use context—the phone doesn’t have a lot of processing power to spare, and one large sprite (though actually, it’s two) turned out to be much faster than dozens of small ones.
Speaking of power to spare, that’s another point—one has to consider that battery life is a major concern for phone users, and what you choose to do with the hardware can impact that battery life. That’s another reason for keeping track of performance and trying to keep things from taxing the system too much, and basically designing around the idea of limited processing. The details of getting an exciting, interesting game that attracts people to play without them avoiding it due to the way the processor load sucks the battery dry is a point well worth considering. After all, part of the point is to have people play and enjoy over a long term and provide word-of-mouth sales to others.
The phone, unlike the PC, is centered around touchscreen/accelerometer/compass/GPS/etc input, without necessarily providing the options of keyboard or mouse. This, of course, has major ramifications for how we design games and interactions. Nucleus is fairly easy—the touchscreen suggests a natural input that most users are likely to assume. Which isn’t to say I didn’t consider the other options. Of them, only the accelerometer really made sense, but it just doesn’t give the fine, responsive control the game is going to end up demanding.
When I designed the input for the PC, it made the most sense to simply track mouse X movements and spin the catcher accordingly. On a touchscreen, the expectation is that the spin will follow one’s finger, however. This is, as I’ve talked about before, a great deal more complicated to get working, but really does provide a much more natural and expected experience in the phone environment.
The last point I’m going to bring up today is the aspect ratio and physical screen size, both of which have major ramifications to the game’s design. the first issue is the aspect ratio—as you can see, the original nucleus was a lot closer to a square aspect, meaning that the distance from the catcher to the edge was much more uniform. This has an effect on difficulty, as it means that you more or less have a similar amount of reaction time no matter where a falling orb comes from on the screen. Contrast this with the 480×800 screen of the phone—there’s a much tighter fit in one direction than the other. This necessitates understanding that the difficulty is going to change depending on where the incoming objects are coming from, and starts to pose questions:
- Do we only allow objects to fall from certain directions?
- Do we widen the allowed directions to increase the difficulty as time goes by?
- Do we reduce the size of the catcher to give more time to react?
- How do we communicate to the user what our decision was?
- These are all very important questions to have answered, but we can’t make a decision based on the aspect ratio alone—we also have to be concerned with the physical screen size. The trouble is, the devices aren’t yet out, and screen size may vary. We can make assumptions that the prototype devices we’ve seen are representative of what the production versions are likely to be, at least. The point here is, the physical size is important because that affects the visibility and readability of our sprites to the end user, a point which affects our questions and concerns above.
- Ultimately, I’m shooting from the hip a bit with Nucleus. I have a suspicion that I’m eventually going to have to re-visit the size of the catcher to make it easier to see the details, but time (and an actual device in hand) will tell. For now, I’ve opted to keep some room between it and the nearest edge of the screen, and I’ll use a limited spawn area that gradually grows outward to the short-aspect areas of the screen. It’s a bit of a difficult problem to work with, as visual information is going to be pretty important, and I do want to spice up the visual appeal with some nice particle effects and a subdued, but interesting background.