For this LD, team RADMARS attempted to make a puzzle platformer where you have to die in order to progress. It was a big challenge, but I think we managed to make something pretty awesome. Check it out here: http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=7860

We have postmortems for 3 out of the 4 members of RADMARS for you today (and timelapse videos for two of those). Up first is roushey, who decided to write a very lot for some reason:

This Ludum Dare went surprisingly smooth. We started off Friday night cooking up a bunch of good ideas and finally settled on the concept that every time you die, you gain a new ability based on how you died. We then spent the rest of the night fleshing out all the abilities you would have, flagging them as necessary, nice to have, and eventually cutting some. After that we had a pretty solid plan to always tab back into and check where we were at. We also put TODOs for art, programming, levels, etc on the doc as well so we could quickly see what the other team members were doing without pestering them.

 

 

What went well:

First and foremost we bumped up team RADMARS to four people, by adding brendo. This helped quite a bit, as he spent basically all of his time on level design. The biggest thing we learned from Escape from Minimars is that the level design needed much more love this time around. The biggest complaint (from us, as well as the comments) was that the game felt stale by the end. I really liked the way we created and ‘painted’ the levels for DDE as well. (as opposed to minimars) Brendo designed all the levels just using colored squares for all the different elements. ( red bricks for solid ground, green for platforms etc)  This way, we had all of the levels designed and playable before we even did the art for what the environments would be like. The only real direction we had was that we wanted to have 3 areas. ( as adhesion was going to make 3 music tracks ) I wish we’d spent a bit more time thinking about it, but we settled on: forrest, caves, and ‘nature-punk’ future-ish kinda thing. It was really nice to have the levels built before I pixeled the map-tiles as I had a much better idea of what kinds of tiles to make. Minimars was the complete opposite, where I panted a buncha tiles and just had people make random shit out of those. Both work, but I like the former much better. Working with MelonJS was also pretty awesome. The creator, Olivier Biot, has been really active about updating it. We had some feature/bugfix requests after minimars pretty much all of which were fixed in the next version. So awesome! Tiled ( http://www.mapeditor.org/ ) is fucking boss. I can’t recommend it enough for working with a tiled maps. Version control! We used Git (still not quite used to it… I’ve always used SVN) and its pretty much invaluable when it comes to working in a team. Voice chat & live streaming! All weekend long we had all 4 of us in voice chat (mumble) so we could quickly ask for things and get status updates (as well as dick around and make bad jokes, and complain about… well everything really. complaining is fun) I had a stream up on twitch.tv which makes it very easy to show what I’m working on with the team. I can demo animations, brendo got to see people play testing his levels, etc. really awesome. I highly recommend it.

 

What went not so well:  The major thing that went wrong was scoping. There was a lot of detail and polish that (i think) is pretty important that we just didn’t have time to do. The biggest of which would be the main character’s sprite never changes. We wanted to have the character change for every different ability. The changes would only be minor, like a stripes, boots, a spiked hat but the fox squirrel red-panda thing had quite a few frames of animation. this makes creating overlay elements that much more of a pain in the ass. I’m gonna rant for a bit here so sorry ahead of time. Perhaps I’ve just not found the right tools, but the process for making animated pixel-art characters is not so fun. Photoshop is probably the best tool to use for pixel art (that I’ve worked with) its just got so many features, and they’re all highly tuned and polished to make it as painless as possible to actually make stuff. The biggest problem with this of course being… animation. Photoshop’s animation features are basically garbage, but that’s not what Photoshop is for so thats completely OK. The biggest problem though is exporting the animations to a sprite sheet. Doing it manually is obviously… terrible. I’ve tried using pretty much everything from scripts to Photoshop actions to try to make the process as painless as possible, but none of the solutions really fit well. I do realize that at the end of the day, its actually not *that* big of a deal, but I see it quite a bit like an IDE having re-factoring tools. If its a hassle or a pain in the ass to make changes, (at least for me) the ‘fuck it’ impulse flares up and the changes never get made. This is of course made worse by the fact that the drawing tools in most other pixel drawing apps I’ve used just feel very immature compared to PS’s ) And the more complex your animations get, the level of pain-in-the-assery rises exponentially. I used Graphics Gale for all of the particles (explosions, splashes, smoke poofs, etc) because in terms of making simple pixel-art animations, it’s really awesome. Its fast, you can go back and forth between frames easily, constant playback preview, and it can (at least reasonably well) export to sprite-sheets. The problem with Graphics gale is that the way it handles layers is really clunky. If it wasn’t for that, id be using graphics gale… pretty much all the time. Selection, copy & paste, are also really clunky and can be a bit weird. I’ve tried to use gimp, and Paint.NET as well. They’re pretty good Photoshop alternatives, but if  you’re already using Photoshop they really don’t bring much to the table as far as animation is concerned. /rant  Phew. sorry about that *_*; Process:  Map Tiles & Parallax backgrounds: All pixeled in photoshop, grid, guides, selection, cloning, painting tools all make my life so much easier. Maps: Painted (tiled) using Tiled map editor. Characters: sketched and painted in photoshop, pixeled in photoshop, exported to sprite sheet using a photoshop action.

Particles, explosions, and effects: Directly pixeled in graphics-gale, no real sketches or anything like that.

‘At the end of the day’ Now that I’ve had some time to sit back and rest, I’m really proud of this game. There’s a lot of stuff I would like to go back and change like the shameless pallet swap of the background in the third area, and the additional states of the avatar. I’ll get to em uh… eventually! for now, Go Team RADMARS! (Also, all of the other LD submissions keep getting better and better each time.) Can’t wait to do LD25 And his timelapse:

Up next is emarcotte, for whom brevity is the soul of wit:

“Yeahh same as usual I need more fcking time. Knowing the tools helps. Having a person per area helps.”

Indeed. Last is me, who falls somewhere inbetween:

What went right

-Well-defined roles: It was great to have brendo as the designated level designer, which freed the rest of us to work on our respective tasks. On the coding side, even though there were two of us we were able to switch off on what we were working on so there weren’t any weird merge issues that might take up time.

-Time to polish code: I was lucky to have all of Monday free to pretty much only do playtesting and fix small bugs, which was great. I also had some time to do some subtle sound tweaks (like the running sound) which I think really helped as well.

-melonJS: a very good game framework which has even had some specific bugfixes related to issues we found when doing our previous game. Not quite perfect yet, but the few issues I had this time were not showstoppers by any means and I was able to work around them relatively easily.

What went wrong

-Feature creep: Our concept, awesome as it is, lent itself to a sprawling amount of features. A good number of deaths->abilities got cut as we realized we would have no time to actually implement them. Cutting these was difficult but we decided we’d rather have something polished and more focused rather than something very ambitious that fell short.

-Time management (to an extent, again): I felt like I ended up spending more time on music & sound as I did last time, but came out with about the same amount/level of quality. Majorly subjective though. Also, again it was a bit hard to get going on Friday/early Saturday but once we got the core features set in stone and some art assets done my coding gained a lot of steam.

Overall this Ludum Dare was hugely satisfying, and we made an even better game than last time. Look out LD25!

And my timelapse:

And of course the soundtrack, which I’m very proud of: http://adhesion.mu/sic/Adhesion-DDEOST.zip Whew! Hope you liked all this stuff – we’d love more feedback, so drop by our game page and leave a comment!

Tags: post-mortem, postmortem, timelapse

4

This entry was posted on Sunday, September 9th, 2012 at 9:27 pm and is filed under LD #24. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.