Designing with PGDI: Answers to Some Questions

I’ve had a bit of a lapse in posts on My Childhood on the RS Anthony, mostly due to going to the Queerness in Games convention this weekend, and a general amount of work getting in the way. I’ve been thinking a lot about the game, though, and about some decisions I’ve made about the questions I posed in the last post. Here, I’m going to take those questions and write out some answers or some attempts at answers. This is going to really reflect how I think about design and what I think about in this phase of the process. In the end, I’m going to come up with some deeper questions, which should be addressed by next week.

To remind you, here is a list of the questions I put forth last time:

1. What am I going to build this game with?
   1. Options are Unity, GameMaker, Inform 7 (text game),  or something else
2. What is this game going to look like?
   1. What will the characters look like?
   2. What will the environment look like?
   3. Do we need a font? Which?
   4. Do we need a GUI? What will it look like?
3. What will the controls be like?
4. What perspective is this game going to use?
   1. Options are top-down, first-person, over-the shoulder, follow behind.
5. What options do players set for their characters?
   1. What appearance options will the player get to set?
   2. What personality options will the player get to set?
   3. What ability options will be available to the player?

I’m going to take these questions one-by-one and attempt an answer for them.

What am I going to build this game with?

After weighing my options, I am choosing Unity. There are a number of reasons for this. Unity has a lot of flexibility for target platforms. So, for example, I could publish to the web, or to a standalone executable. I might even have other targets, but those would be trickier to pull off. In addition to platform flexibility, Unity is easy to use, it is familiar, and it has support for things I might consider using (such as controller support).

What is this game going to look like?

This is a broad question with a lot of sub-questions, but the answer, in general, is that the game will look simple. It will be minimalist in style. This means that I can use simple shapes to represent characters and objects, that I don’t have to do a lot with animations, and other things to make what could be a big game have fewer assets to generate. Setting the game in a space research station is also a good fit for this art style, since players will expect the setting to be clean, assimilated, without variation. As a result of my thinking about this, I have crafted a mockups of a character (right) and the general space in the game (below).

As for the font and the GUI, I determined that both would be needed. I discovered a font called Monkey, which is 100% free to use for any purpose, fixed width, and looks like it fits in a space theme. This game needs a GUI for character creation, dialogue, ability selection, and some kind of pause menu. Additionally, there should be something like a start screen and an ending screen like just about every other game. The most complicated GUI will be character creation, due to wanting to make sure that the player feels like they have enough choices to make about their character. This will incorporate typing fields, sliders, and color selectors. Alternatively, character creation could be posed as a series of questions.

Part of the GUI is knowing that I need to have some way of pausing the action of the game. This is important to note at the beginning, so that when I go to code the game, I understand that such a system will be in place. This knowledge is found in the fact that a pause menu should be available and that dialogue will probably need to pause the game as well.

The GUI for ability selection will probably be displayed at the bottom of the screen, in boxes, with the current box highlighted. This is a simple GUI, and won’t be too intrusive. This means that each ability the player has will need to have an icon that players can recognize. This shouldn’t be too much of a problem, but those are art assets that need to be made.

What will the controls be like?

I’m pretty much going all out for controls by allowing keyboard/mouse and controller support. The benefit to using Unity is that I don’t have to code for these separately, I just have to set the inputs up. This also means that I can have a bunch of control schema thrown about. So, for example, I can use WASD controls and arrow key controls and thumbstick controls and let players set these controls themselves if they want something different (say, if they’re using a Dvorak keyboard). I’ve already thought out the potential keymappings and have them here for you:

• Keyboard/Mouse Controls
  • Arrow/WASD to move.
  • Mouse to look/move camera.
  • Mousewheel/[]/1-6 to select abilities.
  • Click/e/x to interact
  • Right-click/q/z to use abilities.
  • Space-bar to jump.
  • If we have crouching, shift to crouch.
  • Esc to pause.
  • Mouse3/Tab to switch camera.
• Controller Controls
  • Left Stick to move.
  • Right Stick to look/move camera.
  • L/R to select abilities.
  • X to interact.
  • Y to use abilities.
  • B to jump.
  • If we have crouching, R3 to crouch.
  • Start to pause.
  • Back/Select to switch Camera.

If there are any strange controls in there, then let me know. I understand that I’m using XBox button names. That’s because I only have XBox controllers to compare to. Some things people might notice is that there will be jumping. But don’t expect much. It’s going to be the most pathetic jump even, unless augmented with an ability.

What perspective is this game going to use?

I am going to try to aim for a first and a third person camera to be available. The third person camera will probably be on rails of a kind, to avoid strange situations with wall transparency. The movement will change based on the camera used, from a camera directed movement to a first person movement. A fancier version of third person cameras is to allow it to follow behind, but I’m really worried about the concept of clipping through walls. This was a simple decision, and it makes sense to let the player choose which mode of view they want.

What options do players set for their characters?

This is a huge question, so it’s broken down into sub-questions.

What appearance options will the player get to set?

