How To Start Game Design - Designing Games with Constraints · Urodela Games How To Start Game Design - Designing Games with Constraints | Urodela Games

How To Start Game Design - Designing Games with Constraints


A Monthly Challenge

I have a goal of creating 1 game each month. A mini, digital board game, made for solo play.

I call this whole monthly thing Table Tempo.


Defining Constraints

For each game, I randomly choose 2 constraints that my game MUST use:

  1. A random board game category.
  2. A random board game mechanic.

Of course, these are chosen from the very popular board game community, Board Game Geek.


Start Designing Differently

Here’s where it gets fun.

:green_book: I wrote down what my game constraints actually involved.

test

On the right, you can see me describing game constraints.


The above example shows designs from the first Table Tempo game called Server Spies, where my constraints were:


Instead of only coming up with finished designs, I brainstormed what Flicking means to me in board games:

test


I did the same thing for the category Spies/Secret Agents.

test


I started linking the two graphs, trying to reveal where the category and mechanic could be matched in an interesting and fun way.

test


:bulb: After looking through these ideas, I thought of my design:

“I should make a game where I flick my pieces into the earshot of other pieces so that my pieces can spy on those other pieces for secret information.”


Implementing the design

I start thinking about turning this design into an actual video game…

  • :x: Artwork
  • :x: UI
  • :x: Different types of pieces
  • :x: Juicy player feedback
  • :x: Player testing
  • :x: Game marketing
  • :x: Controller inputs
  • :x: A 3-5 year plan
  • :x: Retirement
  • :heavy_check_mark: Player can flick a piece across the screen with mouse. (Mechanic)
  • :heavy_check_mark: Flicked piece can “listen” to other pieces in earshot. (Category)


test

First prototype of Server Spies - The game is ready for Steam :laughing:


:green_book: I let my constraints remove the tasks that were out of scope, allowing me to focus on a prototype that matched my design.


Playtesting, incremental changes, and emmerging themes


Okay prototype sorta done. :heavy_check_mark:

:grey_question: I playtest, playtest, playtest while making code changes and asking questions about the game:

  • What does the player get for flicking into earshot?
  • How does the player know their piece is listening to others?
  • What is the player even flicking?! What does the piece represent?
  • What is the player trying to achieve? What does the player need to do to win?

Thinking back to our constraints, answers emerge (and then some):

  • What does the player get for flicking into earshot?
    • Spies/Secret Agents Category
      • The player gets information from those other pieces when their piece flicks into earshot.
      • :bulb: Maybe the player is eavesdropping on other people that have secret info.
  • How does the player know their piece is listening to others?
    • Spies/Secret Agents Category
      • The player gets a text dialog of the other piece that the player’s piece is listening to.
      • :bulb: Maybe our piece is intercepting the pieces talking to each other.
  • What is the player even flicking?! What does the piece represent?
    • Spies/Secret Agents Category
      • :bulb: Maybe the player is flicking their secret agents around, pretending to be butlers.
      • :bulb: :interrobang: Maybe the player is flicking ROBOTS dressed as butlers. And all the other pieces are guests at a party!
  • What is the player trying to achieve? What does the player need to do to win?
    • Spies/Secret Agents Category
      • :bulb: Maybe the player needs to listen in on every guest’s conversations, deducing which one is to blame.
      • :bulb: Maybe the game is a murder mystery!


test

:robot: :robot: :robot: ROBO-BUTLERS :robot: :robot: :robot:


I understand how weird this game got… but I loved the idea and I think it fit the constraints nicely!

:green_book: I looped over this step several times, constantly asking if the changes I’m doing actually address my constraints.


Grind the game development.

Here’s the section about the game development:

  • We write tons of code.
  • We design UI.
  • We wire up player inputs.
  • We test until the game is “good enough”.

Since this is a game design article, I’m not going to discuss the technical details.

:green_book: But for all you game devs, I validate you and the pain that is required to code a game. This section is for you. :smile:

… Anyways.


“Being done” with my game.

Games are never finished, anyone in game development knows that. But I knew for a monthly challenge how important is was to “be done” with this game - FOR NOW!

Here’s a list of things regarding constraints I thought about as I closed:

  • Does my game fulfill my original constraints?
  • If you strip away the assets and the juice, does my game still address my constraints?
  • When other people play my game, do they notice the constraints? Or do they notice something completely different?
  • How long did it take me to design the game vs implement the game?
    • Did I design too big of a game? Or did I implement more than I designed?


And of course, enjoy the moment of a “finished” game:
test

Play Server Spies


Thanks for reading.

That’s it for now. I’d love to hear your feedback on this type of game design process.

I’d also love for you all to play + hear about the board games I put out each month: