Advertisement Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    4
  • comments
    0
  • views
    678

Preparing for and Participating in a Game Jam

Sign in to follow this  
Dan DAMAN

798 views

The Toronto Game Jam is opening for registration later this year. I'm hoping to participate again since it's been a great experience every time. As of last year myself and a friend have participated in the Toronto Game Jam three times. The event, also known as TOJam, has developers come together at George Brown College for three days of manic development of crazy game ideas.

Participating in a jam can be overwhelming but also rewarding and fun as hell. Over the last few events I've had things go right and things go wrong. Here are some tips to help avoid some of the worse pitfalls that you can hit during a jam.

Tip 1: Know what you're going to make in advance

At TOJam you have from Friday at 10:00AM until Sunday at 6:00PM to create your game. While you don't need things to be set in stone you should know that you're making a puzzle game and if will be based on sliding tiles or stacking blocks. If you don't know what you want to make then you'll be using up your time figuring out what to do instead of doing it.

The week before the game jam we take our one or two paragraph "elevator pitch" and write a simple list of what needs to exist to fulfill that pitch. We then refine that list into a detailed set of tasks we want to complete on each day of the jam. With the list we can grab work as it's ready and keep dead time minimal.

Tip 2: Know what features you can drop

Murphy's law always strikes. Something goes wrong and suddenly the deadline is looming. When figuring out what to do for the game you should have some idea of what features you can drop without ruining it. Generally this list will be very short but it's always handy to have if you fall behind schedule.

Making a list of optional features is also a good gut-check on whether you've got a realistic schedule. If the list is long then your project is probably too large. A schedule that feels like it has too little work on each day is better than one with too much. You can always add work and scope to a project while you're working on it. It's much harder to cut scope down when you're running out of time.

Tip 3: Balance your workload between team members

If you're jamming solo you don't have to worry about this. If not it's critical that everyone has something to do. One trick is to have broad but shallow task trees. If C depends on B which depends on A then they can only be done by one person. Sure you could work on A then your partner can work on B but you can't work on C while your partner works on B. A way of fixing this is adjusting your design so B and C depend on A but not on each other. From a coding perspective using interfaces and loose coupling helps a lot.

In our latest jam, TOJam 12, we had a number of lethal hazards which could be activated by a button. In the bad case character death would depend on development of some arbitrary hazard which would depend on implementing the button to activate it. To avoid this we set up the button with two observable events, OnPressed and OnReleased and gave the player character a "Killed" method. By having a simple interface everything that was activated by the button could be developed independently. By having the "Killed" method player death could be written independently from any specific way of killing the player.

Another trick is to group your tasks into distinct streams. During the start of TOJam 12 I developed the base skeleton of the game while my team mate whiteboxed levels. The only dependency here was that I needed at least one level to load to start the game which was done well before I needed it. Later on I worked on handling player death while my teammate composed the title theme song for the game. 

Tip 4: Have a library of game creation tools in advance

When jamming it's important to always be working on the game you want to make. The last thing you should be doing during a game jam is building a tile map editor. In TOJam 11 we lost about four hours to writing input handling code for a twin stick shooter. That took away time from more important tasks like generating bullet patterns, spawning enemies and so on.

Tip 5: Minimize the number of variables the game's design

I'm not a professional game designer so I'm not sure if "variable" is the right word. What I refer to is a thing that can be changed to alter the feel and balance of a game. The speed of a character, enemy hit points, number of enemies, how often they shoot, how often you shoot and so on. All of these variables add complexity to the process of making a game "feel" the way it should. Having lots of low hitpoint enemies could make you feel powerful. Having a few high hitpoint enemies would feel quite different. Having lots of high hitpoint enemies could make the game feel dangerous, scary or simply unfair. In all these cases I'm only changing two variables, the number of enemies and their hitpoints.

At TOJam 11 we produced a twin stick shooter called MANT: The Man Ant. The twist is that the bullet patterns would be generated procedurally. This also was the biggest headache. Pattern generation worked but it was extremely unbalanced. Sometimes patterns would be pathetically easy. Sometimes the game would produce enormous unavoidable walls of gigantic bullets. We burned up at least half a day trying to get a consistent and fun difficulty curve but still had huge differences between sessions. The game was a "finished" working product but it wasn't very fun.

