EAE Open House

This past Thursday was the EAE open house, and things went really well.

The team had two 55" TVs that we displayed live gameplay team members playing the game. Occasionally, somebody else would have a go with one of the team members which frequently resulted in a really tense play session while the crowd looked on. It's great to see how much fun other people besides the debs have when they play our game. Admittedly, it was about as warm a crowd as you could get, but people still had a lot of fun.

About 30 minutes into the night, disaster struck. For some reason, one-by-one, stations began dropping out and became to one another over the network. We had never really stress tested the server, but 14 stations seemed perfectly reasonable, so we had totally not anticipated this problem. Fortunately, Max was there. He grabbed a laptop, built another solution and worked with the other engineers to install that new solution on the machines while Zac and I gave explanations while pointing at the YouTube videos. 

Although it seemed like hours that the game was down, it probably wasn't much more than 30 minutes. Max is a wizard, and our whole team is awesome for keeping their cool and jumping into action to fix the problem. I'm still not totally sure exactly what happened, but hopefully the break will give us time to diagnose what the problem was so we can avoid it for release. I'm strongly suspicious that Max knows what the problem is.

We got a lot of fantastic feedback, and we're blessed to rub shoulders with some very smart people. Jeff from EA Allplay was there to talk in detail about things that we can do to improve the interface and understanding of the player for hacker gameplay. He pointed out that we were fighting for the hackers attention--instead of having a power bar that we want to have the hacker continuously look at, he challenged us to get rid of the bar all together. There's something that we can do to show the information we're trying to get across without requiring a power bar, and whatever that is can be done in the area that the hacker is already looking. I suspect the same goes for the thief, too. We finally have some time to breathe this break before we go into the long haul that will be next semester.

Speaking of winter break, there's a lot ahead in the next few weeks. Chris has been working on a level-builder solution, which is sadly taking more time than we had anticipated. Hopefully, he'll get it working so that we can not only crank out levels faster than ever before, but also crank out levels with interesting shapes, (not rectangle!) As well. 

Personally, I've made it a goal to actually implement 20 levels into the game by the end of the break. I know that I'm capable of more, but it want to make sure that the levels actually get in to the game, and not have a handful of half-finished, buggy levels to show for my efforts.

Speaking of half-finished levels, Damean took the levels that we had been working with and really made them shine for the open house. I didn't consider the levels that we were working with to be half-finished, but the difference between levels that Damean worked on and levels that he didn't was like night and day. I have to remember to get him a better copy of the hacker map with the OS switches written on the hacker guide plane, that would really help him. 

I'm currently flying back from Illinois after visiting my family for the winter break, and I'm feeling extra revitalized to work on both Cyber Heist and finish up the Oppy project. I wrote this entire entry on a new iPad I got to help with the cross-platform aspect of Cyber Heist, and I'm really excited for the next few upcoming months.

What I did this semester

Recently I was required to write a postmortem for the past semester's projects class. In the postmortem, I was required to specifically list all the things that I personally contributed to the project this semester. I was impressed with the result, and I thought it'd be cool to post that portion of the postmortem here.

• Wrote up contracts for outsourced artists
• Developed art template pieces for walls in both code and geometry 
• Created the wall size and modularity system to help faster implement levels 
• Built, rebuilt, and scrapped levels dozens of times. 
• Built and imported whitebox assets for early game development 
• Imported and developed initial sound system for development 
• Wrote crouching/peeking code for thief movement 
• Imported dozens of art assets, including walls, obstacles, doors, pillars, etc. 
• Hand-assigned tasks to engineers and helped communicate feature functionality 
• Co-wrote a design glossary with Chris 
• Developed the new process to help coordinate engineer efforts 
• Helped schedule trips to Wahoo, ESP, and EA to show the game to pros, and invited in Shane and friends to see the game. 
• Made a spreadsheet and schedule to have regular playtesting, and spearheaded said playtesting. 
• Personally quality-checked every single feature from the backlog. 
• Organized and arranged meetings with Troy D’Ambrosio for business help 
• Added content to the game website, specifically the gameplay, story, game, thief, hacker, team, platform, and EAE pages.
• Populated the backlog for the project (See appendix A) 
• Managed and collaborated with our music outsource artist towards producing 3 tracks for the game 
• Re-named the game 
• Promoted our game at Comic Con and Utah Indie night 
• Contacted Unity representatives to push our game via twitter 
• Pushed drones instead of human guards 
• Designed Tracers, SAPs, jammers, transmitters, door functionality, ping system, link placement versions 1-3, peeking system, lasers, guard traps, guard alert meters, and guard detection parameters 
• Invited guest engineers to assist team engineers with AI pathing problems 
• Laid out menu screen functionality 
• Developed bug-squashing system for weeks leading up to IGF 
• Formally presented the game to EPs 4 times 
• Recorded play sessions for use in trailers/promotional materials 
• Recorded/wrote tutorial audio explanation 
• Wrote 4 versions of story premise
• Wrote Tutorial cues content for 10 levels 
• Designed over 20 levels
• Developed unit-test levels for guard behavior
• Wrote up word list and approach for unified media plan

IGF Submission

Team Hack'N'Hide just entered Cyber Heist to IGF.

It's a fantastic feeling. Even better than that has been how evenly paced we've been throughout the last few weeks leading up to the submission. Of course, we upped our workload a bit, but we've been pacing ourselves accurately so that minimal crunch occurred.

It was quite astounding to see the game come together almost seemingly out of the woodwork. About two weeks ago we finished with the final features of the game and began polishing the game a ton. We were blessed to have extensive feedback from faculty on the way that the levels went out, and our planning paid off when we were able to reconstruct all the levels over again based on their feedback.  

