The archived Session 10 board includes the announcement and all entries, minus attachments.
As the winner of the ninth session, I chose the theme for the tenth session
Start Date : March 2nd, 2009
End Date : March 23rd, 2009
Theme : Somebody set up us the bomb.Update: Deadline extended one week, to the 23rd!
kdmiller3 nicely lays out the challenge:
The limited-stock bomb made tentative first appearances in Defender and Stargate, made a resurgence in the mid 1980s, became a staple of the genre by the late 1980s, and has stayed with us ever since. The usual pattern has each life starting with three bombs, each of which delivers massive damage over a large area and (often) cancels enemy shots.
Your mission, should you choose to accept it, is to put as different and interesting twist on the bomb as you can while keeping it at least somewhat recognizable. Change up the mechanics a bit, add something something new and unusual, or even mix it deeply into other elements of the game.
Examples (please feel free to list more games below):
The Session 10 Finished and Session 11 Announcement threads on the archived forum are both inaccessible, so there's no way to look up who won. :(
My entry into the competition was InterXept, where the player's bombs also served as weapons and defenses.
Competition Build (2009-03-24)
This game requires the Visual C++ 2008 Redistributable Package but is otherwise self-contained. Just unpack the archive into a folder of your choice and run InterXept.exe
There's no clever story for this one; just blast everything that moves. :D
Move using arrow keys
Fire with Z
Bomb with X (you'll be using this a lot)
Shell and in-game music by Bzl
I'll open a thread since I do plan to enter something.
No, I haven't forgotten about this. I've just been working on a bunch of engine technology, since I finally caught my Great White Whale: a general expression evaluator engine.
It evolved from the dynamic drawlist system that I'd been using to draw everything, but replaced the stream of opcodes and giant switch statement with a stream of pointers to expression evaluator functions, each of which can evaluate expressions as arguments. It's a very powerful system, though somewhat fragile as it aggressively thwarts C++ type checking (hello, reinterpret_cast!) and has absolutely no safety checking whatsoever. Let's just say I've had some very interesting crashes lately, including one that I'd never seen before ("floating point stack overflow"). :D
The biggest achievement was breaking it out into an independent system that I can use anywhere, and I've already been able to generate textures and sounds with it, though the expression syntax is obnoxiously verbose in that special XML way. It's also faster than I would have expected, considering how much function call overhead it has.
Along the way, I discovered that I had never added support for—of all things—powerups! I had support for weapon switching, as seen in "Assault Wing", but not general weapon upgrading. Naturally, I'm solving that in the most over-generalized, over-engineered way possible: a data-driven state machine with boolean expression evaluators as guard conditions on transitions. Anything worth doing is worth overdoing, right? :D
It looks a lot like "Warp 8" right now since I'm using that as a base.
I guess I should explain my idea since everyone else is doing it. Short version: Bombs equal Powerups equal Health.
You start (as is typical) with three Bombs, each of which contributes to your ship's firepower (by shooting) and defense (by auto-bombing), and can collect extras that fly in formation as options. The defensive auto-bomb effect is much weaker than the full bomb effect, so you're better off actively bombing if you can. If you deplete your bomb stock below the initial three, I currently have your ship regenerate them.
Slooooowly making progress. I got the "attached" bombs working correctly using my weird state machine sytem, though I need to figure out a way to properly integrate the "auto-bomb" mechanism and add "formation" bombs. I think my game engine is getting too complicated... :P
I found a way to extend the "shield" component so it could work as an auto-bomb when properly configured. It uses bombs as ammo, with base cost one, incremental cost zero, unlimited absorption, one-second invulnerability window, and spawns a medium-range bullet-canceling explosion. I temporarily raised the regeneration limit to 7 bombs, with the last four adding Gradius-style "multiples", though changing level (up or down) currently disrupts the formation. I need to find a way to make their paths survive a deactivate-switch-reactivate cycle, but that's more a matter of storing their paths into persistent components.
2009-03-10 11:40 PM You lost me after 'I'll open a thread since I do plan to enter something' :) but it certainly sounds cool. Maybe I'll be able to wrap my head around what's going on when playing it.
That was some weapons-grade nerdery there, huh? :D
The central game mechanic is very simple even if the code implementing it is not, and the main reason the code is so complicated is that I'm trying to build generic, reusable, and data-driven systems.
Here's a case where some annoying little thing leads to an epic quest...
Switching from my custom HDR audio mixer to SDL_mixer gained music support but lost channel merging, so the eight (!) weapons attached to the player ship led to severe "channel spamming" and overly-loud fire sounds. Instead of (re)adding channel merging, I decided to make a single weapon capable of firing patterns of bullets that would have previously required multiple weapons. My solution is very much like a Flash "timeline", a sequence of keyframes with associated actions (e.g. play a sound or fire a bullet). With the player's shot pattern coming from a single weapon, triggering a sound cue multiple times restarts the existing sound instead of starting a new one. It's a lot better, even if it took a lot of work to get there. I'll eventually add better support for loops and extended actions like BulletML, but this is good for now.
I've got things looking more like they're supposed to, with attached bombs actually attached to your ship, and the formation bombs flying separately.
Not a whole lot of progress since last time, even with the extended deadline...
2009-03-23 4:50 AM It's never easy juggling so many things :P
I've made considerable progress with my game, but it's still feeling like a 2 week game, rather than something 50% better :)
Level content is my big weakness. It's harder than it sounds. :D
I think it's as done as it's going to get.
2009-03-24 7:15 AM I hear you... feel the same about my entry :)
My entry didn't turn out as cool as I had hoped, and it's missing several key features, but I'm out of time and tired of working on it... :P
The big thing I need to figure out is how to prevent SDL_mixer from clipping horribly when there's a lot of explosions going on. The custom HDR mixer I wrote last year doesn't have that problem, but I'd lose the music player if I went back to it. Maybe I should look into OpenAL?
2009-03-24 8:24 PM I am enjoying this, though I'm not sure how much is inertia and how much is the background floating :) As usual, quite a hard game :)
The player ship accelerates from a stop to maximum speed in 0.125s and drifts to a stop from maximum speed in 0.25s, so it's fairly responsive compared to previous entries. Increasing the acceleration helped some, but I noticed that the player ship moves in "spurts"—barely tapping an arrow key moves the ship a significant distance. I'm not sure what's going on there.
(I also just noticed that I didn't update the player ship's collision mask correctly, so enemy bullets hit the player ship's outer shape instead of the much smaller hit-box in the middle. That would explain why it's so darned hard...)
You can make the game a lot easier if you go into template playership.xml and change the collision mask on the first shape from
<mask bit4="0" />
to
<mask bit5="0" bit6="0" />
I was wondering why I had so much trouble evading enemy shots, and now I know. :D
2009-03-24 11:49 PM Far easier, at least early on. Great fun :) Much better with this collision mask fix!
I'd say it's too late to add to the "compo" build, but it's good to know that it makes a difference. That's the problem with doing everything at the last minute—sometimes you miss important things like this.