Our next project was a puzzle platformer built around using dead bodies left behind when your character dies to reach different goals. Variables are generally level specific and mostly independent. Things like how quickly a door should close or how often a gun should fire. Tweaking still took around half a day but we stopped tweaking because we were done rather than being out of time.

ToJam Specific Extra

If you're driving from another city don't forget to take traffic into account. The 401 and Gardiner Expressway are infamous for a reason.

Related Links

Toronto Game Jam website
Our TOJam 11 project (not a great game in my opinion)
Our TOJam 12 project (you can find more details on how the jam went in the development log)

 
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • What is your GameDev Story?

    In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

    (You must login to your GameDev.net account.)

  • Blog Entries

  • Similar Content

    • By oeryilmaz
      Hi,

      I recently read Mat Buckland's Programming Game AI by Example book, I also watched Dave Mark's Utility Based AI GDC videos. And I'm confused about the difference of Goal Driven Agent's and Utility Based Agent's. 

      In Goal-Driven Agent Behavior section of Programming Game AI by Example, Mat Buckland wrote formulas for deciding which goal to be selected. And as I understand, in Uitlity Based AI characters also selecting goals(actions) based on some formula(curve formulas for example). 

      Is the Goal-Driven Agent Behavior section of Programming Game AI by Example written wrong or the only difference between Goal Based AI and Utility Based AI is curves for selecting goals(actions)?

      Thank you.
    • By khawk
      Splash Damage, developers of Dirty Bomb, have released the game design document, art book, and soundtrack for Dirty Bomb. According to their blog post:
      The Game Design document includes hundreds of pages of designs, sketches, notes, concept art, biro drawings, user stories and more. It can be downloaded here: link
      The Art Book looks at many of the original concepts for Dirty Bomb; from maps and characters to weapons and vehicles. It can be downloaded here: link
      The original soundtrack can be downloaded here: link
       

      View full story
    • By khawk
      Splash Damage, developers of Dirty Bomb, have released the game design document, art book, and soundtrack for Dirty Bomb. According to their blog post:
      The Game Design document includes hundreds of pages of designs, sketches, notes, concept art, biro drawings, user stories and more. It can be downloaded here: link
      The Art Book looks at many of the original concepts for Dirty Bomb; from maps and characters to weapons and vehicles. It can be downloaded here: link
      The original soundtrack can be downloaded here: link
       
    • By DevBlazer
      Hi all, I am currently playing around with making a 2D underwater survival game (pet project, not too serious) but I need someone I can sit with for like an hour or so, to help me flesh out some reasonable mechanics for the behavior of liquids and gases in relation to gravity, pressure, etc. (Sorry guys I totally failed science class and have no intention of studying it now).  There obviously has to be a balance between what I'm willing to code for and realism and then assistance with understanding some mechanics and how their formulas, etc would work.

      Again, I'm not trying to recruit anyone here, just looking for someone knowledgeable to have a friendly chat with for a little while.
       
    • By lougv22
      I am currently an indie game developer and I am looking to get a job with a game company as a game programmer. I worked for a game studio 9 years ago, but at the time I decided to get a day job as a software developer (non-game development), while focusing (as an indie developer), during my free time, on a vision for a game I've had for some time.
      This was then, but i've recently found myself unsatisfied with my day job and I am now thinking of going back to the game industry. The drive to make games is just too strong in me and I can no longer justify spending my days making software I am not excited about. Which leads me to my questions about a game programmer portfolio. Before i first got a job at a game studio i had built a couple of small games, this was way back though, around the year 2006. Would those be too old to showcase on a portfolio?
      Second question, i'd like to make the indie game i am working on available for potential recruiters to play, but I am not sure how to do that. I tried to put it up on Shimmer.io (kind like itch.io, but not as popular), but i ran into issues with that. It's a Unity game and the Web build i created for it was about 190 MB and it ran slowly and was very choppy on my machine, at which point i kind of gave up on the idea of putting it up online. The other option is to simply send (through email or Google drive) game companies a regular Unity build and let them play it that way. The question is, should i try to go the Web build route again and if so, any tips on making it work well this time? And also, if the Web build doesn't work again, would it be acceptable to send companies i apply for a regular build?
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!