Being able to completely reconstruct the levels from scratch was, in my opinion, the biggest sign of good planning and foresight. It was also a great test to see how the level-creation process works and how effective our team could be at it. Had it not been for the remarkably frustrating process of having to implement custom code for the tutorials, the entire process of building all 6 levels would have taken the greater part of a single afternoon. Things are looking fantastic for future level iteration. 

Tutorials were significantly more difficult to get right than we had anticipated. With the help of Joe Bourrie from EA, we were able to really break down the things that we wanted to teach the player and introduce them in the order that they made the most sense. As simple as we thought the levels were, there were plenty more ways to make the levels even simpler, every time we thought we were "done". We playtested with three different groups to see how they reacted to the tutorial prompts and iterated them every time. 

Being at the point that we could just focus on player feedback and tweak small things at the game was fantastic. I frequently referred to this as "chump dev"; the stage of game development that anybody who hasn't made a game thinks that game development is all about. We tweaked, we altered, we bug-fixed, we band-aid'd, and it turned out to be great. We submitted our game calmly, ahead of schedule and excited for the post-IGF changes that we're going to make.

Our team rocks.

Proved Process and Professional Playtesting

This week was midterm evaluations.

I got to talk with Jose and Roger one-on-one (well, one-on-two) at length about what kinds of things we've been doing well and what kinds of things that we can improve.

I was extra pleased to hear Roger admit that we had proved him wrong on the process we implemented for the team. I wasn't the as excited over proving Roger wrong (he also loves being proved wrong) as I was excited to hear that the rest of the team not only tolerated the process, but actually approved and appreciated it. It was a producer's dream come true.

The process was two-fold: first, put in tons of review-checks and roadblocks to prevent off-design-concept or sub-par features from making it into the build. This prevents people submitting things without a clear concept of what the feature is or how it's supposed to perform. Second, hand-assign tasks to our team (comprised almost entirely of engineers) to make sure that tasks are appropriate for our relatively wide range of talent. This also has the side-effect of making people very accountable for the tasks that they've received. There's ownership over what they did, and everyone can take pride in the specific thing that they were in charge of for the game.

A combination of the summer one-on-one approach for the team and Zac's insight on how EA worked helped make this process really shine, and the team is running smooth as silk. However, Roger and Jose cautioned that "functioning" is not a reason to celebrate. There's all kinds of things that we can be doing to improve where we currently are on the game to bump our game up from good to excellent.

Among those ideas, the most exciting idea is to start making visits to other professional studios to get feedback and show off the game. We've just set up a visit to Wahoo Studios in Orem for next week, and I'm crazy excited to get professional opinions on it.

Level Building and Playtesting Prep

Today we presented a game to a recruiter from Microsoft, and Kiran and I gave a re-hashed version of the presentation that we gave to EA four weeks ago. It went really well, but we didn't have a playable build ready for him by the time we had finished our presentation. This didn't turn out to be too bad, because by the time he was done talking to team Vinyl he had forgotten to come back to our side of the lab to play the old build of the game we had running.

I knew that having a playable build was important for this exact reason, so I don't feel like I learned anything so much as I learned my lesson. We're working on getting a playable build for the playtesting starting next Monday, and the new plan is to have working builds for playtesting available for anyone who comes in to see the game.

This week is going to be focused on updating the build and getting those playable levels built. Furthermore, we're going to have to decide what to test during playtesting to make good use of that time. My time is definitely going to be focused on getting the levels up and the playtesting questions are ready.

New Semester

This summer has been a fantastic adventure.

Granted, it's now three weeks since summer passed, but the momentum that the Hack-N-Hide team has had since summer has been amazing. I've actually blogged about it several times on our team website, at hacknhide.blogspot.com

As a quick recap, we were able to present Cyber Heist (previously called Co-Signers) to EA Salt Lake to members from their entire team. After we presented, they were able to give us feedback that cut right to the chase of the things that we were concerned about. It was as if they'd been working on the game side by side with us the entire time and knew exactly what we were hoping to improve. I would love to someday have the expertise to be able to analyze a game I've never before seen with as much accuracy as they did.

Its been a fantastic experience over the summer working as the primary producer and designer along with Chris Rawson, who's now assuming the position of lead engineer on the team. I started out the summer splitting my attention between 4 games, and now I dedicate over 70 hours a week just to Cyber Heist. I've never had an opportunity to work this hard before, and its comforting to know that I'm still completely in love with the process. Working with games is definitely my calling.

I've recently applied to EA as a new graduate designer. They asked applicants to only apply to one position, and it took a lot of thought to decide between producer and designer. I feel like during the summer I had a very good insight on how both of the positions worked, but I feel like I have a better natural inclination towards designing. Its a little weird, but one of my favorite aspects of design is recognizing a feature that no longer works, cutting it, and developing a new feature that better fits the new parameters of the game.

Gears and Steam Update

Gears and Steam design time is iterating faster and being more productive than ever before.

Not that we aren't normally productive, its just that we're reaching the point in design where all our previous investigative work has paid off and we're seeing much larger leaps in development. We found a fantastic mechanic to keep hero decks feeling unique, methods to playtest and create villain decks, and9 developed a new classification system to help us rapidly balance the decks that we create.

With all this and the story that our writer—Dave Armstrong—has been creating, we came up with a complete functioning prototype from nothing within about 4 hours. This is iteration number 4 on our tank-class deck, but we've learned a lot on the way, and we're getting better and faster at creating decks that will make it into the final game. Our efforts have definitely paid off.

The most important feature we added in this most recent design session was that each deck will play cards in a unique way. Since these characters all have story and compelling features about them, this will be much easier to develop from the top-down and still make it fun. The primary mechanic in a card game is the act of playing a card, and what better way to make two decks feel completely different than to change the conditions that they play cards?

