Adventurers! Update

Quite a while ago, I wrote a post about a co-operative card game that me and an avid game enthusiast Mikael Fehlberg were developing. It's come quite a long way since that post, and is just reaching the physical prototype phase. The theme--we've decided--is going to be steam punk, and while the name of the game is still up for debate, the blog is currently at http://gearsandsteam.blogspot.com.

Gears and Steam is a Co-operative card game, spawned primarily out of Mik's and my shared desire to play games with the non-game-playing people we love. Co-operation is a much easier way to accomplish a fun, shared experience than a competitive game, and Mik and I are developing a game that is not only accessible to people who aren't hard-core into tabletop gaming, but also making it interesting for people who are.

Our game focuses on deck building, with simplified options that allow you to progress your ready-made, streamlined deck in one of three directions, depending on what your team of heroes needs. As the players, you fight your way through various scenarios, each of which call upon smaller, re-usable villain decks which occasionally compound with each other to make each scenario difficult in different ways. These scenarios can be played in a sequential order of difficulty, and the choices that each hero made in the previous scenarios will carry over from game to game, giving each player different starting abilities and benefits.

For those of you too busy to click links, I'll probably end up double-posting many of those posts to my blog here, and I'll start right now:

Changing gears from conceptual design to a physical prototype brings challenges that you might not initially think about. With a card game specifically, you're essentially creating the entire game before you can playtest anything. That means that you're going to have to spend a lot of time writing things out on cardstock, or spend time on a formatting program to work on printing out the cards.

Today, Mik and I spent more time than we anticipated just trying to get the physical prototype in order. Having done all the work and everything laid out in spreadsheets made this process easier, but didn't remove all the gruntwork that stood between us and our first playthrough.

Not surprisingly, we're both anxious to start. We're at the point in design where nearly every conversation ends with something along the lines of "well, we won't be able to tell which is better until we play test it", and being at that point is really exciting. So far, we have decks completed for vanilla ADC, Support, and Tank characters, even with roughly cohesive deck themes (Raymund the Electronaut, Temper the Boilerman, and the Gentleman, respectively). With the last few minutes of development today, we printed out a slightly unfinished version of the campaign one/game one villain deck, the Spiderlings.

Recently, we've also been surprised at how much effort creating a unified and cohesive villain has been. Making heroes was relatively easy because its everything that we've wanted in a co-operative deck building game. The villain, however, has proved particularly challenging because it's essentially the entire game. We can't make the villain too easy or the game won't be fun, but if we make it too hard the game won't be winnable, which is even less fun. On top of that balance, we have to give the players interesting choices to reward them for optimizing their hero's abilities, but not restrict them to such a narrow set of plays that they have no choice in what to play. It's quite the line we have to walk.

For now, we're just anxious to start playtesting. We both expect a large amount of rule-changes after playing, and we're hoping that those rule changes won't have to include axing some of our favorite aspects of the game.

New Co-Signers Hacker interface

I'm sitting in on an Engineering meeting discussing how to approach creating the new interface for the Hacker. Previously, I've talked about how we want to improve gameplay while preserving the essence of the game and adding the emotional-states-pyramid to the Hacker. The new system changes how you connect to nodes to aid the Thief in getting through the level, and makes the Hacker side less of a UI and more of a game.

Chris Rawson and I spent about 2 hours making an animatic to show how the new Hacker interface will lay connections and connect to nodes using After Effects. When I say "Chris and I", I really mean "just Chris", who opened my eyes to the glory of making a Visual Prototype. I've since learned how to use After Effects.

The idea is that the Hacker gameplay takes place on a hex grid, and several of those intersections will contain nodes that relate to the Thief's world. To connect to those nodes, the hacker has to have an unbroken connection of links from his source node to the node that she wants to control.

The Hacker will place a network of links on the Hex grid lines in one of several orientations. Once placed, the links can be rotated to make or break connections to other parts of the Hacker's network. Once every few seconds, the Security System will chose a random node out of every node on the board to check (nodes are only doors, IR, password, etc., not intersections or rotation buttons). If the Hacker is connected to a node checked by the Security System, a chase sequence will commence. More frequently, the Hacker will click on the rotation button for a link to rotate the connecting link and avoid being chased by the security system. By rotating this link, the Hacker will also lose control of the node the Security System was checking at the time.

To place links, the Hacker clicks on an unoccupied intersection and a link appears in one of two default positions--both horizontal angled down. If the Hacker doesn't release her click, she can drag around to change the initial orientation of the link. No matter how the player rotates the link, the location of the rotation button (the initial intersection the player clicked) will stay static. This will allow for rapid placement of links that still allow for a varying degree of skill in how the placement effects the gameplay.

