» December minijam (Two birds with one stone)
December minijam (Two birds with one stone)
Last sunday the
december minijam happened, so here's a small postmortem
written from my perspective.
How did we get
from theme to game?
At the start of the jam I got
talking with Adam about
Haxe and the Ouya
Jam. He liked to try a project in haxe (a programming
language similar to flash's actionscript which can target multiple
platforms natively). I've been using haxe for almost a year now so that
made me the main programmer this time.
So Adam had this idea in
mind for a film noir scene which we could do for the
Ludum Dare Jam, which was happening simultaneously with the
minijam. Lothar then joined in as well and did all of the pixelart while
Adam was basically doing the game design, writing the script and doing
I'm a big fan of the Sam &
Twitch comics so I could get into the film noir setting and the
mechanics of the idea reminded me of the intro of
UMVC3, so with that in mind we got to work almost instantly
after the minijam themes were announced (which we completely
Because we wanted to have the
lowest possible barrier to entry we decided to target html5. So I got to
testing out some stuff, sound was notoriously famous for not working
and it turned out I couldn't get it to work. On my pc, in Opera
& Explorer. However it did work on Adam's more powerful machine
in Firefox, Chrome and a newer version of Explorer.
decided to just keep coding and making sure we could always fall back to
the flash target. I started out implementing simple systems to trigger
scene and camera changes, text, voiceovers and animations as it was a
little unclear how things were dependent on each other. Initial
animation for instance was scrapped for tween animation and then changed
to just switching out a bitmap.
The script was coming along
and with that we did a quick sketch of the storyboard that you can see
at the top.
We were a little unsure of wether or not
voiceovers would work well and it became clear to me that having some
more flexibity and control in the triggering system would be a good
idea. So I started rewriting things.
Unfortunately the minijam
presentation deadline was looming and time was up before I could
actually use all that for the assets. I got most of the triggers working
again but synchronizing the voice with the text and tweaking the
movements of the camera takes some time. So during the presentation
people got their eyeballs burned with some fabulous programmer art from
yours truly and random music I still had on my computer which totally
didn't fit with the game. Sorry about that. Please do check out our
Ludum Dare version of the game with all the visuals and sounds as
they're intended. http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=27123
after the minijam concluded we continued work, Adam created a nice set
of voiceovers, Lothar improved the profile pictures and I actually got
to implementing the crucial choice the player has to make at the end.
Unfortunately I didn't have much time on monday so I spent about 6 hours
adding all the assets, bullets, I redid the camera system, added
parallax and added support for reading srt subtitle files. I also
upgraded and adapted my code to the latest Haxeflixel
- I would have liked to have spent a bit more
time getting a clear overview of all the elements of the game, how stuff
would interact etc. For instance, up until the presentation it never
really dawned on me what the big green text was supposed to be used for
- The flash build had problems with certain audio files. It
turned out sound HAD to be at 44Khz. I blindly ran into that and thought
some weird data corruption had occured and re-created a project, dumped
in the assets and source code and tried again. Safe to say, I wasted
some time realizing the problem and converting all the sounds later
on. (For that last conversion problem Qubodup kindly pointed me to a program for batch conversion called sox, thanks!)
- Rewriting code is a bad idea during a short jam. An
initial idea generally works the most intuitive, even if it's limited
and doesn't offer as much control as it could if you would rewrite
- I was working with an out of date Haxeflixel version it
turns out. It's a library initially created by Adam Saltsman and has
been greatly extended by the Haxeflixel guys. But because Adam (not
Saltsman) was doing a fresh install of Haxe we were on different
versions, and as it turns out, there was a big update in between. That
made the code I had written pretty unusable for Adam later on so it was
important this got changed.
- I wasted some time trying to get
text look like really upscaled and anti-aliased (an artistic choice).
Turns out haxe and haxeflixel are pretty idiot proof, the text always
looked sharp, no matter what I did to it. So in the end Adam just pasted
the text into pictures.
- Passing on the code. Basically since
I wrote all the initial code and didn't have enough time on monday,
Adam had to finish up. But as the first time programming Haxe and diving
into my horror code, that wasn't easy. He did manage to fix a couple of
issues that were left, like the essential final gunshot sound. But
unfortunately I didn't explain the unintuitive camera control clearly
enough so it was left unused. In hindsight I think I probably could have
used tweens for clearer control and faster results. (I'm generally
reluctant to use tweens as they quickly lead to this typical flash
- Synching subtitles actually takes a lot of
time. The script was 4 pages long and making sure every line is properly
synched simply takes time. Also you can't start working on that until
the final voiceovers are done. So it created a bottleneck and due to
time restrictions the subtitles were also left unused.
haxeflixel has the feature of automatically pausing the game as soon as
the focus is lost. That was fine with my inital system where things were
timer based. But after I rewrote it I never tested it again, so it just
buffers all the events in the meantime and triggers them as soon as the
game is unpaused.
- Feature creep in general. Especially in
jams it's more important to focus on clear results one by one instead of
adding more and more possibilities.
- Time works slightly
different depending on which flash player version you have. I found this
out just now, writing the postmortem. I made a test with the camera
movements which worked fine on my jam pc with the debug flash player,
but on my home pc with firefox and a flash plugin, it's a couple of
milliseconds off. This results in slight but noticeable camera twitches.
So be wary of this if you intend to make time based
- Script, graphics and sounds turned out
- A singular vision.
- Not much programming
wise :) In hindsight, for a project like this, an interactive
storyboard, the timeline editor from programs like Macromedia's Director
or Adobe's Flash would have been perfect, basically removing the need
for programming completely. This way the focus could have been just on
synching the assets.
- In testing out all those trigger systems
I did get an interest in camera movement, panning, close ups and
generally making the most out of the assets there are, bringing life to a
relatively static scene. I really would have liked to have some sounds
panning in sync with the camera for instance. It's not hard to
Here's the Haxe project
with all the source code.
The game is
playable through here: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=27123
After the dead line I added some quick camera
movements to show the idea. I've also added some slow motion particle
effects for the rain and cut up the background to take advantage of
parallax scrolling and also made the borders fade into black for more
seamless transitions. The effects appear somewhat crude due to the low
native resolution but don't let it stop you from re-using the code. We
used 160 x 90, if you were to use a higher resolution, the effects would
also get a lot more smooth.
You can take a look at
the modified version here.
Category: Experiments |
Views: 518 |