VELOCITRON – Postmortem & Extras

Posted by
December 24th, 2013 11:02 pm

Hey there! Adhesion from team RADMARS here with our tri-annual Ludum Dare battle report. This time we did a fast-paced music-based melt-face cube-smashing WebGL game called VELOCITRON which you can play here: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=18627

First up we got a timelapse and the long-awaited soundtrack to VELOCITRON:

http://adhesion.mu/sic/Adhesion-VELOCITRON.mp3

First postmortem we got is Brendo‘s:

My role this time around was a bit subdued compared to past Ludum Dares, but I’m really happy with the team’s results! Our brainstorming process on Friday night was very fun and productive. I think our idea of a demolition tunnel flyer was a good balance of theme, scope, familiarity, and novelty.
Being that the game is mostly procedurally generated, I didn’t have much to contribute in terms of level design, so instead I focused on 3D models. Problem was, I haven’t modeled in years, and Blender as a tool was mostly foreign to me. It was a good experience learning the program, but that ate up a lot of my time. Hopefully in the future I’ll have that tool more readily under my belt!
Often, being in the primary game design role means I’m bombarding the programmers with ideas they may or may not be able to implement. Kudos to Roushey and Eugene for taking the right balance between implementing new ideas and polishing the ones that are already there. The amount of progress made on Monday while I was away was astounding!
And of course, no Radmars game would be complete without Adhesion’s incredible skills on the music and sounds. He got to spend pretty much the entire time focusing on audio, and it really shows with the well-designed transitions and channel layering. Nice show all around!

Now Adhesion‘s:

This Ludum Dare went pretty amazingly well in my opinion. We managed to land on our main idea pretty early on in our Friday night brainstorming, and even came up with a title, which is usually an insane scramble for us the day before we submit! Before the competition we were pretty dead set on doing another three.js-based 3D game and luckily we were able to figure out our basic gameplay which wouldn’t be too crazy to implement on the dev side of things.

Also since we decided to do another very audio-centric game again, I had the opportunity to almost exclusively focus on the music & sound design like I did with Tessitron (LD26) which was great. Doing all the music and sound design as well as a bunch of dev feature work like I have for most LDs is certainly doable but a big challenge, and the room to breathe in that department this time around certainly helped. I had a lot of fun making the music, going for something more fast-paced and pounding which I don’t do too often, plus I had the opportunity to use my new guitar and some fancy unreleased software I’m working on at work which was awesome!

This was also my first time trying out the web audio API (via howler.js), which we deemed safe since the newest Firefox finally has support for it. This was really interesting and eye-opening, but I ended up pulling some of the web audio-based functionality (the ability to seamlessly change positions in the song) since it crippled loading times and memory use, and thankfully I was able to figure out a workaround (playing all songs simultaneously and fading them in and out) to get the seamless transition behavior that I wanted. 3D positional audio and the janky beat detection both kinda work though! A bit frustrating, but I’m really looking forward to doing more experiments with web audio. The idea of doing great rhythm/music-based games in the browser is really inspiring.

As awesome as the game is this feels like the one with the hugest potential and room for improvement. I was a bit frustrated that we collectively didn’t have as much dev/gameplay iteration time as we would’ve liked, since there was definitely some room for small extra gameplay mechanics (like speed boosts!) that could’ve really improved the game. Also I know there’s way more we can do visually with three.js/webgl (like shaders!) that we unfortunately never have time for. I had some fun (ie: misery) trying to cram in some beat-based visual effects right before submission to no avail :(

Regardless of any issues this is definitely one of the best games we’ve ever made, and I’m super proud of it. Go team RADMARS!

Now emarcotte‘s:

This ld I was more productive. There was enough sort of easy stuff for me to do when others weren’t there. Plus mike was around and coding a ton so we had some decent back and forth

Things that worked: threejs is fun, made more time to work this round than last, had good brainstorm that got an idea quickly.

Things we could improve: more rigor to imple for core components. More full group play test time (and earlier).

The thing that killed me the most was trying to fix the way we had implemented the tube so various things could interact with it better. You may notice deep turns don’t work so hot… Also I don’t think we could do a spiral… Basically we found a hack that looked really good to start and it was hard to fix later without making it look less awesome

And last but not least the mighty SPACEMARS:
Ha! another one down~ Overall I’m really happy with how velocitron turned out. As usual Sound design puts the team on its back. The movement of the player feels really tight. I feel like this was the most fun gameplay wise that we’ve made, but also the most lacking in visuals. There was a lot more we had planned for the last room smash crash action, but time is indeed a thing. The holiday season is tough time to fit in a game jam~  I always love to dig in and do some coding as opposed to art. This one was a bit trickier to manage as emarcotte and I were working on some of the same files fairly frequently. ha! some fun in the sun git conflicts.
That’s it! As always we love feedback so please let us know what you think of our musical opus VELOCITRON. See you next LD!

Tags: , ,


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]