January design update

Continuing the new monthly update format. This time, because a lot of them don't have updates I'm going to have two parts. The first part is for games that have NOT been updated. This will just be a list of links back to the last blog update that includes that game. The second part is for games that actually have an update this month.

Entering Contests

The Game Crafter runs a number of Challenges (i.e. contests) every year, and for the most part, I've ignored them. Usually, because by the time I notice one I'm interested in they are just about finished and so I don't have time to design something for the contest. Right now, there are three contests running that I'm interested in. And I have designs mostly "ready" for two of them, and an idea for the third.

Surrounded with a Shotgun - new weapons?

The decision has been made at VPG to treat all games like potential Kickstarter productions. That is to say, that in development we have to consider what kind of stretch goals may make sense with the game.

So now, I'm considering what can be added to Surrounded with a Shotgun as stretch goals. It is proving difficult, especially given that I personally really don't like the concept of gameplay exclusives.

Unfortunately, given the game's components, there aren't a lot of non-gameplay exclusive options that make sense. Which means any exclusive will likely have to include a gameplay element. So, I've been giving that some thought.

Surrounded, with a Shotgun (SwaSG)

This game started its life as a joke. A few years back, during an office Christmas party at Victory Point Games, we had a gift exchange. And not just a gift exchange, but a white elephant gift exchange. For us, that meant humorous gifts primarily. My entry into the exchange was a completely untested, and as a result very broken game called Nate's of Siege. Nate's of Siege was basically a zombie game in which the player was trapped in the VPG office and being attacked from all sides, but instead of zombies the player was being attacked by hordes of Nates. It was a Natepocalypse.

General Update

So, it has been a while since I've written a blog entry. Which is mostly unacceptable. Yes, life happens sometimes, but that is kind of a shallow excuse. In any case, I'm going to try to correct that going forward by doing updates in a more scheduled fashion. For now, let's say every Monday at noon pacific. Because that's my day off. We'll see how I do with that.

To start this new schedule off I'm going to give a general overview of a selection of the games I am currently working on. This is as seen from space kind of overview, so details will be a little scarce but should give an idea of the games I'm working on at the moment. In the coming weeks, I will try to do a more thorough write-up for each of these games.

I need a better economics education

So I'm working on an economics game. Specifically, it is a medieval business simulation. When I started, I had thought I had a fairly decent grasp of what I would need to know in order to create the 4 market system I had in mind. I designed a system. I was proud of my system but something just didn't feel right. I posted on Reddit and Facebook to get feedback. I was right. My system was broken. Not in a mechanic sense, as I think it would function exactly as I designed it. But rather it was broken from a thematic standpoint. I didn't obey basic economic principles.

Federation of Sol

A couple of weeks ago VPG officially assigned a developer for my science fiction "States of Siege" game, Federation of Sol. And I've been going back and forth with him and the game has moved forward by leaps and bounds.

Reich - working title

So, I've started working on a follow-up project for The Chosin Few. Currently, I'm calling it Reich but that is likely to change. It uses the basic A.I. system of The Chosin Few modified somewhat to allow it to scale to the entirety of WW2. You play as the military head of Germany who has to carry out the orders of Hitler. This will, of course, necessitate a few tweaks to the engine. I would love to get some feedback/thoughts on the following tweaks.

Rules Writing

Rules writing is probably one of the most important skills a board game designer/developer can have. It's the core of how we communicate with the player. It's how we put ourselves into the box to teach the game to the player. Except that if we were in the box the player could just ask us questions if something doesn't make sense. With a rulebook, they can't. So, how do we make sure they don't have to? The short, oversimplistic, and frankly condescending answer is of course to just write good rules. A truly comprehensive answer is probably too ambitious for this blog entry, but I think I can cover a few key points that I found lead to easier to understand rules.
I by no means should be seen as the final authority on rules writing. These are just my opinions. I think they are good opinions, but they are still just opinions.

4X Euro Space game, part 2

In a previous blog entry, I discussed ideas for a Space themed 4x "euro" design. Mostly in that blog I covered really broad strokes kind of stuff. Games that inspired me, the basics of the movement mechanisms, resources, ideas about leadership and building stuff. And that great, but today I want to really dig into the idea a bit more. A lot of stuff is still nebulous but some of the elements have solidified nicely and I want to talk about both.

