Let’s Design a Game #12 The Death of a Game

If the lack of update regarding this series didn’t give it away (or the title of this post for that matter) Who Are You Working For is Dead.

And I want to talk about why and what I learned from it.

When we finished the first playtest of this game, the flaws were many and obvious. Part of the problem was the amount of time between me wrapping up the prototype build and the first multi player test of the game. I fumbled my way through the explanation of the game and even as I was explaining how the game worked, I could see the weak points.

Honestly, it was not a fair playtest to judge the merits of the game.

What I saw right away were the mechanical weak points; I did not see the weak points of player motivation and the way savy players can exploit the bidding system.

When we started to play the game, the board felt “samey” and trying to figure out what rewards were worth the effort to pursue was difficult. There was too much information for players to consume and that prevented players from getting into the game.

The game was a block to itself.

When we starting to bid on contracts, players had enough options to allow for everyone to take their own path, simply put, there were not enough interaction points.

I think the theory of the game is sound, but I don’t think the “real life gaming motivations” of the players works with the theory of the game. A theory that sounds like a lot of fun in my head doesn’t mean it will translate into a lot of fun when it is on the table.

The feedback provided was warranted and all over the place.  Now, if this blog and the podcast are any indication, giving up on a design is not my style. I think a design can be worked, fixed, replayed and made into a great game.

So why is this game dead?

It is a matter of logistics, focus and what this game will look like if it is ever completed. We have a long list of ideas that range from game ideas to websites and apps. When I started this design project, my plate was smaller and easier to manage. Now, we have a new game we are focused on, I have other projects going during the week and the attention this game requires right now does not fit into the weekly to-do list. I also think this game needs a complete overhaul of what it looks like and how it performs. As previously stated, the theory is good (IMHO) and I want to make it work. The mechanics of the theory need to be streamlined.

In reality, this game is not dead, it has been reprioritized in the stack of ideas waiting to be worked on. It might be years until this game makes it to the top of the stack, but it is there waiting to be worked on.

With that, here is the major lesson I took away and want to share with others. Don’t be afraid to let go of a design. Put it back in line and move on to the next project. Aidan and I have talked about this regarding other projects we have worked on which we had to abandon. He puts it in a great light when he says, and I’m paraphrasing here, “There are times when the technology for a project does not yet exist. In the case of games, that technology is the experience or mechanic or theme we have yet to discover that will allow us to make sence of the experience we are trying to build.”

That gives me great comfort that the projects we have to “abandon” will have their chance and allows me to move on to the next project.

What Next?

I want continue the Let’s Design series, but I will pick a smaller game to design. I also want to add an audio element to it. I may even adda  video element to it but I have some figuring out to do for that part. The google doc will stay alive, waiting for an update.

Please feel free to visit the Google Doc of this project.

Find us on Twitter (Follow Us!) and Facebook (Like Us!)

If you have any comments or questions, leave a comment here or email Chris at c.renshall.tgik.games@gmail.com

If you have made it this far, would you like to go a little farther? We have a regular Google hangout with other designers. We talk about the games we are working on and share helpful tips and ideas on how to make designing our game easier. We meetup every other Saturday. Either comment here or tweet me or email me and I will add you to the list and send you a link to the Google hangout.

Let’s Design a Game #11 Random Thoughts…Major Problems and 2 Players

This post out of order but it is part of the process so I am going to insert it here and give you fair warning.

The first time I talked to Aidan about this game, I dawned on me that we have a real problem with two players. Players are going to know, just by looking at the open contracts, who is the owner of which contract. The other major problem we had at the time was how we were going to handle the agent side of the bidding process.

The entire time I was thinking that one player would be working on one job. It never occurred to me to have all the players in the game have agents working the same job. I was thinking about how to get a contract owner to accept specific agents without giving up their identity. This was a major issue because the whole idea of the game is to not know who you are working for. I honestly thought the game was dead.

At the time these issues came up. I was a few days away from figuring out the solutions. The two player problem is currently solved with a couple random cards drawn from a dummy hand. The agent problem, as you have seen in a previous post, has been solved with the use of player specific tokens and allowing all agents supplied to a job to participate in the job.

