Home | Rules and Guide | Sign In/Create Account | Write a Post | Reddit | #LD48 | #ludumdare on irc.afternet.org (Info)

Ludum Dare 31 — Coming December 5th-8th 2014! — Join the Mailing List!
  • October Ends: in 30 days, 1 hour, 49 minutes, 37 seconds
  • Ludum Dare 31 begins: in 65 days, 2 hours, 37 minutes, 37 seconds
  • (FYI: Clock might be off) | Ludum Dare 31: Real World Gatherings (Now Open!) | October Challenge 2014!


    And remember to work together… as a Jamteam!

    Posted by
    April 11th, 2013 12:35 pm

    After seeing a post asking for tips on participating in Ludumdare as a team I was inspired to write this. I’ve successfully participated in three global game jams with in person teams, the Boston Festival of Indie Games, and Ludumdare(with St0ven), so I have a bit of experience with jamming as part of a team. There are plenty of other posts that cover the basics of participating in a game jam on your own and many of those suggestions still apply. Here are a few examples:

    http://www.ludumdare.com/compo/2012/12/10/greetings-to-all-the-new-guys-a-k-a-folis-inofficial-guide-for-newbies/
    http://www.ludumdare.com/compo/2012/12/17/my-tips-what-i-learnt-from-the-fix/
    http://www.ludumdare.com/compo/2012/05/06/its-war-a-tiny-world-war-postmortem/
    http://www.ludumdare.com/compo/2012/04/08/the-game-jam-survival-guide/

    I’ve tried to keep my tips specific to a team environment, so without further ado, here they are.

    If possible, form your team ahead of time
    This way you know who’s doing what and what style they’re most comfortable with and what they are capable of. There’s nothing worse than trying to find another artist or programmer at the last minute and finding out that the tools they are familiar with or the style they use is completely incompatible with the game you are making. This also helps prevent the problem of too many chefs in the kitchen. If you form your team ahead of time and realize that you have four programmers and no artist then you still have time to split into two or more teams.

    Minimize overlapping responsibilities
    If you have multiple programmers you should try and break things up so that you aren’t working on the same code. You want to spend your time creating, not merging and bugfixing. If you do want to have multiple programmers working on the main gameplay components then have someone define interfaces early on. This way it’s really easy to drop in new code or change existing behaviour. For artists this may mean having one person do all character art and another do environments or UI.

    Reduce bottlenecks and get rid of interruptions
    Ideally create a way for artists to add content to the game without having to go through a programmer. Create placeholder assets(empty sounds, blank sprites) that can be easily swapped out without programmer intervention. This allows you to focus on making the game work while they can focus on content and aesthetics. Spend a little more time on making it easy to load in lots of content(It will pay off in a team environment). This also saves you or somebody else from interruptions where someone is asking what they can work on or to add their new content to the game. Make sure that each person has multiple things that they can focus on so that if they can’t progress on one they can switch over to the other. There are always going to be scheduling issues, you may have artists working on stuff while your programmer is asleep or vice versa and you don’t want that to slow down progress. Finally, if you need an uninterrupted block of time to work on something then be clear about it. Make sure that any questions or requests are written down for later or sent via email. I go so far as to sign off of IM/IRC and not check my email if I’m cranking away on something.

    Someone should be calling the shots
    This doesn’t mean that you need to be a ruthless dictator or that other people can’t make creative contributions but at the end of the day somebody should have an idea in mind for what the final game is going to look like and they should help guide people in that direction. Whoever takes on this role should be capable of understanding what is feasible. As a programmer I find that I am not great at estimating artist workloads and I have to assume that the reverse is true too. Also keep in mind that it’s a 48-72 hour game jam, it’s not the time or place to demand perfection. I always try and encourage people to do their best work and I find that I’m constantly surpirsed and inspired by what they create. If you find yourself in this role make sure you get estimates from the people who are actually doing the work and always be conservative with your estimates. If somebody else is organizing the game then don’t be afraid to say no to them, in the end everyone will be happier with a finished game than an unfinished game that was a really cool idea.

    Source Control
    Use source control. If everyone is at the same physical location or on some sort of instant messenger then drop box or a network folder can work, but it’s not ideal. You want to spend your time working on your game not mucking around with version control so stick to what you know and keep it simple. Make sure that it’s something that you are familiar with. If you don’t know how to use git or svn then now is not the time to learn it, you’ll just end up frustrated when you try and do anything more complicated than simple commits. If you don’t know a source control system I would recommend using drop box with a backup folder in it for old revisions. If your artists don’t know your source control system but your programmers do then consider using some sort of hybrid where your code is in source control but your art assets are uploaded to dropbox. Recent builds should always be available to everyone on the team. Source control is what allows you to add potentially game breaking tweaks at the last minute without fear or to spend an hour refactoring things to add a new gameplay feature that may or may not work.

    Pick an idea early and run with it
    This isn’t nessecarily team related but it’s exacerbated in a team environment. It’s easy to waste time trying to come up with the perfect idea. Pick something early on and keep the scope small.

    Plan for people to drop out or have other commitments
    Focus on the most important parts of your game first so that when somebody can’t continue to participate you can still salvage a game out of what you’ve got. Animation and polish and menus are nice to have but leave it all for the final day. Unexpected things will come up, in fact I don’t think there’s been a single jam that I’ve participated in where everyone has been available for the entire time. If something comes up and you have to take a break or drop out then you should let everyone else on your team know that you can’t participate and if you’ll be back later.

    Have fun making games,
    -Ben

    Tags:

    One Response to “And remember to work together… as a Jamteam!”

    1. dector says:

      Thank you for sharing your experience. Will keep your tips in mind.

    Leave a Reply

    You must be logged in to post a comment.


    All posts, images, and comments are owned by their creators.

    [cache: storing page]