Tuesday, March 02, 2010
Game Jamming on a Bigger Game?
So after working with a few Game-In-A-Day / 48 Hour Game / Weekend Game Jams - and visiting the one in January - I had a thought. These come seldom to me, so I relish the ones I do get.
One of my excuses for non-participation (or limited participation) is that I've constantly got one main game project or another that I have very limited time to work on as it is. My family is very tolerant of my taking many hours a week to work on it, but I feel guilty taking so much time on something else.
But the results of these little exercises are impressive. They are awesome experiences, and it's staggering to see how much can be accomplished in a 24-hour or 48-hour time frame when you really, really focus on it. Just eating the miles. It's also a fantastic exercise for game developers to go through every step of the process at high-speed. I think any indie game developer (myself included) can benefit greatly from the experience. A 48-hour game jam is probably the equivalent of a semester-long college course in game production.
And Stuff Gets Done. Never to the level of completion to satisfy the participants, but a lot happens very quickly.
So here's an idea:
Suppose you were working on a full-on commercial indie game - much larger than what could normally be done in a weekend Game Jam. if you, as an indie, were to go balls-to-the-wall crazy on, say, getting a single area or chapter or set of levels 100% playable in a day or weekend, sloppy though it might be, would that be a good thing for the game? Give it the full-on Game Jam treatment. Would that be real progress, or would you end up with a lot of work that had to be re-done for beta?
Has anybody else tried this? Any experienced Ludlum Dare / Game Jam / Game-In-A-Day veterans feel like weighing in?
I guess there's only one way to find out fer sher. I'll have to schedule some time...
Labels: game development, productivity
- posted by The Rampant Coyote @ 7:23 AM (Permalink)
Comments:
Links to this post:
<< Home
This sounds more or less like the concept of a "sprint", from Agile, without the Agile mumbo-jumbo and with a large dose of "no such thing as too much overkill".
I think doing gonzo-sprints can work:
1. You're using decent version control (pref. hg or git, but others might work), doing the sprint in its own branch. Be sure to check in code as chunks work, not all at once at the end.
2. Clearly define the overall functionality up front. Bonus points if it can be broken down into discrete chunks that can be considered "working" for some definition of that term.
3. Refactor mercilessly in the sprint branch *before* merging anything back to the main branch.
I really can't under emphasize how valuable I find using mercurial or git. I can branch for "lemme try this" experiments, with no risk. If they work out - bonus! Merge to main. If they don't, no harm, no foul.
I think doing gonzo-sprints can work:
1. You're using decent version control (pref. hg or git, but others might work), doing the sprint in its own branch. Be sure to check in code as chunks work, not all at once at the end.
2. Clearly define the overall functionality up front. Bonus points if it can be broken down into discrete chunks that can be considered "working" for some definition of that term.
3. Refactor mercilessly in the sprint branch *before* merging anything back to the main branch.
I really can't under emphasize how valuable I find using mercurial or git. I can branch for "lemme try this" experiments, with no risk. If they work out - bonus! Merge to main. If they don't, no harm, no foul.
I've wondered about that too. How well it might work to devote a 24 or 48 hour period to development on a larger game. The thing that gives me pause though is that I know that a significant portion of the code would need to be redone later.
When I worked on Treasure Raiders at the global game jam, I found myself throwing all sorts of coding standards out the window. There were several spots where I implemented a quick and dirty solution that would work, but wouldn't lend itself very well to expansion later. I let myself get away with it mostly because I knew that we weren't going to need to expand any of the code beyond the immediate needs. Short sighted coding like that could really kill you on a larger project.
Still, I think I'd like to try it sometime.
When I worked on Treasure Raiders at the global game jam, I found myself throwing all sorts of coding standards out the window. There were several spots where I implemented a quick and dirty solution that would work, but wouldn't lend itself very well to expansion later. I let myself get away with it mostly because I knew that we weren't going to need to expand any of the code beyond the immediate needs. Short sighted coding like that could really kill you on a larger project.
Still, I think I'd like to try it sometime.
I asked a similar question after I participated in contest. Could crunch time be more effective to start a project rather than saving it at the end? Are brute force, heroic efforts good for getting over lulls in productivity early on?
I think the problem you have with any crunch period is that the quality of the code might go down, causing more problems later. On the other hand, as GAJ suggests, it's possible to keep an eye on quality, but you have to be willing to throw away junk code. Be ruthless about quality.
I am thinking about taking a Ludum Dare game I made and submitting it to a contest this month, but I'll have to polish it, which means digging into the code for the first time in months. I wonder how much of my time will be spent refactoring it heavily or if rewriting it would be better.
I think the problem you have with any crunch period is that the quality of the code might go down, causing more problems later. On the other hand, as GAJ suggests, it's possible to keep an eye on quality, but you have to be willing to throw away junk code. Be ruthless about quality.
I am thinking about taking a Ludum Dare game I made and submitting it to a contest this month, but I'll have to polish it, which means digging into the code for the first time in months. I wonder how much of my time will be spent refactoring it heavily or if rewriting it would be better.
My thought is that it's not the start of the project that's hard - and there's always crunch at the end. But getting through that awful, slow slog that is the middle territory can be destructive to one's soul.
So at that point, the principle gameplay code should be done. The basic gameplay should be down. But the game tends to get buried in details. So a quick dash to make some visible, clear progress, recognizing that some refactoring & debugging (for code and content) will have to be done to play catch-up later...
Well, it might work.
Post a Comment
So at that point, the principle gameplay code should be done. The basic gameplay should be down. But the game tends to get buried in details. So a quick dash to make some visible, clear progress, recognizing that some refactoring & debugging (for code and content) will have to be done to play catch-up later...
Well, it might work.
Links to this post:
<< Home