What I would like you to take from this is that I really thought these were game breaking problems when they came up. I was not sure we could come up with a two player variant, nor did I think the agent bidding problem could be solved without changing the entire concept of the game. Yet, the solution to both of these problems is as easy as a couple more cards to throw people off each other’s tracks and a simple token for each player.

There might be some major issues that come up during and after testing, but there are solutions out there to the problems we face in our games and the willingness to look for and find them can solve most of the problems out design will face.

Please feel free to visit the Google Doc of this project.

Find us on Twitter (Follow Us!) and Facebook (Like Us!)

If you have any comments or questions, leave a comment here or email Chris at c.renshall.tgik.games@gmail.com

If you have made it this far, would you like to go a little farther? We have a regular Google hangout with other designers. We talk about the games we are working on and share helpful tips and ideas on how to make designing our game easier. We meetup every other Saturday. Either comment here or tweet me or email me and I will add you to the list and send you a link to the Google hangout.

Let’s Design a Game #10 The Agents

Today we will give you the details on the agents.

2015-06-22 16.47.55
Agent Spread

Currently there are 48 agents in the game. Agents are used to pass skill checks for contracts and act as a way to boost die rolls.

Agent Card
Agent Card

Each agent has one of three skills. Those skills are Planning, Execution and Get Away. They also have a roll effect. Roll effects are used whenever a player rolls a die and they want to boost a poor roll. In the top left corner, each agent has a cost. The cost of each agent is the amount of money a player will receive when one of their agents is used in a mission/contract and they are successful.

Pending Mission
Pending Mission

Agents are used to pass skill checks and in the example above, you can see that the base level skill checks for this region are 5 Planning, 4 Execution and 5 Get Away. Add to the base level the checks required for the card and you end up with a total skill required of 8 Planning, 7 Execution and 8 Get Away.

Agents On A Mission
Agents On A Mission

Let’s assume these are the agents that have been accepted by the contract owner and they are about to attempt the mission. Each agent will roll a die, add their skill, combine that with the roll and skill of any other agents working with them for that particular skill. If this total is larger than the skill check required, the skill check is passed. If all the skill checks are passed and the mission is a success.

Mission Rolls
Mission Rolls

The six agents on this missions rolled really well and rolled an 18 Planning, 13 Execution and 12 Get Away. The contract owner would reveal who they were to collect the reward and the contract owner would then have to pay all the agents in the mission. In this case, the contract owner would have to pay $40K in agent costs. Some of the agents could have been their own but this was an expensive mission. There were a lot of dice rolled and the chances of the mission being successful were high, but that comes at a cost. You can try to use few agents to lower the cost, but risk the mission failing.

As always, if you have any questions, feel free to contact me. I know the explanation is fragmented, but I want to divvy out the game in pieces as not to throw out too much at one time and give people a chance to digest the pieces as they are released.

Please feel free to visit the Google Doc of this project.

Find us on Twitter (Follow Us!) and Facebook (Like Us!)

If you have any comments or questions, leave a comment here or email Chris at c.renshall.tgik.games@gmail.com

If you have made it this far, would you like to go a little farther? We have a regular Google hangout with other designers. We talk about the games we are working on and share helpful tips and ideas on how to make designing our game easier. We meetup every other Saturday. Either comment here or tweet me or email me and I will add you to the list and send you a link to the Google hangout.

Let’s Design a Game #9 The Main Mechanic, Revisited

 

Even though there has been a lot of progress on the game, I need to update you on the main mechanic because we made a change to the way it works and I don’t want to cover anything else until you have a chance to see it. For specifics, please see the previous post about the Main Mechanic since I don’t plan to cover the main mechanic in great detail in this post.

Players will start with the same set of contract cards

Starting Hand of Contracts
Starting Hand of Contracts

 

Players will also have a set of contract ID cards.

Set of Contract ID Cards
Set of Contract ID Cards

Above are the contract ID cards which include one card for each region and a set of numbers 1 thru 8. Players will be able to ID the contract(s) they turned in using these cards.

Players will now select one of their contracts to give to the collector. They will also set aside, face down, the ID cards that match the contract they turned in.

Contract and ID Cards
Contract and ID Cards

The contract collector will shuffle the contracts and display them in the middle of the table

Turned in Contracts
Turned in Contracts

