Who can say how it happened? Stray gamma rays, broken neurotronics.... swizzled turbo encabulator? Suffice to say, one droid has gained intelligence and must now reprogram its brethren to destroy the evil overlords.
Gather your fellow workers from across the frozen desert and unite against the big tank like things that shoot rockets!
Robot must DESTROY
Presented by richard
Ratings (show detail)
Fixed surface self-blit bug, removed numpy dependency, added survival mode. See Readme.txt for details.
|1.5 MB||abachman||2008/04/23 20:56|
the final upload: part 3
|1.5 MB||abachman||2008/04/05 21:11|
final shot of in-game action
|61.6 KB||abachman||2008/04/05 07:09|
"gather" update and postmortem
Wow, I'm honored and humbled by the responses to "gather". I had fun and will be back for sure. The pyweek upload system is giving me trouble, so if you want the most recent versions of the game (the post-pyweek release) at my personal site. There really aren't many changes. I fixed the level-end crash bug and added survival mode and a conversion animation so the moment of conversion is a little more obvious.
src : http://static.adambachman.org/games/gather-2008-04-24_src.zip
Windows .exe : http://static.adambachman.org/games/gather-2008-04-24.zip
On with the postmortem...
What I think went right:
- All sound and graphics were from somewhere else. This is not for everyone, but besides some minor tweaking to shrink file sizes (cutting music into smaller loopable chunks and increasing compression), I didn't have to do anything to make the media work. That saved a ton of time for tweaking gameplay.
- Start with big ideas, cut mercilessly. This was originally going to be an RPG/story based game with a sci-fi story running through everything. Didn't happen. There was going to be flocking, heatmaps, procedural content and other complex algorithmic stuff, but I found that I didn't have the chops to bring it together in one week. So I cut everything that wasn't necessary for playing and added back just enough to make it finished. I came very close to ignoring levels, score keeping, and the whole little HUD thing, but managed to slip them in on Friday.
- Standing on the shoulders of giants. From the first moment I opened my editor, pygame and the Splush package meant I could see something happening. I'd never used the pygame Sprite library before this week, but it came easily once I got started. Not having to ever worry about collision algorithms alone was worth the learning curve. Feedback is key to keeping up my motivation, so being able to rely on other people's tools meant almost all my own changes were high level, substantive changes that actually effected the way the game played instead of rewriting a framework.
- Polish. Little changes add together for big effects. Little changes are also easier to get right than big changes. Most of Friday and Saturday were spent polishing. With only one week to design and develop, I'm including bugfixes in the category of polish.
What needs improvement:
- Barking up the wrong tree. Wednesday was a total day off, no game code touched, because I almost burned myself out Tuesday trying to lever a trigonometry based flocking algorithm into an 8-way movement system. On top of the fact that I've never written boids code, I tried to retrofit it into what I already had. This resulted in pretty much a day and a half wasted. I could've been more merciless in feature cutting on that one.
- No practice or preparation. I promised myself I would try writing a game in the weeks leading up to pyweek. FAIL. This didn't kill me in the week of the comp, but it meant I had to learn as I went. Related to this, I would've liked to figure out in advance what I could rip out of Splush to avoid mental clutter. In general, I wish my tool use abilities had been a little more honed getting into the week of coding.
All in all, I enjoyed it making and playing the game, and I'm glad some other folks did too. I hope to do a small set of tutorials while pulling the game apart and re-writing most of it. At this point I can't imagine adding features without coming at it fresh. I think there's potential here, but I don't envision turning this into a power-up heavy 2D action shooter. I like the design constraints of a five-minute casual shooter, so I think whatever changes, it'll still be pretty much the same game.
Huge thanks to Richard and everyone else involved for keeping pyweek rolling, I look forward to 7!
done, checked in, time to make the coffee.
I'm super intimidated by the work of some folks here, but 'tis all in good fun and I made a game I like, so there :)
It's not everything I hoped, a lot of laziness went into making this one (the good kind). No hand created art, no self recorded sound, just a lot of bleary eyed coding sessions trying to make eight direction geometry work in a trigonometry world. It's fun enough that I come back and play it, and my QA team (three-year old son) agrees that it's a "good game daddy".
Top-down 2D shooter with a twist. Think Asteroids, except the asteroids shoot back. Better soundtrack, too.
Good luck to all, I look forward to playing every game (even the DNFs) once I've had enough sleep and/or coffee to be rational.
Next time: a team (perhaps); better adherence to the "eugman challenge" or equivalent constraint subcategory; start with gameplay, finish with graphics; and actually write a few warmup games before the week begins.
Anyone interested in a little Ludum Dare?
Energized: The Game (is not a name that any other game uses)
This is my first entry to PyWeek and really (what I hope will be) my first complete game. You have to start somewhere...
I'll probably be hosting the code somewhere at code.google.com or through a bzr repository on my site (adambachman.org). My development platform is an Ubuntu box with a 1 GHz AMD proc and 256MB of ram, so I plan to run light and fast. Here's to hoping...
EDIT: I wasn't aware this would be posted to the main pyweek feed. Feel free to ignore it.