This came with counter-arguments, and rightly so. Once people learn how one character operates, they're going to have a tougher time learning another character's play mechanics. The counter-counter argument is that if they're playing a second game, then mission accomplished—they like our game to play another session. Furthermore, learning different aspects of a game can be fun, especially if we keep the play-card mechanic simple enough for people to pick up relatively quickly.

Mik came up with a fantastic method to develop a villain deck—instead of trying to create a villain deck beforehand and playtest to find that its not quite right, we're going to spend some quality time developing some sound hero decks, and then one person plays all the heroes while the other person plays the DM. After a few sessions, we'll try to find patterns in the level of difficulty that made playing fun, and then try to recreate an automated version of that. We're about halfway through developing the three characters, and I'm totally excited for that stage of playtesting.

One thing is for sure—bringing a story-writer on to the team was an incredibly valuable way to increase the fun of the game we're making. Mechanics only go so far to bring people into the game, and having something to work from makes the game feel so much richer than it did before.

Designing Fun Games

Designing a co-operative card game takes a significantly greater effort than I'd originally anticipated.

I'm surprised because I'd already anticipated it taking quite a bit. What's challenging about the Square Root of Steam (name subject to change) is that its not only a co-operative card game, but its style is different than any game that either Mik or I have played, and possibly any game that exists. We've had literally hundreds of ideas that we've discussed, scrapped, improved on, crossed out, and so forth. For anybody interested in developing a game that's both new and actually fun to play, heed my warning:

It is not easy.

I'm excited because I'm learning so much about the game design process. While I've learned around a dozen really important things, I can narrow it down to the four most important lessons so far:

1. Fun is the most important aspect of the game. This might seem obvious, but its easy to get distracted over balanced mechanics or making the game the right level of difficulty for the player. If a game is too easy but still fun? Great! You've made a successful game. That mechanic is not totally balanced with other mechanics but everyone loves it? You win. Don't be afraid to design something that you think "doesn't work" if the result is something that ends up being fun for the player.
2. Story and context of the game are incredibly important. I tend to focus on mechanics and balance over story and flavor, but sometimes even clunkier mechanics can be more fun because of the context you're playing in. For instance, the game Ladies and Gentlemen is clunky on purpose--but its very fun because its silly and ties in with the game theme. Mechanically excellent games with little story canend up being less fun simply because there's less context for the player to relate to.
3. Games are very rarely too hard. Games need choice, and choice requires making mistakes. Players should be able to make several sub-optimal choices and still succeed. If you're designing a game, nobody on earth knows the game better than you, and if you can't beat it without thinking, its probably too hard. See #1.
4. Playtest all the time, especially in the beginning. If there were a formula for "fun", we'd have found it and have made the perfect game already. Fun is about how the player feels, and no amount of well-thought-out design can make up for a quick playtest session to see how your game feels to someone playing it. You'll end up wasting way more development time than you need to by developing something that a simple playtest would have revealed isn't fun at all.

Again, there are other lessons, but these stand out most clearly AND relate to the things that I've been told over and over again in the EAE program. Hearing good advice and understanding good advice are two very different things, and I'm excited to be able to incorporate that advice into how I design games.

Producing a Small Children's Summer Camp

Yesterday was the last day of the Mobile Game Dev camp, and I'm really glad I did it. Not only was it great to work with Chris Rawson and Sherly Yunita, but it was a really great experience over all. About halfway through the week we talked to Roger Altizer about some of our problems, and he gave us some great advice that I pondered over the remainder of the week.

While some of the students in the class were getting everything I dreamed of out of the course, many of the students were spending the majority of their time playing Minecraft and browser games. I figured that it wasn't really my responsibility to babysit the kids to get them to learn awesome things with their time--if they wanted to waste their parent's money, so be it. Roger set me straight, however--it is absolutely my responsibility to get them to learn awesome things. Some kids will inevitably goof off--he noted--but every kid comes home with a birdhouse, whether it be crappy or awesome.

After thinking about it, this really represents a lot of what I do as a producer, as well. I don't have to care what team members do with their time, but I should because it determines the success of the product. My success as a producer isn't about how well I organize the people who are already working fantastically, but about how well I motivate the rest of the team. Nobody praises a coach for the star player on the team, they praise the star player. The coach is praised when the entire team performs well, and getting the team to perform well is exactly what I should be doing as both a producer and a teacher.

I learned quite a few other things during the course of the camp, including a teacher's worth of knowledge about Game Maker and a lot about productivity and setting ground rules. I didn't think that I would learn as much as I did, but in reality, children are just very honest versions of adults. If they're bored, they're not going to listen. If they're interested in something, they'll pay attention to it. Managing children's productivity takes the same kind of skills that I enjoy working on that it takes to manage a large team, and I'm really happy I got the experience.

Using Project Management Software Correctly

Yesterday I talked with Amy Adkins--former producer at EA Salt Lake--about her thoughts on project management software and how I can use it to be more effective in general, because I was having trouble seeing the use. After talking, its use became very apparent if any of the three conditions are met:

1. You want to organize the vision of the entire team by ranking the importance of different tasks in the development cycle.
2. Your team is on a specific deadline you have to meet.
3. You're working on a large/long-distance team, and need to coordinate the efforts of multiple people.

Project management software is first and foremost a tool to prioritize and coordinate the efforts of a team. With this ideology, project management software can be used for absolutely every project that has more than one person, because each person on the team has a different idea about what kinds of things are most important.

Producers have the job of ranking this priority not only in what should be done, but what can be done. If a team is on a specific schedule, project management software comes in handy to give an overview of the total time a project will take. Often, the choice to cut a feature has to be made after the schedule for a project has been developed and not enough time exists to develop every feature. When a specific amount of hours to complete a project are established, the price of adding new content and/or features becomes much more apparent.