Now that the contracts have been shown to the table. Players will start playing agent cards for the various contracts and accept or deny cards.

Contracts with Agents
Contracts with Agents
Close Up of Our Contract
Close Up of Our Contract

When players place an agent on a job, they will use a token to ID which agents belong to them. Players can play more than one agent on a job.

Accept/Deny Cards
Accept/Deny Cards

When a contract has 4 accept/deny cards played on it, the A/D cards are revealed, if there is an accept card, the job is attempted. If all the cards are deny, players take their agents back and the and the A/D cards are held until the end of the round.

Looks Like We Have a Job
Looks Like We Have a Job

Prior to this method, we were worried that players might forget what mission was theirs and two players might claim the same contract. Our plan was to test the game as it was and see if that was really a problem. While we were talking about this game this past weekend (6/12) we came up with this solution and I spent the rest of the weekend working on changing the prototype around. There were a few other changes but I will cover that in a later post.

As always, feel free to check out our google doc and leave us comments or questions.

Link to the Google Doc for this project

Find us on Twitter (Follow Us!) and Facebook (Like Us!)

If you have any comments or questions, leave a comment here or email Chris at c.renshall.tgik.games@gmail.com

If you have made it this far, would you like to go a little farther? We have a regular Google hangout with other designers. We talk about the games we are working on and share helpful tips and ideas on how to make designing our game easier. We meetup every other Saturday. Either comment here or tweet me or email me and I will add you to the list and send you a link to the Google hangout.

Let’s Design a Game #8 Checking in With Aidan Part 2

We spent most of the time talking about the main mechanic, but the benefit of working with a co-designer are the ideas that can spawn and being able to talk about them immediately. Aidan had the idea to change the agents and the contract owners to just colors. There would be many colors for players to be and their identity would be hidden until they were done with that color, think Small World and setting your race into decline. As jobs were being completed, the contracts and the color owner would be set to the side and displayed for everyone to see. Players would not be able to collect on the jobs until they revealed who they were. Players could have agents they are upgrading over time so they need to balance how much reward they take in vs how fast they want to upgrade. I guess there would also have to be an incentive to let your jobs ride.

The game idea aside, what I want to get across is the generation of a new idea and how excited we were when we started talking about the new idea. We would not jump off the current project to chase the side ideas, but we make notes, talk out the idea for 10-15 minutes and set it aside until we get around to looking at it.