This one is fairly easy in comparison to the others. The model, as shown above, has three distinct parts, each with a different color. The player will simply get to choose the color for each part. If time permits, then I could also include a height/weight option, which would be helpful for differentiating characters in the long run (though most other characters will be taller than the player’s character).

What personality options will the player get to set?

First and foremost, the player gets to name their character. The font I have under consideration doesn’t have much in the way of special characters, so I may have to scout around for a more encompassing font. Second, I thought it would be interesting to have the player able to select their character’s favorite station activity from a set of activities available on the research station. This could be referenced in dialogue, and the activities might lead to suggestions for locations to be put in the game. The same could also be said for favorite food.

What ability options will be available to the player?

This question is the real problem. Abilities are important to the game. So is choosing what abilities your character has. It would be easy if you, say, had a choice between two each time, but coded for each choice in the next stage of the game. But because there is this focus on player choices to reflect a personality, I want to allow players to choose them in whatever order they want. The problem we end up with is that of combinatorics. Let’s take a silly number and say that we wanted six abilities, chosen in any order, starting with the first one. This means that at stage 1, you can choose any of the six abilities. Then at stage 2, you can choose any of the remaining five abilities, and so on down the line. The math behind this is weird and complicated and requires dividing a number of factorials, and summing the results using different values, depending on what stage you’re at. Suffice it to say, there are 63 unique combinations of six different things (this is throwing out combinations that are equivalent other than order, so AB is the same as BA). The problem with this number is that, because there are 63 different unique combinations, there are 63 different possibility states the player can be in when approaching a problem, as the game goes on. That means that you need to make specific paths of game progression for all 63 sets of abilities. That’s a lot to make in a few weeks! (Now think about the combinatorial mess that is Mass Effect.)

So six abilities is too much. What do fewer abilities look like? Five abilities gets us down to 31, less than half, just by removing one ability. Take away another one and we get 15 for four abilities. At three abilities, we have 7 combinations. 4 and 3 seem more doable, though they seem to be making the game rather short. You start with an ability, interact with an NPC and gain one more, then do it again, and you’re done if you have three abilities. Do it one more time if you’re going after four abilities. A trick to reduce the number is to make the first ability predetermined (there’s no choice). This moves the number of combinations down to as if you had one fewer ability, plus the one for the predetermined ability. So four abilities with the first predetermined becomes 8 (7 +1 for the predetermined ability). Five abilities becomes 16 unique combinations, and six abilities becomes 32 unique combinations. This overall sounds pretty tenable.

Each combination of abilities will directly lead to content. That is, each one needs an NPC with a different problem, which will lead the player to a unique place in the station, and therefore, each combination will determine the size of the game. I’m not very excited about making much more than 16 different areas for the game to spider out into. 15 even seems too much for making in the next six weeks. So my target number is either 7 or 8. The benefit with 8 is that you get to give players a standard start to the game. The game, by its nature, will always have the same ending (there’s only one unique combination that includes all the abilities). But this does reduce the beginning choices by one. Still I like it better than having 3 abilities. That makes the game too short to have an emotional arc, I think.

None of this, by the way, gets down to what the abilities are. That’s because I haven’t decided yet. All I know about these abilities is that I want them to be pairs of abilities (so actually, I’m looking at 8 abilities). This means that each obstacle in the game needs to be able to be bypassed with both abilities in a given set. I feel like the major obstacles in the game will be people and doors. Some people will need to be avoided. Some doors simply won’t open. Other potential obstacles might be walls in general, or possibly alarms or cameras. Each ability group will focus on one kind of obstacle. So, for example, an ability group dealing with people might have abilities for avoiding or incapacitating a person. Each set of abilities should have a direct (incapacitating) and an indirect (avoiding) way of dealing with its obstacle.

I’d like to stay away from any of the abilities outright harming people, otherwise the game’s story might be too easy to spot, but abilities that might eventually get to that point if practiced. So, perhaps an ability that makes someone fall asleep for a few seconds would give the player enough time to move around a person. Doors, walls and cameras can be a tough set of obstacles to deal with, though. It’s important that each ability not seem like it can be used on a different obstacle. So, while it might be a good idea to turn invisible for a few seconds to get around cameras, this seems like it would work to get around people as well. Instead, perhaps walking on the ceiling would work. The cameras, pointed downward, wouldn’t catch someone on the ceiling, but a person would spot that right away, particularly if the ceiling isn’t that high, like it might not be at a research station.

Anyway, I think that’s enough talk about abilities for right now. I’ve still got a lot to work on this week. The next stage of the design process needs to answer the following questions:

1. What obstacles will be placed in the player’s way?
2. Determined by the obstacles, what abilities will we have?
   1. Direct abilities?
   2. Indirect abilities?
3. What do these obstacles and abilities have to say about the way areas are constructed?
4. Just what areas are in the game anyway?
5. What are the finer details of the game? I.e., story bits like the macguffin that gives new abilities, who is running things, what do NPCs want from the player, etc.

I think that’s about it. This was a long post, so I’m glad you made it all the way to the end. Hopefully the next post won’t be so long (though I’m not so sure).