While both reasons above have certainly applied to me in years past, it wasn't until working on a large team that the purpose of project management software finally hit me in the face. Working on a team with 10 or more people is significantly harder in all respects--there are that many more visions of the project you're working on, there are that many more priorities, and more specifically, there just isn't enough time for a single person to coordinate all the efforts of people by keeping up with them individually.

However, using project management software--like Hansoft--still seemed to take more energy than it was worth because nobody on the team bothered using it. Amy explained that Producers and project managers have a responsibility to create a team culture of checking Hansoft on a regular basis, because it can do an infinitely better job of coordinating team efforts than people can. When looked at from that way, I can get more team product per effort I put in if I spend energy creating that culture and updating software than I would putting it directly into managing people. It's not completely intuitive, but it makes sense.

I asked Amy to critique my use of Kanbanpad--project management software I'm using for 3colors development, and her biggest critique was that I hadn't organized things in terms of priority, but rather by type of task. That really resonated with me, and I quickly began to see what I was missing. Project management software is supposed to be a place where any team member can go and quickly assess the most effective thing for them to do for the project at any given time, and I changed the structure to reflect that.

Game Design Camp Using the Activate! Curriculum

Next week I'm going to teach a summer camp about game development to middle-and-high-school age students. It's going to last for the whole week, and they'll hopefully be able to walk away with a game that they've designed, made art for, and coded all on their own.

It's been a bumpy ride, and there have been two waves of teachers who have had to bail on the project, but this last week Chris Rawson and I met together to put together a curriculum using Colleen Macklin's curriculum from Parsons The New School for Design in New York City.

The course that we're teaching focuses more on creating mobile games than it does making games that impact our environment and surroundings. While I firmly believe that games can have a significant positive impact on the way people behave and act, we didn't end up using many of the green-oriented teaching points of Colleen's curriculum. This was partly due to the course content, but mostly due to learning about this ready-made curriculum too late in our class design process. For those who are interested, the Activate curriculum can be found here.

Our course focuses on three specific things: design, teamwork, and coding. The coding aspect of the course will be done in Gamemaker: Studio, and while this is far from even the most liberal definition of coding, it will likely be the first exposure to any sort of code for the majority of the students attending. Most important, Gamemaker is a product that the students can install at home for free after the course.

For the design aspect, we plan on borrowing heavily from the Design I course here at the University of Utah's EAE masters program. Not only was the class the most fun I've had in a classroom, but it also taught many of the principles that I now use on a daily basis. Things like brainstorming methods, paper prototyping, or refinement and playtesting methods are some of the things that we're going to use during the camp.

About halfway through the week, we'll break the 21 kids attending into 7 groups of three, and have them each design a forced side scroller in gamemaker. We're really excited to see what unique things the kids come up with, and for the chance to teach some of the principles that have helped us out while making our own games.

Increasing Team Productivity

I met with AJ today to figure out how we can increase productivity within the Co-Signers team over the summer. Co-Signers has--as expected--taken quite the drop since people are off doing internships and visiting their home countries. I know that we can get progress on the game despite difficult communication circumstances, and I definitely know that we have the production manpower to do it. Even with just AJ and I (Zac is interning at EA and Andrew at Ubisoft), two producers is more than enough to get a firm hold on team organization.

The main problem that we've encountered is not one that is unique to this summer. Certain members of the team are fantastic self-starters who will take a problem from the scrum backlog we've developed and work on it--as decided on in the team meetings we've tried to regularly hold. Other team members will volunteer for a category of tasks, but won't ever check anything out or do anything.

While I initially thought that this second half of engineers were just lazy and didn't care about the project, I've come to believe that they are just the kind of people that will be more productive if things are spelled out for them and more strict deadlines are given. Even though I'd like to believe that everyone is so motivated that they'd put working on Co-Signers before anything else, this is realistically not the case. Some people want to help, but just want to be told what to do, as well.

With this new theory, I sent out individual emails to each team member asking them how many hours that they could contribute to the project, and then followed up within 2 days. Everyone responded, and I consulted with AJ about the kinds of things that we can assign to different members of the team by breaking the tasks into much more granular-ized tasks that we can directly assign to members of the team.

I suspect that the days of team-wide "answer the call" emails are over, and we've entered the age of individual, task-and-deadline oriented emails to some of the team members. I don't necessarily like to act like a boss to team members, but after giving it some thought, I think that a boss might be what some members of the team need to meet their potential. In the end, a producer makes sure that the game is made, and might just be what has to happen to get the game done.

Gears and Steam First Playthrough

On Friday Mik came up to Salt Lake and we had our much-anticipated first playthrough of our card game--for now called Gears and Steam--even though the prototype was decidedly un-finished. I'm thoroughly glad we decided to playtest earlier rather than later, however, because not 5 minutes into the game, we stopped to talk about some of the things we were noticing, and we continued talking for a good 2 hours.

Immediately, things became apparent about how fun or not fun they were, and I was disappointed with how many things just weren't fun. The most notable thing was the "speed" mechanic. Initially this was a resource that would allow you to either play a card or use a power. Every player started out with one speed, which was the core of the problem. While "do one thing on your turn" was supposed to be what made the game simple and streamlined, it was frustrating because it became "develop your character or do something to fight", which was a decidedly un-fun choice. Furthermore, while neither of us started our hands with the extra action cards in the deck, it was very clear that having that card in your starting hand would be tremendously advantageous--so much so that we could both picture players thumbing through their decks to "coincidentally" put the action-getter cards close to the top of their decks. Not good.

