Less is much, much more

For a couple of weeks I’ve been going back and forth with the following options:

  • Release my game including only co-op mode
  • Increasing features: adding new things to bring more features that help deal with Traitor mechanism, which would postpone release.

The question I kept asking:

  • Would this level of quality satisfy me? Would the game be good enough for release?

In the core of my game is the idea of having one secret traitor in the party. You don’t know who it is, the same way as in Werewolf party game.

Playtesting revealed issues:

  • There should be more options for the “traitor” (aka the “infected”) player in the game.
  • There was something I didn’t quite like in how the game ended – but something I quite couldn’t pinpoint.

And also, the game box is way too large.

I spent week or two going back and forth stuff, and solo testing my game.

And today it hit me.

I was randomly browsing Game Crafter pages where I found out there’s 108 card tuckboxes available. This might sound strange, but… somehow I immediately thought:

  • My game doesn’t need more components: it needs less component.
  • My game doesn’t need more complexity/features: it needs less features if any.

It’s bit difficult to describe, but by deciding to reduce number of cards to 108 (instead of using current 150ish cards) made a huge difference. I immediately knew what changes I needed. I wrote 7-8 tasks for myself: one deck is getting smaller, another deck is getting additional use, there’s no need to add one additional deck which I was planning… and certain resource system might be simplified. And of course tweaks here and there and playtesting.

The game core still remains untouched: the basic mechanisms, the basic goals are still there, but by reducing features, reducing cards I now see that this game will be great.

I think the solo and co-op system already work, and with that in mind I can happily do the few changes that will change things a bit. After this, there’s more options for the traitor player, the rules remain very simple, there’s more options for all players.

To recap: from “let’s add new deck, new features, new complexity” (that leads to a hard-to-balance mess), I’m “removing features, moving meaning of one deck to another, removing number of cards” I aim to receive:

  • More decision making instead of luck
  • Better options for the secret traitor player
  • Cheaper & more convenient game tuckbox (which leads to smaller shipping costs, which actually might make game more accessible for non US-folks)

I wonder at which point had I forgotten that when there’s a bug in code, you usually end up having less, not more in code? Same seems to work for physical card game design as well.

My decision to do this will mean I will be needing more testing, which again delays the game (I think instead of August… it’s maybe couple of months more. Might need to use valve time too). I think then I’ll have a game I’ll be really proud of, a game that will work great.

Game for werewolf party game fans – that’s what I was aiming for in the beginning.

But anyways.

Less is much, much more.

Prototype code must be ugly, filled with bugs and smell bad – my #7DFPS post mortem

Recently, the 7dfps prototyping challenge got tons of attention. The idea of the challenge was to prototype a 1st person shooter in just 7 days. I participated, sort of. Since 7 consecutive days didn’t fit my plans, I decided to work on my prototype on 7 days scattered around a few weeks of time.

I brainstormed tons of ideas and started doing a multiplayer prototype.

What went right
I used some of my old code, and was able to knock together plenty of things (but not first person… and not shooter… but well, something)

In this very short period of time (bearing in mind 1 day meant few hours of work to me) I was able to put together very simple level loading system, animated character, raknet system for multiplayer (handled movement, animations ok enough) and some other stuff.

What went wrong
What I couldn’t get in shape: playable prototype. The most important part of prototyping is that you do something you can prototype. In retrospect, I can find that the main reason fort not being able to do playable (with some sort of goal, now it was just moving objects) prototype was this:

Using multiplayer library (raknet) meant some hours was spent making it work, and working on my own server-client system. Perhaps too much for a contest like this. It would have been okay, if I had earlier used the raknet library. Now it was too bit much work (for this prototype). Raknet is damn cool, and it made the difference that I even had any network system in place at all. It was hugely easy & fast to implement (just few hours), but for this prototype, it was few hours too much.

Second important thing was that I perhaps wrote bit too classy code. When I code, I nowadays usually try keep the code clean. I try get rid of useless methods, useless classes and keep things tidy. I believe that in all serious projects, that’s the best way to go. I’m too lazy to try clean the code just before the release.

But that’s quite wrong way to go with small prototypes. In prototyping, the code must be ugly, filled with bugs and smell bad. The shittier the code looks, the more copy & pasting you do, the better… as long as the code does the thing it’s supposed to do.

I think it requires talent to write messy code for prototypes. Refactoring & cleaning can come later.

What next time?
What is cool that I managed to try out raknet and even get it to work. That was the biggest thing for me. I could test the code with a buddies in different parts of this planet.

For the next prototype… I can consider writing smelly code, but it might be hard. I’ve spent more than half of my life writing/designing/thinking/doing-something code related stuff, and going back to very messy coding (even for a short period of time) can be difficult.

We’ll see.