Game Development Process Archive

Today is the last day of our Rafflecopter Giveaway.

Click Here to Enter.

Be the first to comment

I’ve put together the print and play files for our Treasure of Skeleton Island prototype using a handy Python script. It’s not super flexible yet, but it is solid enough that I’m ready to release it to the world, so go visit the bitbucket repository.

For future projects, I’m hoping to take advantage of Squib for completely data-driven prototypes.

Alright, enough of the techie stuff. The print and play files are available here.

And don’t forget, we’re still running the prototype giveaway. Click here to enter if you haven’t already.

Be the first to comment

Starting Small on Kickstarter from Brian Henk

Posted November 13, 2014 By Jeff

Over at Stonemaier Games, Brian Henk has a guest post describing his “start small” experience on Kickstarter. It is remarkably similar to our experience with Cursed!, complete with a mid-campaign art swap. Check it out: Good Creator Bad Creator: A Guest Post by Brian Henk

Be the first to comment

Cursed! Kickstarter Update Roundup

Posted July 29, 2014 By Jeff

Here is the condensed version of all the Cursed! action that we’ve been reporting on over at the Kickstarter Campaign since our last Cursed! blog update.

  • We have finalized the rules based on playtesting. We’ve changed the format of the rules document a bit, so once we finish the conversion process, we’ll be posting the rules on our website for all to see.
  • Surveys went out and have all been returned. We decided to go with just the stock Kickstarter survey process, since our fulfillment process is all getting handled by The Game Crafter. While that process did go smoothly, the appeal of a third-party survey provider was obvious. For one thing, you cannot send the same survey out to multiple reward tiers. You need to recreate it by hand each time. I was very glad we’d went with simplicity when designing our reward structure.
  • Our box design is mostly complete. While we did have a box for our prototypes, it wasn’t designed so much as slapped together out of existing pieces of art, so we aren’t even going to call this a redesign.
  • The card redesign is complete! Every single card in the deck got an updated layout and many had the text (both flavor text and sacrifice effect) modified after playtesting. The new design is the featured image for this post. Enjoy!
  • We’ll be ordering a proof copy soon to make sure that everything is to our liking before we place the bulk order.
Be the first to comment

Game Development Theory

Posted March 11, 2014 By Jeff

If I say (write, type, whatever) “game theory” and you leap to concepts like Nash Equilibria, zero-sum, minimax, or maximin, then you’re not quite in the right place, but I encourage you to stick around. You may learn something. For those of us more concerned with having an enjoyable game night than we are with Mutual Assured Destruction, we do a number of things to make sure that gameplay does not degenerate like this

Balance

A balanced game is one in which no player overall has a strong advantage of disadvantage compared to the others. Balance problems frequently occur in role-playing games when it comes time for players to choose a class for their character. Since most games want a variety of choices when it comes to choose character abilities and fundamental characteristics, it can be difficult to ensure that the game is enjoyable for everyone, regardless of the choices they make. MMORPGs are continuously rebalancing the attributes of the characters in their games to try to achieve this ideal of every player (of a given level, to compare apples to apples) has an equal share of the fun and adventure. As you might expect, those who see their abilities fall in comparison to everyone else (called getting nerfed) complain a bit, but overall gameplay improves.

When designing a tabletop game without the opportunity for frequent tweaking, you have a few tools you can apply to keep your game balanced. The first is symmetry, the primary balancing characteristic we use for Curses! In a symmetric game, as you might be able to guess, all the players start off in identical conditions. Each person may have a different set of cards in their starting hand, but the chance of getting a particular card is the same for all the players at the table.

Another technique for balancing a game is to structure the mechanics to deliver a lot of variety without a lot of difference. The 4th edition of Dungeons and Dragons did this by recasting progression within each class to be much more parallel. There was a lot more variety in the flavor text (the descriptions of how events occur), but the outcomes possible with each type of character were much more standardized than in previous editions.

A third balancing technique is to allow for, and encourage, collaboration among the players. If one player starts getting too far ahead of the rest, they can gang up to either improve their own fortunes or retard the progress of the frontrunner. Curses! allows for this in two ways. Firstly, each player must play one card on someone else each turn, so if anyone’s fortunes are starting to look a little too rosy, the rest can gang up with the Curse cards. Secondly, many of the Sacrifice cards target other players, sometimes with a much larger impact than a single Curse could generate.

Predictability

When we say that a game is predictable, we don’t mean that it is predetermined. Anyone can win and crazy stuff like someone ripping off their shirt in the middle of a Munchkin game to reveal a +1 T-shirt underneath is awesome. What you want to avoid is someone winning from last place with a coup de grace that relies on an alternate interpretation of the word “the” in the second footnote on the first page of Appendix C of the rulebook. I hyperbolize, but you get the idea. To paraphrase Albert Einstein, the rules to your game should be as simple as they can be, but no simpler. Once you’ve played through a couple times, each player should be able to hold the rules in their cranium and run through scenarios to determine what impact different plays by themselves or others would have on the game.