Furthermore, the original idea of speed was far away from making the game simpler. Since you could use this resource in any time during your turn and it was an inherently flexible resource (we'd talked about using a speed to draw a card, as well), it made things more complicated, not less. The original idea was inspired by Ticket to Ride, where each player only chose one thing to do during their turn and moved on. While this concept worked beautifully for Ticket to Ride, our game was going to scale by adding more of these actions during your turn down the road. In this case, having 2 speed was not twice as complicated as having 1 speed, it was several times as complicated. Specifically, it was however many things a player could do with a speed brought to the power of how many speed that player had. If the player could play a card, draw a card, or use a power with one speed, thats a choice of three things. Now if they have that choice twice, they have an initial choice of three, followed by an additional choice of one of three things for each option of their initial choice. Having 5 speed would result in 243 combinations, which is more daunting than we wanted, especially for the vanilla characters.

Speed was our primary problem, but there were others, too. Since we had begun by porting character decks from other games to give us a starting point, the characters were not designed to work with the mechanics we'd developed. Specifically, we both found ourselves without sufficient outlets for the steam cards we were attempting to acquire. Furthermore, we found our hand size rapidly dwindling to nothing as we faithfully discarded our worst card at the beginning of every turn to gain steam to potentially use later.

Discarding the worst card of your hand to get something is not necessarily a bad thing, but we found that this just wasn't as fun as we'd hoped. Nobody wants to look at a hand of great cards and decide which one they want to axe for an activity they can only do once per turn (so you'd better not miss it). Furthermore, if there's a card in there that you'd prefer to discard because its not as great, why not just make that card better?

When World of Warcraft was in beta, the game slowed down hardcore players with plenty of time to dedicate to the game by lowering their experience rate after a certain amount of time. They called this "unrested experience", with the idea that your character wouldn't level up or learn as fast without some time to rest. It was received poorly, but the mechanic was sound, so Blizzard changed the mechanic to "rested experience", which instead gave casual players a bonus to the experience they got until the bonus was gone. This was applauded by players alike as a great mechanic, but in reality, the only thing that changed was the wording. Now, people feel like they're being rewarded instead of punished, and subtle changes in mechanics like these are what separates mediocre games from games that truly shine. I frequently refer to the unrested experience story in terms of player perception, and it was appropriate in how our game gave players the steam resource.

Instead of discarding a card at the end of your turn to get a steam, we decided on changing it to a choice of gaining a steam or drawing a card. Now, the player feels like its the end of their turn and they get to choose a reward. Ironically, this mechanic is actually worse for the player, because they don't get a chance to search for a better card and discard their worst, but we both agreed that it felt much better and rewarding.

Still, speed was quite problematic, and steam felt like an all-or-nothing resource depending on what kinds of cards you drew. To make the early game fun and not punishing for not having sufficient speed, we changed speed to a resource that would do more limited things: play a card, and rarely be required for abilities. Most activated abilities would now cost steam, but speed would still be the kind of thing that would only be used on your turn. Abilities that required speed would carry the unspoken question: "is using this ability worth sacrificing a card drop?" This question will be the question that we consider while designing new decks.

Steam mounted really quickly when dealt the right cards, which was a problem because you had 8-12 permanent steam cards that would untap at the beginning of every turn. There were a couple things we did to address this. First, we moved the untap stage to the end of your turn instead of the beginning. While neither of us had seen a game that does that, the location of the untap phase primarily affects when you want the players to save their resources. Players tend to use all their resources right before they're refreshed, would we want players to save steam on their turn so they can use it later, or save steam on other player's turns so that they can have an awesome turn? Additionally, having resources vulnerable from the end of your turn, through the beginning of other players turn, and toward the beginning of your turn gives each player vulnerabilities that the villains can target without saying things like "target resource does not untap normally during your untap step". Now we can just say "tap a resource" and you're not able to use it until the round after your next round.

Finally, we ended up changing what we called the resources. Steam was feeling more like something you got paid in, and we switched to calling that particular resource money instead. Everyone understands how some villains would target their money, but it was always hard to picture somebody targeting steam and making sense. We still wanted steam, however, so now the "play card" resource is steam instead of speed. Speed is gone, which is fine with me--I called it "actions" probably 80% of the time, anyway. Since we're calling it money now, we changed the way that it operates slightly: when you spend money, you don't get it back, and you now have cards that are "contracts"-- permanents that give you additional money per turn. Players can choose to draw a card or get a one-time pay at the end of their turn.

There were a few things that ended up working very well, like the doom-track method of attacks and villain draws. We were both stoked that that turned out just as well as we anticipated, and we're looking forward to really making some interesting things happen with it.

Developing Game Wrappers

I cleaned out and organized all my miscellaneous files from my computer and external drive this past week, which required an additional hard drive. As it turns out, the hard drive I used had a working copy of Sins of a Solar Empire on it--a deceptively time-consuming and surprisingly addicting RTS game from 2008. Anywhere from 90 to 130% of my freetime this week has gone towards playing that, so I'll probably make a couple posts in a row, here.

 I'm really excited about the progress of several of the games I'm working on, and I'll start with 3colors. I consider myself to be a pretty talented game designer in most things, and an absolutely abysmal designer when it comes to creating game wrappers. 3colors was no exception, as I was honestly considering having the game play out with just the colored circles that I made from the Youtube video.

Even though I know that I would have been happy with that game, base mechanics with no story are not what make excellent games. They make excellent prototypes, and that's what I had. In my mind, the prototype involved matching things in your bank to things on the board, so I tried for quite some time to think of a wrapper involving that. What kinds of things could be in the bank that would make sense to match on the board? Food? Monsters? Animals? AngryBirds? At the time, I had quite the list of things of things that one could match up, but none of them seemed to work because they would all be randomized in the bank. If your foods were peanut butter, jelly, and bread, then what happens when you have bacon, lettuce, and tomato? Would you end up with peanut butter and bacon (potentially delicious)?

Instead of having sets of things that match, I moved on to random things, like monsters or animals. If these groups of items are random, however, why are you matching them? Why are you matching 2 dogs and a cat? Thus, my problem: going towards sets of things wouldn't work because they would mis-match in the randomizer, and going towards random things wouldn't work because it would never make sense why you were matching totally random things.

I was stuck, so I talked with Corrinne Lewis--one of the EAE advisors--about what kinds of wrappers I could develop for the game. Her approach was excellent, and the core concept of this blog post: Instead of trying to think of a wrapper for the mechanic that I couldn't get to work, try to find a different core aspect of the game to base a wrapper on. Good games tell a story, she said, and you need to find a wrapper that explains the mechanics so that people will understand your game faster than handing them the prototype.

What is the core mechanic of your game that you want to use a wrapper to convey? Clearly, matching isn't working, so she suggested exploring the "capture" aspect of the game. What kinds of things are people used to capturing? Territories, like in Risk? Companies, like in Acquire? What about capturing ships? Now you're playing as a pirate, trying to capture all the ships on the "ocean", and each ship has a different sail that changes when you double capture it. Excellent.

I shared this with the team, and Derek Higgs--one of our engineers--suggested using Tiki masks that flipped upside down when you captured or un-captured them. This led to what our game is now by showing a new core mechanic: toggling a grid of points. I'd never seen this because I went too narrow in my initial design by calling this action a "capture", which limited the design space of what we can tell a story about. Now that we were thinking about flipping things back and forth, it was a short walk to come to flipping different colored turtles from off their backs. Its satisfying, its something that everyone can relate to, and most importantly, its a wrapper that enables people to understand the mechanics of our game far faster than anything else could.

I'm excited because its the best wrapper-creation process I've been a part of, but also excited from the lessons that I learned from it:

1. Explore several different core mechanics of your game to develop a wrapper for, don't get stuck on one that isn't working, and
2. While making a prototype, always describe things in the most generic way possible. Un-necessarily defining things limits the creative ideas of how to describe the game later on.

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.


 

Game Story Dev

High time for an update on the Co-Signers!

Engineering progress is going very well, AJ is particularly on top of the scrum process. Today was definitely a success, all the things we'd planned to do were accomplished, and we're moving right along to sprint 2.

In class we took an hour to listen to Craig Caldwell's--one of the EPs in the program--presentation on story. He spent a lot of time talking about good story arc design and different ways to keep an audience captivated and interested. Although most of what he said related to movies, we managed to start talking about how his presentation could relate to the backstory of the Co-Signers. As of now, our backstory is pretty weak.

I feel like I'm significantly stronger at making enjoyable mechanics for a game, but the farther I get into this program, the more I realize that thats a relatively small portion of video games. Style, story, charm, and feel appear to really make a game stand out, regardless of mechanics used. The mechanics probably have more significance in video games than I'm giving them credit for, but they're easy, and thus easy to dismiss.

Thus, after Craig's presentation I again embarked on a task that I feel I'm relatively poor at: making a cohesive story within the constraints. This time, things were a lot more successful than creating story for Ludology, and we had probably 5-6 interested people all pitching in ideas. Additionally, we were armed with different story arc construction tactics that made our job easier as well.

As of now, we're thinking about having the Hacker be a long-term, middle-management employee who worked at the DoE but was fired after blowing the whistle on long-term ongoing corrupt policies that happened to take advantage of a student who would eventually become the Thief. When the Thief is faced with mountains of debt and no diploma, the Hacker calls the Thief and convinces him to break in. Throughout the game, the Thief discovers that these practices have been ongoing, and the Hacker was aware of both the practices and the Thief's plight. The game ends with a prisoners dillema, where both players choose to either encarcerate or side with their companion without knowledge of what the other is choosing.

The thesis of the game is to promote trust between two players, and so far this story does just that. Regardless of the final story that we end up with, we're still struggling with how to convey this information to the players. The team we were talking with were kind of split between text files found in-game and intra-level cutscenes. Personally, I'd like to go for in-game voice-overs that explain what the Thief or Hacker character is thinking and communicating to the other person.

One thing that I got from Craig's presentation was that good stories come after quite a few iterations, so I'm prepared to think about this quite a bit.

That is, quite a bit before the remaining 3 weeks of the semester are over...

GDC

Five weeks!!

Holy guacamole, time flies by really really fast.

Last week I attended GDC, and it was pretty incredible. I learned a lot, like what kinds of things game companies expect in producers, what kinds of things make you stand out, and how to carouse with important people without compromising my personal values.

All in all, it was a great trip.

A particularly great aspect of the trip is the reaction we got to the Co-Signers. Nearly everyone we talked to about it thought it was an incredible concept. Before the trip we had a mid-production crisis on the team, where a lot of the engineers wanted to switch the game to UDK instead of Unity. We had the entire team talk to engineers and designers while at GDC, and the feedback that we got isn't only that UDK was a bad idea, but that Unity is a great idea.

Thus, we're going with Unity.

It's full-steam ahead on the Co-Signers, and we only have four weeks to get to alpha. To be blunt, this would be a lot simpler if every class period wasn't chock-full of sharing time by the EP's.

Adventurers Gameplay

I mentioned that I'm going to be blogging a lot today, only partially to help me stay awake.

Last post I talked about the game design theory and the approach Mikael and I are taking towards our new game, at this point called "Adventurers".

Don't worry, that's a working title.

For the sake of posterity, I'd like to talk a bit about some of the mechanics we came up with, where they came from, and why we chose them.

Adventurers is a co-op card game with an automated dungeon very similar to Sentinels of the Multiverse. One of the things that we didn't like about Sentinels was that the game ended right as your character was starting to get awesome. In and of itself, Sentinels is a game that borrows heavily from Magic the Gathering in terms of several different streamlined decks with mechanics that play off well from other cards in their respective decks. It also borrows from the co-operative aspects of Dungeons and Dragons, except the dungeon master is replaced with another pre-made deck that flips over the top card during the "Villain" phase.

The game is awesome fun. Furthermore, its simple enough for our non-game-playing significant others to play with us.

The idea of this game was born when Mikael noted that Sentinels would be really fun with a campaign mode where your character would get stronger between rounds--a little more like Dungeons and Dragons.

D&D has a stigma, however, and Sentinel's biggest gameplay value is that its incredibly simple, yet can become complex. To add the level building feel of D&D, we added a Diablo-esque aspect of loot to your characters, along with addable/customizable stats--also in the form of cards.

The idea is that the game is 100% card based, because we loved the fast setup/cleanup time of Sentinels. For neutralizing certain cards out of the Campaign (Villain) deck, you're awarded an experience draw. An experience draw will be 2-5 cards from a pre-made pile of cards for your specific character. These cards could be anything from a special ability that comes immediately into play, or a piece of equipment that your character uses immediately and starts with at the beginning of the next round. For customization, your character can only choose 1-2 of the cards that you drew from your experience draw.

At the end of the round, the cards that you chose for your experience draw go into your deck, and become a stronger part of the deck that you started with. Depending on what cards you choose during your experience draw, your deck could become more spec'd toward, say, damage dealing--instead of choosing things that would make your character tankier.

One of the principles that we're trying to stick to is giving a large amount of restrictions to the player initially and then supplementing that with releases to those restrictions. For instance, Sentinels limits the number of cards you can play by allowing only one played card per turn, and Magic the Gathering limits your play to the amount of mana cards that you have out at any given time. Adventurers will use a stat-based resource system, which will all be in front of your character at the start of the game.

For instance, lets say that your character is a support-mage. You have 30 Health (3 spec points), 7 Mind (7 spec points) and 2 Strength (2 spec points). To use your "Heal" ability, you need to expend 3 Mind. You tap 3 Mind as many times as you want to use Heal--lets use Heal twice. Finally, you use "Light Punch" for 2 Strength. You now have 1 untapped Mind, 6 tapped Mind, and 2 tapped Strength. At the beginning of your next turn, you could choose one card (either Mind OR Strength) to untap.

Of course, only being able to untap one stat per turn would be ridiculous. The equipment that you get throughout the game will do things like allow you to untap additional stats, or lessen the costs of the abilities you're using. During your experience draw, you can choose passive cards that have a chance of coming up during your normal deck draw that also alter these mechanics further.

To compensate for these new mechanics, we've removed Sentinels' environment and put all hazards into the villain deck. Adventurers will have campaigns of sizes anywhere from 1-5 games, and every level of the campaign will use the same deck. Each level of the campaign will have a different "Boss" card, which change the ways the cards will play in the same deck.

For instance, lets say we have a 3-round Goblin Invasion Campaign. The deck might include several one-shots that do damage to heroes and Goblins that attack the highest HP hero every time. For the level 1 scenario, the Boss doesn't change any mechanics, and attacks all heroes for 1 HP every turn. The level 2 Boss would have more health, attack harder, and change all goblins so that any time they would attack the hero with the highest hit points, they hit the hero with the lowest hit points instead. Level 3 Boss might be immune to damage as long as there are less than 3 goblins in the trash, pulls one goblin out of the trash any time he deals damage, and heals for the same amount that any goblin deals damage for.

The above scenario was just something off the top of my head that shows how the "goblin" card in the campaign deck could be enhanced depending on what stage of the campaign you were currently on. Each campaign deck comes with a Treasure Deck, which the players flip over for defeating certain monsters in the Campaign Deck. Treasures will only be permanently equip-able items (to allow for ease of clean-up by keeping the backs of the treasure cards unique) that can be given to any of the heroes in the campaign. Until this item is replaced, it will remain a starting item for that player and occupy its appropriate item slot (ie, helmet, boots, gloves).

Finally, to replace the environment, a simple time-of-day mechanic will take its place. This will mostly add flavor by making it feel like you've been fighting for days within the course of an hour, and subtly influence certain effects. Thus far, the phases are morning, noon, evening, and sleep. Most of the time the villains and players rest during the night phase, and can untap two stat cards instead of one. Certain campaigns might take advantage of a time of day, like--for instance--the Troll Campaign, where the Trolls do no attacks during the morning and noon phases but flip over two cards each in evening and night. Each round of play would take one time-phase.

The game obviously needs a lot of work, but its amazingly fun to design. There are certainly things that will be axed, and certainly things that will be added, but we're happy with the core gameplay that we've come up with.

Simple Design in Games is Critical.

This is a game blog, and I don't really feel like it has to be exclusively about the games that I make in the EAE program.

That being said, I really want to talk about a side-project that I'm working on: a co-op card game/dungeon crawler. For lack of a better name, we're calling it "Adventurers".

I say "we" because myself and Mikael Fehlberg--an extremely avid competitive game enthusiast--are going to start working on the game on Mondays from here to completion. I made the mistake of staying up until 4AM last night discussing the fundamentals of the game, and now I'm forced to blog during the last 3 hours of my 12-hour-Tuesdays just to make sure that I don't sleep through Game Engineering II.

However, it was totally worth it. We're starting by borrowing from several of the games that we already know that we love (eg Sentinels of the Multiverse, Dungeons and Dragons, Magic the Gathering, Diablo) while adding some new things that make it unique as well. Even though everyone wants to make a game that's completely new and unique, thats silly for two reasons:

Reason 1: Making a new game has no audience. Completely new formats will have trouble attracting people, because they cant relate to it at all.

Reason 2: While its entirely possible that a totally new idea could be fun and polished, its very improbable. There are literally hundreds of games that just aren't any fun at all because they try too many new ideas at once. Games are like science experiments, you should only change one variable to determine if the new idea you have is fun or not.

That being said, don't think that we're squashing creativity to make sure that our game can be easily understood. On the contrary--we're spending most of our design time simplifying our unique mechanics in such a way that the game can be learned quickly and still be rewarding for experienced players. There's way more time than an uninitiated game-designer might first guess that goes into making sure that the game design is simple and understandable. Making games is really fun, but anybody can make a game stupidly complicated and fun. It takes real effort to make a game that is simple and fun.

Self-approval

For those who might be looking for it, I should include a link to the Team's Blog:

http://teampriapus.blogspot.com/

Our presentations to the industry panel was pushed back another week, which I don't enjoy. I want to have a team meeting regarding organization and structure of the way that the team goes, and it doesn't make sense to do that twice in a row. Once the industry  panel cuts games from the list of games that will actually go forward, we may find ourselves with several more people on our team that will definitely need to be part of that meeting.

That reminds me: For this post, I'd like to talk about my feelings on being cut or going forward. I feel that our team has had the least amount of approval in terms of what the game is at this point. We're a 3D physics platformer where you're the character of a game thats trying to put his game back together, formal element by formal element. To be really honest, I feel as if the EPs (Roger and Bob mostly) have stopped fighting us just because we need to have a game to present.

Regardless of whether that's true or not we do need to have a game to present, so if my hypothesis is correct they're probably acting wisely. I dislike how that approach breaks the studio simulation, but this is an education first and a simulation second. Having a game they approve less of might be better than having a game that they're in love with...in March.

Whether or not their approval is coming our way, I feel that our game is exactly what it needed to be. It's exactly the intersection of almost every thing we were told needs to be in the game. That includes something that I didn't consider before: personal passion. The game now involves education about games in general, and the educational value of games is something that I've been passionate about even before I came to the EAE program. Our game is fun, in-scope, unique, student-y, and impressive.

One thing is for certain: I'm confident that our game is excellent, and I can go into the presentation a week from today feeling extremely confident that our game will be picked.

Education in Creativity

I'd like to spend some time reflecting a bit on the history of the game pitches that we've had and how we've got to the point where we are, because I've learned an incredible amount. I feel that our team is in the unique position of building a game off of a proven, fun mechanic instead of an idea. While other teams have been struggling to make the implementation of their interesting idea fun, our team has been struggling to make the idea of our fun mechanics interesting.

This is not what I expected to learn, but it's exactly what I needed to learn.

I spent time talking about the current iteration of the game pitch today with Zac (who has a brand new baby as of this evening--grats!) who told me that they're focusing on making their game into something that's both rewarding and fun for both people playing. I feel that my strengths are in tuning a certain game to be fun, and with a solid idea behind me I could turn even a game about Thermodynamics with mandatory calculation into something that would be fun to play.

Aside: STEAMship WAS awesome. I was genuinely happy with the final iteration of that game.

Back to my conversation with Zac: I expressed to him that I would much rather be in his position, because I feel like I've been put in the one situation that I was completely unprepared for. I told him that this entire experience of making a thesis or an idea around this game has been amazingly frustrating akin to a poor game of 20 questions, where the script would go something like:

Roger: This game doesn't have a solid hook, nobody will care about this game.
Jake: We've thought about a topic that we think is interesting enough to make a game around.
Roger: That topic has nothing to do with your mechanics.
Jake: We've come up with a way to incorporate our topic into our game
Roger: You don't really care about that topic, get something that you're really behind.
Jake: We've come up with an idea that we're all passionate about.
Roger: That idea isn't a game, it doesn't sound fun.
Jake: We've found a way to make this new idea fun.
Roger: That game doesn't have a solid hook.
Jake: We've not slept trying to think of a game that could possibly fill every requirement given to us on this, and have come up with an idea that we think will work.
Roger: You're thinking too hard about this.

Really, it feels like I've spent the last 4 years as an undergraduate in Mechanical Engineering being trained to think a certain way and I've been trying to undo it all in the last 4 weeks. Thinking a completely different way is amazing, educational, and rewarding--but incredibly difficult nonetheless. I didn't think you could learn how to be creative, but I think that this program is as close as I can get to an education in creativity.

Games first, story second.

I talked with Roger yesterday about some frustrations that I've been having with the game that we're designing, and after a good night's sleep, I think that I've really figured out what kinds of things need to be done.

For those of you that are not Jake Muehle, I was frustrated that Roger would consistently comment that the game was not focused enough, too broad, or he didn't care about some of the thematic elements that we picked--namely, bullying. Every time Roger talked (and disapproved) of what we had come up with, I felt as if the game got less game-like and more towards this nebulous "edginess" that Roger seemed to want out of a student game.

On a trip over to the MEB, I expressed these exact frustrations, and Roger gave some great tips on what we needed to do. We've been trying to make our game "student-y" through the thematic wrapper, where our game is not actually a game yet. Our game was based on the concept of "pushing stuff around is fun", but then we tried to make a game out of it by adding a story. Roger suggested that we give the story a break and think up pure games that would be fun given our entertaining mechanic.

After sleeping on it, this advice seems so obvious I feel like an idiot. This is why I came to EAE, THIS is why I switched to being a producer--I'm great at making games. I got so caught up in the seemingly required edginess that I didn't even stop to think about what the most important part of games were--making them a game. Story follows behind making the game fun. I can't believe I didn't come to this on my own.

One other thing that's been surprising to me is how effective the "late mark" system is. It's just a bunch of tally marks on a sticky note on people's computers, but everyone seems to try *really* hard to be on time to avoid them. That might be because people are so devastated to receive them, as I've been making a habit of giving out late marks no matter how awesome the excuse--if you're late, you're late. Another tip-of-the-hat to mission organization theory--if you record your progress, people perform better.