72-hour Game Development Competition
the challenge: building a computer game from scratch using only publicly available libraries in 72 hours by a maximum of 3 people per team.
the BIGGER challenge: getting the 3 people to agree on how they will make the game.
personally, I think a team of one will be more efficient with this kind of project. just imagine all the design meetings at work you need to sit through just to decide who does what. 3 days will only be enough to decide whose turn it is to bring the donuts for the next meeting.
[continued in the comments...]
for those who are interested in the competition, here's the link:
http://www.finalredemption.com/72hourgdc/board/index.php
posted by .e @ 1:03 PM
2 Comments:
if the team has to be more than one person, it might help to have one person to do the music and another the graphics, and everybody to conceptualize and to test. but no more than one person to code and to have the final say in what the design should be. you might think this kind of measure is only good for a 72-hour project, but i find it applicable to larger projects as well. having more than one programmer coding on a single module wrecks havoc on the application's stability and expandability, according to my experience. in addition, coordinating tasks amongst developers/architects is real time consumer. that time is better spent on design and testing.
Hey Ed, I just saw your post in your blog (http://code-head.blogspot.com/2004/11/72-hour-game-development-competit
ion.html#comments). Honestly, this is how I think we can most efficiently work in a team of three...
1. We need a lead designer. What he says goes. The others aren't
happy: TOUGH! This will prevent us from going in circles. Of course the lead designer should listen to what the others have to say and go with the majority most of the time, but when it becomes clear we're not going to agree on something the lead designer steps in and makes a call. That's his role. He's not there to order people around. That's NOT his role, he's not the boss. He's there to keep the ball rolling.
2. We start by agreeing on the game concept and a lot of high-level stuff, such as the general interface we'll use, overall parameters and gameplay style, etc. Once that's done, the lead designer creates a proposed modular approach to implementing the thing. We meet again and discuss the value of the design, make whatever changes are necessary, etc.
3. We create a list of other things we'll need, most importantly the list of art we'll be needing. This doesn't have to be detailed, something like "we need animation data for the main character and backgrounds for each level", etc.
4. The lead designer implements the infrastructure. I don't mean he starts the implementation, I mean he sets up the skeleton for the entire game and uses stubs for each function. (For those who don't know, stubs are an implementation of a function whereby you can pass parameters to it but whatever the function's supposed to do doesn't happen. If the function returns something, then the stub returns something reasonable, most often something fixed, but sometimes it's better to have something
random.) The goal of this step is to have a complete infrastructure that can be compiled (but does nothing), where all that's left to do is to go in and implement the functionality. The other two could help by making the skeleton for their module (while ensuring the entire application continues to compile), but...
5. While the lead designer is working on the skeleton of the application, the other two start tackling the list of other things we'll need. Again here we're more concerned about having SOMETHING as opposed to having the finsihed product. So creating a rolling box for the "animation data of the main character" would be fine. The goal is to have some art so we can test the game as we develop it.
6. Now we should have everything we need to start the real work. We each pick up a module to start implementing. The high-level module (ie: the .exe) that glues all the other modules (ie: the .dlls) should probably be implemented by the lead designer. Other than that, I don't see any reason why we can't just pick off modules as we want. We should probably choose a bottom-up or top-down approach and use that to decide the order that modules should be attacked. Personally, I think the bottom-up approach in addition to having the skeleton in place will allow us to get noticeable differences immediately. There will probably be exceptions, for example perhaps we should tackle the interface first even if it's really high up so we have something we can look at when we test the lower-level stuff.
7. A version control system might help us. What I'm thinking of is having a central repository of our game as it stands now. The repository should ALWAYS (without question) be compilable. We would checkout our own private copy of the repository to do our work. We test locally to make sure what we've just implemented works as expected then we check the change back in. We should probably do a complete checkout and make sure everything still compiles, but by making sure things compile before doing the check-in we should be allright. If you guys like this idea let me know and I can setup a CVS or Subversion repository before hand. Note that I'm no version control expert and I only want to use this for the most basic functionality, which is to help us collaborate on the same set of files. Technically speaking, if we're careful we could probably use a directory as the central repository, a seperate directory for each of our private workspaces, and a tool like Araxis Merge to perform check-ins. I'm fine with that too. (Works fine here at DoJ :)
8. We need to work IN THE SAME LOCATION. I think this will make a huge difference in terms of efficiency. If we have a question about a module, we need to be able to speak to the person responsible NOW. If we have a question about the architecture, we need to be able to discuss it as a team. If I need help with my work and you're ahead in yours, taking a few minutes to help me out will probably speed the overall process. (Imagine everyone waiting on one key module otherwise.) Working in the same location is definitely the most efficient way to proceed. The requirements for the location: a network needs to be setup so we can share files easily, and access to the Internet is an absolute must (so we can look up references or examples, download whatever libraries we'll need, and listen to Internet radio :). Obviously we'll need a room big enough to house the equipment for three systems and still have enough room for us to sit comfortably. (Ventilation can be an issue for a small to mid-sized room: we may find it pretty hot in
there.)
9. We need a PC per person. I think this goes without saying, but anything less would be inefficient. Unfortunately, I think we're more-or-less short a PC for Mike. I've got the laptop he could use (and it already has Visual Studios .NET installed), but it's not much of a workhorse (watch out for those compile times... they're reasonable, but slow... like a minute for a small project). You know, if I had time, knew what platform we'd be coding on and cared enough about it, I'd probably setup some cluster software so everytime any one of us compiles all available crunching power across all systems kick in to do it. Reduced compile times always results in higher efficiency. Oh well, this will do. Don't forget: if we're serious about recording some music, we'll need those instruments and some way to record from them.
10. The competition allows us to submit our game multiple times. I think as soon as we have a working version of the game, we submit it. Afterwards we should submit whenever we make a significant commit (like a major bug fix, optimization or even artwork enhancement) or on a regular basis, like every other hour or every five hours. In addition, we should take that opportunity to make a backup of the entire codebase (should the worse happen, like a power failure). Finally, we should use the last 30 minutes or so of the competition to stop whatever it is we're doing, make sure the game compiles and make a final submission before the deadline with our most recent work. Heck, we should probably spend the last hour playtesting and tweaking (not changing) the game play to ensure what we get is what we set out for. For that matter, play testing should be a regular part of the development cycle as soon as we have a playable version. We should include special functionality to make testing easy, like being able to jump to any level, or being invincible, etc.
11. Food: it's essential we eat on location (as opposed to going out). Any time spent outside the house is time not coding.
12. Working hours. I think it's good to set a goal on our working hours, but I think it's more important for us to listen to our bodies. 2h power snoozes will result in higher efficiency than strictly sticking to a schedule. That's the problem with the game industry now: they keep increasing the number of hours people work but don't realize that each additional hour renders those people less efficient, up to a point where you less efficient than sticking to regular work hours.
13. Conflict resolution. Sure, there won't be... of course! BUT, if there ever should be, the third person will need to act as an arbitor between the first two. The third person should try to resolve the issue to the best of their capabilities. Sure, that might mean there'll be a "winner" and a "loser", but no matter the outcome we should accept it, remain professional and get back to work. I suppose in the worse case scenario where all three are involved in the debate that the lead developer's say should have extra weight.
14. A person should NEVER be idle. You're waiting on someone else to complete their module before you can proceed? Then how about reworking some of that art, or writing up some music, or making some sound effects. We've got lots of tasks we can do in parallele to keep us all busy.
All I'm doing here is outlining A method we could follow to ensure we remain as efficient as possible in the short time period we're dealing with. I'm certainly not advocating the above as THE method to follow. In fact, I'd much rather see us discuss the above and anything else you can think of and agree up front on a work environment that will be most effective yet acceptable to everyone. Contrary to your post in the blog Ed, I think a good team of three people will blow away anything a one-person team could do... the only worry I have to this effect is we've never worked together as a team before. Oh well, this will be a trial of this as well. :)
I'd like to reiterate that my motivation for doing this competition isn't the competition itself, it's developing my skills and portfolio, and even my skills as a team member working together under hard conditions. I think it will be a very valuable learning experience (for me at least) and that's what I'm looking forward to most. Next I'm anxious to see what we can do in 72 hours and suspect we'll all be surprised (one way or another :). Only after all that am I interested in our results in the competition. I say so again because I hope your motivations follow along the same lines as me. If so, we'll likely have similar expectations and work ethics. If we have drastically different motivations, we may argue a lot over what we want to build.
Post a Comment
<< Home