Euro 4x idea

My absolute favorite board game is easily twilight imperium. But, it's so hard to get to the table. Primarily, I think, do to the length and perceived complexity of the game. I'm also quite fond of Eclipse, particularly its economic system, which is quite a bit faster in terms of gameplay. So you would think that at some point I would have tried my hand at the genre. I have not because I've never felt I had something to add and make a better game.

Surrounded, with a Shotgun - Playtesting report

This week VPG put the playtest call out for Surrounded with a Shotgun. I've decided to experiment with digital playtesting and so far it has been a huge success.

Previously when I've done play testing, I've sent out physical kits. These kits take time and money to produce, so there is always an imposed cap on the number of testers. Then they have to be mailed to the tester, which takes time. When all is said and done the tester doesn't see the game for 2 weeks to a month after agreeing to be a tester. In that time the game stalls. I can't make changes because then the testers will be testing the wrong version. And about half of physical kit testers aren't going to provide feedback at all, which I assume is because something new has caught their attention in the last 2-4 weeks since they said they were interested.

Using a pure digital kit approach, I had actionable feedback before I could finish replying to all the testers to send them the link. Granted, this is at least partially because SwaSG is a short game, but it's also there was an immediate ability for the testers to test while they were / are at peak interest. And so far I've had about 60-70% of the testers provide feedback. I'm used to only having maybe 20% of the kits I send out result in actionable feedback.

So, as of right now I see no reason to go back to physical kits for play testing unless I'm working on a game with a dexterity element or a component that I can't emulate digitally.

This is awesome!

Developing your own games...

If at all possible you should not develop your own game. Specifically, because a good developer needs to be able to make choices that will be difficult for a loving "parent". When the baby is ugly and needs reconstructive surgery it is not easy to cut away at something you love. With a bit of distance, it is a lot easier to make changes.

So, if you have access to a good developer take advantage. How do you know if someone is a good developer? Well for starters they won't pull any punches when they explain what's wrong with your game. So if all your friends tell you your game is awesome, you probably don't have a good developer friend. But if one of them tears into it a bit... pay attention. At the very least they are probably good playtester and depending on the details of their feedback they may be a good developer.

However, there is a dearth of good developers out there compared to the number of games that need development so sometimes if you want to get a game finished and published you need to be able to self-develop. This can be tricky as you still need that distance to make good choices as a developer.

So what is the best way to get that distance? Stop working on the game. Start something else for a while and when you've forgotten how the game works or at least a few specific rules, then you can come back to it with fresh eyes. With a developers perspective. You may eventually get to close again, and if so you can repeat the process.

Assuming you have a project that has been sitting for a while and you have established some distance, what now? Play the game, from the rules, not memory. Or better yet, put it in front of someone who has never seen the game before and watch them play the game without any help from you. Take note of everything that felt unnatural or that your tester(s) does wrong. Especially if they do it more than once. That means it felt right to do it the way they did it. Did it break the game? If not, maybe that is the way the game should work now. Especially if it feels more natural. Rules that feel natural and intuitive are easier to remember. Were the testers constantly going back to the rules? Sometimes the same rule multiple times? You probably need to clarify or simplify the rule so they understand it the first time. In short, you are going to test and iterate.

You may consider a few thing. If you can take a mechanic out of the game and not seriously affect the gameplay, it should be removed. If players consistently do the same thing the first few turns, make that part of the setup. If you can abstract something without losing the impact of what you are abstracting, do it. Basically, do not be afraid to make changes. If something doesn't work, you can always go back to an earlier version of the game. But if you never try something you will never know if it works, and your game may be weaker because of it. Oh, and speaking of earlier versions, archive earlier versions in case you have to go back to them.

Okay, so let's assume you aren't afraid to make changes. Excellent. But, be careful not to change too much at once. If you do that and the game breaks you won't know what broke it. Change one thing at a time if you can. You should only change more than one mechanic if the mechanics being changed are dependent on each other. If you have five mechanics you want to change, change them one at a time and see how it affects the game.