Curses! has very simple core mechanics (one on yourself, one on someone else, sacrifice one, draw back to five), which makes it easy to get the rules out of everyone’s way and get on with the fun. We’ve also designed the cards to make it simple to divine any player’s state at a glance (color coding plus standardized positions of all the fortunes). You’ll always know where you stand relative to everyone else and roughly how many turns of horribleness would need to descend upon you before you’re eliminated.

Engagement

Have you ever been in a Scrabble game where all but one player get up from the table and wander around, get more beer, turn on the TV, etc. because that one person can’t come up with a decent word, but refuses to sacrifice a turn by swapping tiles? It is my biggest complaint about the game, even though I’m often the one left at the table trying to make something out of AAEIOUU. A well designed game will have some way of either keeping players engaged as play goes around the table or keeping a high enough tempo than anything longer than a bathroom break would be disruptive.

The brute force method of keeping game play moving is to insert a timer. Unless an element of time is crucial to your design (e.g. Boggle), resist the temptation to force your players to move faster. If you can help the players out by removing some common, repetitive tasks, like counting how many points everyone has, that will improve response times without enforcing artificial constraints.

More challenging, but more rewarding, is developing mechanics that keep all the players engaged with the game and each other no matter whose turn it is. Curses! has fairly quick turnover, but some of the rules changes allow interference in gameplay even when it is not your turn. For games with longer turns, make sure players have side channels for wheeling and dealing. Risk
is a great example of a game where this happens spontaneously. The rules don’t say anything one way or the other about make “treaties” with other players, forming and breaking alliances, etc. but it almost always happens, because it allows the players to remain interested and productive when they aren’t on the offensive.

Wrap-up

Of course, there are many other qualities that you’d like to see in a well designed game. It is highly genre-specific and is a lot of art (but a little science remains!). If you are just starting out with a design, the best thing you can do is get other people to play it. Ideally, get some people to play it while you watch, so you can see how others interpret your directions. Look for any signs that someone is bored or thinks some facet of the game was unfair and focus like a laser beam (see! science!) on fixing that. The best artwork and most intriguing backstory won’t make up for an unfun game.

In future posts on this theme, we will look into different types of games and prominent characteristics like playercount, game length, and complexity (usually measured by age range).

Be the first to comment

Game Development, First steps

Posted April 4, 2013 By Andrew Bradley

The idea is that this will be a sort of a walkthrough for the independent game developer.

So you’ve been playing lots of games, and you have decided that you might like to have a crack at making one on your own, or with some friends. Congratulations. This is not going to be easy. At times, it won’t even be fun (but honestly, most of the time it is).

If you’re reading the above paragraph, and thinking “Well, I play some games, but maybe not a lot of games,” then you need to go to step zero, play some more games. You need to know what’s out there in order to take part. Just like writers should be readers, filmmakers should watch films, teachers should be lifelong learners, you will learn more from practitioners of your craft (good and bad) than you can imagine.

OK, so you’ve played some games and now you’re ready to start one of your own. Turn off the computer. Take out a pencil and a notebook. I’ll assume you have a basic idea or theme for the game in mind. Hopefully you’ve also got a basic mechanic in mind. That is, during the main parts of the game, what is the player going to be doing?

If I’m designing Civilization V, then the player is managing an empire, sure, but specifically, the player is clicking on various things on the world map; units and cities and the like, and giving commands. The game is then processing those commands and the commands of AI players.

If I’m designing Bioshock Infinite, the player’s essential action is navigating the world from a first-person perspective. Sure, you shoot things and interact with the world, but at the most basic level, until you are navigating that world, there is no prototype.

If it’s Assassin’s Creed IV, it’s surprisingly similar to Bioshock, although now I have to consider that the player’s avatar is visible the whole time.

For a game like Prison Architect, the player’s essential behavior is building the prison. All the stuff that happens inside the prison is (mostly) out of the player’s direct control.

For whatever your project is, you have to first consider, what does the player directly control? What does the player do? For my current project, the best short description of the game is that it’s a turn-based tactics game. So the player’s essential action is very similar to games like X-Com: Enemy Unknown or Frozen Synapse. In fact, the target is somewhere between those two games for me. So I have to think about what my player will do, before I even start to think about how he or she is going to do it.

While there’s a lot of other game modes, the main game is the battles, so I’ll be working on that first. So I need my player to be able to navigate the battlefield, not as a soldier but as a commander with a top-down controllable world view. I need to be able to select soldiers and give commands, and I need to be able to tell the game I’ve given all the commands I’m giving this turn, and it can go ahead and process them. There’s obviously much more to the game than that but you can see already how complicated it’s getting. I filled several notebook pages to get this far, and in fact may have even described more here than is necessary to strictly get started.

So let’s forget the turn processing right now. Let’s even forget selecting and commanding soldiers. To start, I need to navigate the battlefield. If I can’t do that, I can’t do anything. For that, I’ll need a 3D engine capable of rendering the battlefield, the ability to place a camera into it, and then the ability to control that camera. We can call the camera the god’s-eye view or whatever we want, but in this type of game your player avatar is essentially this invisible camera floating above the action.

So first, figure out the very core of your game. What does the player do? Figure it out on paper, with notes and diagrams or whatever works for you. Next, we’ll figure out how to make it all happen.

Be the first to comment