3Colors Dev

The Hacker portion of the Co-Signers needs some serious work. Click-and-capture node after node is pretty boring, regardless of how he interacts with the Thief. Since the Summer started, the design team has really had some time to ponder over the elevated emotional states graph that I put into my last two posts. We've come up with one particularly awesome solution that addresses every level of the graph, makes the gameplay less boring than mud, fits into the visual aesthetic of the game, explores our thesis statement further than before, and doesn't interfere with the current Hacker-Thief dynamic that's core to the game.

That solution is for another post. To get there, we pitched dozens of ideas back and forth to come up with mechanics that fit all those things. Lots of ideas were generated and rejected for not filling one or several of these categories. Some of them were really cool, and one of those is what I want to talk about.

Initially, this was a solution to allow for the hacker to get to various points on the board while frustrating what combination of nodes the hacker can or can't capture. It was scrapped for requiring too much focus on the Hacker's side, which would distract him from the dual game he had going with the Thief, among other technical issues. The idea is that the entire board would consist of interconnected, multi-colored nodes--some of which would be key points that the Hacker would have to capture. However, only a certain number of color combinations would be available to him, and they wouldn't always point to the direction that the Hacker wanted to go. This was too distracting for the gameplay that we were looking for, but a cool idea for a small iOS game was there.

Tuesday I spent a good three hours trying to design this solo and came up with several ideas, none of which were great. When this became its own game, the inherent goals of the game were removed, because there's no reason to capture discrete points if there's nothing that you can do with them once you own them. Furthermore, I wanted to make sure that this game was really simple--not only to make the scope small, but to make the play experience simple and rewarding.

Some of the ideas were things like trying to capture rows or columns, trying to capture all points before they scrolled off the screen, trying to capture key circles, trying to capture everything within the time limit, and trying to capture things before they changed colors. All these ideas fell short, for various reasons that I might go into later. Whats important is that I put in a lot of time, had nothing, and was really frustrated that none of the ideas that I came up with were working.

Yesterday I talked to Zac Trustcott about my woes and we pitched ideas back and forth for a bit. Not five minutes into this, I came upon an idea that really sang. The idea is to capture everything on the board, but any time you capture a circle you've already captured, it becomes un-captured and changes to a random color. You still have the bank of color combinations to choose from, and it eliminates the swipe-spamming problem that was prevalent in other versions of the game. In lieu of a design document, I took a page out of Chris Rawson's book and made an animatic for it:

The game starts the player out on a distinct point--in this case, its the upper left corner of the map (the animation doesn't show this at all). The player begins to capture circles by holding down and swiping across colored circles, trying to match them up with one of the random combinations on the left of the screen. The player has to start his swipe on a circle that is either already captured or next to one that is already captured. If the player ever successfully captures a node that is already captured, the node becomes un-captured and changes colors.

Its a low-enough scoped game that we should be able to build it over the summer, and fun enough that it should be really awesome. The moral of this story is that time spent into development is never wasted, even if you come up with nothing. Talking with people after putting in effort can provide the spark that allows all those ideas to come to fruition.

Now, its time for the first meeting to start building this. I need to come up with a wrapper...

                   

Illustrated Thief Mechanics

First off, I'm going to admit that I'm embarrassingly proficient at paint, because I always use it to do stuff like this. These are some quick diagrams showing some of the Thief attention states that I was talking about yesterday:


Case 1: The Thief has walked in front of the door to his right, and noticed that an awareness bar is filling up. Quickly, the Thief ducks back into the hall to prevent a chase.

Case 2: The player has walked in front of the room in front of him and was seen briefly by the guard there. Normally, the player would not be able to see the guard, but since a guard is aware of the player, an awareness icon is displayed where the guard is standing, and is even seen through walls.

Case 3: The player allowed a guard's awareness to fill up completely, and is now being chased. The guard behind the player has called for backup, and the guard ahead and to the right is close enough to answer the call. While the player is seen by at least one guard, all guards chasing the player will be represented by a red 'chase' mark. In this case, the Thief has a few choices available to him: duck into the room on the right and hope the hacker can help lock the door in time, run down the hallway to the left, or duck into the room in front of him. The chase should be a moment of quick thinking, and displaying all guards chasing the player will allow them to make more informed decisions more rapidly.

Case 4: Once the player has stepped out of the view of all his pursuers, he enters the "search" state. Guards are still shown through walls via their awareness meters, but it will gradually decrease to nothing while the player is not seen. In this case, the Thief's best option seems to be to jump into the room on the right.

Improved First-Person Stealth Gameplay.

Last post I discussed theory that Chris and I laid out during our Monday design meeting regarding stealth game player reactions and states. This theory led to several changes in the Thief interface in the Co-Signers and even more on the Hacker side.

First, after spelling out exactly how several other stealth games have worked in the past, we were able to determine what our game needed and exactly why it fell short. In the current prototype, the Thief continues along until spotted, where the guard in question then practically flies directly to your location and captures you. This all occurs within 1-2 seconds, without warning, indication, or chance to react.

I'm going to be referencing this chart a lot, so I'll just stick it in here now:

Our Thief gameplay really only has two of the 5 states: normal, and game over. In other stealth games, the player is given a very clear indication that he is in danger of being noticed, and also that they are being chased. What our game doesn't have is that high-stress moment where the player has the chance to back out and not be chased.

We concluded that an 'attention indicator' would address this. The player would see an exclamation point filling from bottom to top when the player has been seen in the direction that the player is being spotted from. After 1-2 seconds, the exclamation point would fill up and change color from yellow to red, indicating that a chase has begun. The (now red) exclamation point will rotate around the player's screen to indicate what direction the player is being chased from. While the exclamation point is red, the player knows that he is both seen and being actively chased. These changes take care of both the seen and chase state, and give the player ample forseeable consequence to anticipate losing the game.

Should the player lose the trail of the guards during the chase sequence, the exclamation point will gray out and "drain" from top to bottom, but still remain on-screen in the direction of the guard--indicating the "searching" state. If the player is re-spotted while hiding the chase sequence will immediately re-commence. Should the player successfully stay unseen while the exclamation point drains to zero, the indicator will disappear from the screen entirely and the player will finally return to the normal state.

In reality, these changes aren't a drastic change from what we had before. The differences are a delay in guard awareness and how quickly they begin to chase the player, a change in guard speed (you should always be able to out-run them), and a UI element to indicate to the player what the guards around him are doing. The core of the game hasn't changed much, but the effect that it should have on the Thief player is dramatic. We're giving the player time to register moments of panic, see the consequences of their actions and anticipate them in the future.

Stealth Game Theory

Game design is like that really awesome hobby that's hard to classify as work. The past few days I've been designing I've found that hours will pass without notice. I know that this won't be what daily life is like in the industry, but it makes me feel good that I'm getting into something that I know I love.

This week design has been focused a lot on Co-Signers. On Monday, I spent about 5 hours with Chris just talking about the game and determining how the game should work before we realized how much time had passed. Working on a design team of two is possibly the easiest design team to work on, as more people make it much harder to come to consensus with. I like graphs, so here's one depicting how easy it is working with more designers:

 Working alone is really hard because there's nobody to bounce ideas off of. With three designers, that 'bounce off' effect is still present, but you now have the burden of getting three people to agree on something and continue on and/or drop a topic completely and shift gears rapidly in your design discussion. By the time you get to about 5 designers working on the same problem, that burden increases so much that its almost worth it just to design on your own without anybody to think with.

That being said, just Chris and I had an awesome design pow-wow on Monday and worked out a lot of really cool things. The most important was the player reaction chart, which I'm more than happy to pictorally represent:



This chart represents the several states of emotional response during a stealth game. I spent some time last weekend playing stealth games like the Metal Gear Solid series and Monaco, and I noticed that all games have the option to quickly recover from being seen. To do this, it must be clear to the player that they were seen, and they should also be able to relatively quickly assess how to evade full suspicion of AI. The "seen" state is a high-adrenaline moment of fast reflexes and quick thinking to evade being chased, and relies on that person. If the player does not react quickly enough, a chase sequence occurs.

The chase is an inevitable part of any stealth game and must be accounted for. This is a higher-stress, longer sustained sequence than the "seen" state with one important distinction: the game is on the line. If the player retains the "chased" sequence for too long or makes enough mistakes here, the player has lost the game. It is this threat of failure that intensifies the chase sequence above the "seen" sequence, and why the chart branches off at this point. In the case of the Co-Signers, an additional distinction surfaces: where the "seen" state is a high-stress moment for one player, the "chase" sequence is a high-stress moment for both players, as one person losing will cause both to lose. The chase sequence demands the full attention of both players, where the "seen" sequence demands the full attention of only one player.

If the player manages to lose its captors, it does not immediately return to a normal state. There is a period where the AI continues to search for the player even though they are not seen, and this is the "hidden" state. Whats interesting is that this state retains a similar amount of stress as the "seen" state for the player, even though it may still require the attention of both players. A player will hide behind office furniture for a good 2 minutes hoping and praying that the guards don't look around this particular desk. Once the player has evaded detection for long enough in the hidden state, the guards give up and return to their normal routine.

That theory is enough for one post. I'll get to what we did with that information in the next post.