Need how-to-contest-in-team guide

Posted by
April 10th, 2013 2:54 am

Hello, LD!

There are some good tutorials and great survival guide about speed game development contests.

But it’s fist time we’ll apply speed development contest as team. And it’s a problem :).

I’ll be very glad, if LD team-players will share their experience how to be efficient while speed game developing in team.

I mean, for example, how to divide work between developers.


Thank you LD. And we are in with Java, good mood and lot of ideas :)

4 Responses to “Need how-to-contest-in-team guide”

  1. JoeCool17 says:

    The single most important thing is communication. You may not think much of it, especially if you’re all good friends, but it is *really* important that everyone knows who’s doing what, who’s implementing what, who’s compiling what, and so on! A friend and I did LD24 together…. it ended very badly after some VC issues and a horrible job communicating how we were going to deal with it.
    Secondly, make sure you use version control, and get yourself familiar with it! Even if just one person is doing programming, and the other art, everyone needs at least a basic familiarity with what the programmer’s writing and how to work with version control. It is a truly powerful tool that used correctly can be behind many great successes. It enables everyone to quickly share what they’re doing without risking any sort of interference, and provides a constant backup in case things go wrong. Art people should be committing their art so that programmers can implement them, programmers should commit their code so that art people can see how it works with their art, and so on.

    I’d recommend using GitHub to start off with- Git is better than SVN IMHO and GitHub has a neat little windows GUI that makes using it less scary.

  2. dector says:

    Thanks for you answer, Joe. But the main problem isn’t about general communication or CVS using.
    Ok. I have small imagination how to split game coding for two or three developers. But it looks like five developers is too much for three days contest.

    I mean, I don’t know what’s the best practice for architectural design and problem-solving in this case. Because it looks not trivial for me without any big engine (with graphics engine, physics engine, scripting for logic), using only small frameworks that covers only, lets say, OpenGL bitmap binding, core functions and batching.

    My first solution is about splitting graphics and logic developing. We’ll write “tools for developers” (map editors etc), as it is normal practice in long-term development. We’ll aim on game. But it’s very big difference, as for me, to develop game alone (i can code some logic with constants, use some mocks, bad, dirty or not-yet-final architect solutions than back to it later and improve it). But this tactic may be very dangerous in team development, because somebodies solution may be based on yours code or architecture (especially if you can’t split work good enough to fully parallel development, lets say, for each module).

    I found one solution, that may be good in this case – Data Driven Design. So, we’ll test it in practice soon. :)

  3. Spiridios says:

    Five programmers does seem a bit much for a 3 day jam. That’s right about the size where you’ll actually need some formal planning, as I think you’re finding out. What I don’t see you taking into account is content.

    I’d suggest, and this may be hard if every one of you is a coder, is to start by splitting the work into coding and content. Put two people tops on initial main game coding and everyone else on getting music, sound effects, graphics, and level data together. Maybe one of the content people can build tools or scripts to aid in content generation if they’re not really artistic. But two coders, especially if they already work well together, can pretty easily evolve code from nothing without a design. Add more, and it starts to get harder to coordinate.

    Your two coders should try and pull together a rough design of how the whole thing works by coding it. Create modules for everything that’s needed, but just stub out the code that’s not immediately needed to get started. Keep evaluating where you’re at as you go. As your code base grows, you can then pull content people in to work on the stubbed-out modules or modules that need improvement. Since the interfaces for those modules have already been dictated, there’s less chance of confusion over what actually needs to be written.

    That’s what my experience tells me. Though I’ve never jammed on a team, I have worked on, and have managed, teams in my day jobs.

  4. dector says:

    Thanks, Spiridios. I’ll think about your words. :)

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]