We did talk about the worker placement idea (#6) and we were both excited to start working on the game. I think what that means is I will start developing the worker placement game in parallel with “Who Are You Working For?” (I guess I just working titled the project) If that sounds like a lot of work, there is a lot of down time gaps in projects. As soon as one game is ready for testing, I need to develop other games. My only real concern is being able to keep up with a blog schedule for two games. There could be times when I make some great development progress on one game and have tests going on with another. I don’t think it will be a problem in the end, but the thought still crosses my mind.

Link to the Google Doc for this project

Find us on Twitter (Follow Us!) and Facebook (Like Us!)

If you have any comments or questions, leave a comment here or email Chris at c.renshall.tgik.games@gmail.com

If you have made it this far, would you like to go a little farther? We have a regular Google hangout with other designers. We talk about the games we are working on and share helpful tips and ideas on how to make designing our game easier. We meetup every other Saturday. Either comment here or tweet me or email me and I will add you to the list and send you a link to the Google hangout.

Let’s Design a Game #7 Checking in With Aidan Part 1

The best part of being part of a design team is having a co-designer to check in with when you are working on a separate project. I took what I had on my white board and what I had made so far of the alpha prototype and walked Aidan through the game. We focused on the bidding mechanic right away as we both identified the bidding mechanic as the most interesting part of the game. While I was explaining the full game concept, I did mention that the first iteration  of the game used a hand of cards moving around the table. I talked about what I liked and didn’t like about the idea of a hand that moves around and while Aidan kind of liked the idea at first. I expressed my list of concerns with a hand of cards that could be dropped of lose its order and we both agreed that we need to find a better way.

Keep in mind, the main mechanic I wrote about earlier was not set in stone at this point, we were exploring all of our options.

We looked at the idea of having players turn in two cards, one would be the contract and another would be an identifier card. All players would turn in their pair of cards to, what we were calling, a “coat check” player. The Coat Check would have to shuffle the pairs of cards and display the cards on the board. We didn’t like this because the cards could easily get mixed up. We thought about making the Coat Check a player that would know who turned in what contract. They would not be allowed to bid on that set of contracts and the Coat Check player would have to rotate every turn. I didn’t like this idea because players would have to take turns watching the action and I don’t like it when I have to do that in games, so I will do everything to avoid designing a game that does the same. We talked about using envelopes for players to turn in and having one player open and reveal the contents of these envelopes. While that system could work, I did not like the idea of having a component in the game that could break down over time. Especially with hearing stories of Sheriff of Nottingham bags that are starting to lose their snaps, I wanted to pass on the idea of using envelopes.

We continued this back and fourth for at least an hour. What we really liked about the mechanic was the hidden identity and the reveal moments after a job was completed. We also decided that the bidding system, as it stood, was good to move on to testing and it would be used to complete the rest of the alpha prototype. The only problem we saw was the chance the a player could mis-identify their contract, but the amount of time from turning in a contract to seeing it back on the board was so short, we are thinking that players will be able to remember.

Moving on from the main mechanic, we talked about how we would handle agents. We talked about using a die for each agent and players will be placing agents on contracts and use those die to roll skill checks. What worried me was the idea that the cost of the game could get really high if we have a lot of dice in the box. If we had scale orders, this would be less of a concern but we are two guys in a kitchen so we are ultra aware of component cost. We also talked about adding an authority track to each region of the board. This was really fun because we liked the idea of adding risk to players should they fail a mission. We still need to work out how the authority track will work but we know we want to add the idea.

The last big thing we talked about was players motivation about why they wouldn’t always bid on their own contracts. Aidan brought it up and he was right, why wouldn’t a player do that? The best solution I had was the idea to give players tokens for completing other players missions and making the penalty really bad if players attempt their own mission and fail. Thematically speaking, if your own agents fail and get questioned, it is really easy for the authorities to track you down. If agents have no idea who they are really working for, you are safe.

That was half of what we talked about and in the interest of space, I will leave the rest to a second post. Thank you for following along and please feel free to check out the Google Doc below.

Please feel free to visit the Google Doc of this project.

Find us on Twitter (Follow Us!) and Facebook (Like Us!)

If you have any comments or questions, leave a comment here or email Chris at c.renshall.tgik.games@gmail.com

If you have made it this far, would you like to go a little farther? We have a regular Google hangout with other designers. We talk about the games we are working on and share helpful tips and ideas on how to make designing our game easier. We meetup every other Saturday. Either comment here or tweet me or email me and I will add you to the list and send you a link to the Google hangout.

Let’s Design a Game #6 Picking a Theme

I start 98% of our games with the mechanics first. I have tried to make games with the theme first but I find that making mechanics fit to a theme is more painful than finding a theme that fits a mechanic. Part if that could be the way Aidan and I work, it could also be my feelings that the worst that could happen to a developed mechanic that never finds a theme is the mechanic sits in storage waiting for the right theme to come along. We still have an asset at the end of the process. If we fail to find a mechanic for the theme, the opposite is true, there is nothing left over at the end of the brainstorming session.

For this project, I knew I wanted to go with a bad guy theme. I did spend a little time thinking about potential good guy themes but the idea that you don’t know who you are working for lends itself to the bad guy side. I did not want to do fantasy or sci-fi with this because those are overdone themes and we already have a couple projects in that space. With all of these “limitations” I ended up with robbers in the city stealing things for other bad guys. This may not be the theme we finish with, but it makes the most sense. Also, everything that I want to do with the game, at this point in time, fits within a universe of robbers and bad guys doing what they do in a city.

Please feel free to visit the Google Doc of this project.

Find us on Twitter (Follow Us!) and Facebook (Like Us!)

If you have any comments or questions, leave a comment here or email Chris at c.renshall.tgik.games@gmail.com

If you have made it this far, would you like to go a little farther? We have a regular Google hangout with other designers. We talk about the games we are working on and share helpful tips and ideas on how to make designing our game easier. We meetup every other Saturday. Either comment here or tweet me or email me and I will add you to the list and send you a link to the Google hangout.