Adhesion from team RADMARS here, with extensive battle reports for this fateful compo from all of our trusty team members. We all have grizzled war stories from the development of our entry Tessitron, a 3D, minimal music game – play here! http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=18627 – but first I will entice you with a screen timelapse and the entire (single-track) soundtrack from our entry:
http://adhesion.mu/sic/Adhesion-Tessitron.mp3
And up first we have tokken’s postmortem:
It’s pretty incredible to be a part of a group that meshes so well and yet our ways of thinking contrast yet compliment one another. Although we’re all able to come up with off the wall bizarre ideas, it’s the way we think that’s pretty special. Spacemars is really good with generating nuggets of ideas; I tend to build off and branch from those. Adhesion has great depth as well as the analytical aspects that help ground ideas. Eugene is usually quiet but when he puts something out there it’s generally to lay down something important. Brendon has a great way of conceptualizing play and teasing out interesting mechanics from our vague notions.
This time around, although we weren’t entirely certain how we were going to apply the theme of minimalism, we had some basic constructs we wanted to adhere too. With three games under the Radmars belt we looked at our history and pondered where we were going and where we wanted to go. Two of the Three games had been 2D pixelated sidescrollers, with the third being a 2D pixelated top down adventure game. Although a theme was never intended, one was starting to appear; partially due to ease and speed of development. Between Spacemars and I, we had some fairly substantial 3D chops if we ever wanted to go in that direction.
Previously, Spacemars and I would generally do the brunt of the graphics work which placed much of the development onto Adhesion and Eugene. The secret sauce for Radmars has always been the great music Adhesion produced (also the dark humor imbued in each game). When he’s loaded down with code, music was pushed off to near last minute or at a lessened capacity.
This time around there was a definite consensus amongst the group to embark on a different journey from the previous games. We wanted to utilize our broad skill set without losing any piece that was vital to our current dynamic. We looked at each other and evaluated how to potentially build something that played off our individual strengths while compensating for each’s weaknesses.
Spacemars is a Jack of Most Trades Master of More Than Should Be Possible. He’s foremost a great developer, with serious pixel skills, 3D abilities to rival my own, and an eye for design. He’s also one of the most dedicated on the team and probably dumps the most time into the projects. His major weakness is time; he can’t do it all. Luckily with a team like ours he’s super malleable and is able to pick up any aspect that needs assistance. Certainly the cornerstone of Radmars.
Adhesion is Spacemars’ right hand man. His greatest asset is his mind and depth of thought; he certainly has a head on him that allows for quick concepting and speedy explanations; his dry sense of humor meshes perfectly with the team. Oh, and he’s a bad ass music man.
Brendon certainly has an eye for design and a great ear for music. Maybe his most important asset is the thoughtfulness he brings to our game designing. He has a very analytical thought process that allows him, and by extension us, to break down games and gameplay into more compelling pieces. His ability to find and create mechanics is something that always boggles my mind.
Eugene is a quiet thunder that weighs in on ideas and directions while being a heavy lifter on development. Unfortunately he is also somewhat mysterious, like a ghost that haunts your brains and whispers genius into your ear.
Myself, I have a robust working knowledge of Cinema 4D, texture and matte painting, and am a UI / web designer. My skills in development are limited to some as3 and Unityscript. My biggest flaw was my parsed time allotment.
At this point you may be wondering what all this BS has to do with the actual game, but I assure you this was not just some ego horse shit. Knowing each person and what they bring to the table helped us shape Tessitron…
Our initial goal was to create a game that was more audio based, possibly music, possibly ambient. Visually we wanted to diverge from the 2D perspective and embark on at least some limited 3D. Right off the bat we were able to see who could be assigned to what.
With the visuals being minimal, to both match the theme but also for time’s sake, I could handle all the 3D myself. This allowed Spacemars to potentially take over lead development as he had previously played with three.js before. With graphics and dev mostly taken care of; Adhesion would be free to do his thing on music. Eugene would work in tandem with Spacemars to kick some development ass. We knew Brendon would be working on level design / flow but at this point we didn’t have enough of a direction to start.
At first we wondered if we wanted to build in story, at least overtly, and have the game themed visually as well. After some discussion we figured gameplay would be the star, with a skill based audio / visual “ride” almost. A strange meld of guitar hero with a SHMUP. This turned out to be a great plan as this allowed Brendon to team up with Adhesion to come up with a flow based enemy system that synced well with the music and scaled with difficulty. Not to mention come up with the enemy string that needed to be hit in sequence to destroy it. This worked perfectly for the final boss as well.
With some solid game mechanic ideas down Radmars took off and began production. Early technical hurdles slowed some aspects down, which others can speak to better than I, but they were surmounted. As for my role, I began producing the simplistic 3D models used for enemies. I pumped out a series of mix and match pieces that could be pieced together to make interesting new enemies. I also did some rough paint-overs to lay in the color pallette and UI, and then built out the pieces to implement the UI.
The other team members will no doubt be able to express their parts better than I. Overall the final product was a pretty fantastic endeavor that came out extremely well and is more fun than I could have imagined. I am most proud of the breadth of skills utilized to bring this to life and the passion the team exhibited is always inspirational. Definitely pushes me to work harder, to learn more, to continually get better, and keep up with the team surrounding me.
And now emarcotte’s:
As usual real life is always chewing time. I managed to contribute a bit, but each time seems less. I think my most useful contributions are on the slightly more backend side, eg loaders and core utils as Adhesion is busy doing music and Spacemars is more focused on mechanics.
Three is decent. API docs are lacking but functionally powerful and easy to use. Definitely worth using again.
Design wise I am not as interested in this as previous entries but the product is more polished since it is smaller scope.
Graphically it looks great as well, absolutely not because of anything I did as well. Good work team!
Here’s brendo’s:
When I looked at the list of possible themes for this Ludum Dare, I really hoped that Minimalism would be chosen. Before the challenge, we as a team had done some reflection, and wanted to go a bit more abstract than our previous entries. That’s why it was surprising that when Minimalism WAS chosen, we had a super hard time coming up with a solid idea. Friday night was rife with floundering thoughts, long silences, and my increasingly nervous feeling that we weren’t going to think of anything. Then, at some point past midnight, Spacemars switched up the brainstorming style by straight-up demanding what kind of game we each desired to make. When it came time for Adhesion to answer, he just said a music game, and somehow the core mechanic of Tessitron leapt right out of the resulting discussion. Sometimes it’s good to just let your desires be known.
Even though my role is “game designer”, I don’t own the concepts of the games; they belong to the group as a whole. What I really enjoy is taking whatever crazy concept the group comes up with and developing it into fleshed-out features and mechanics. That’s what I spent most of Saturday doing. While the others developed the prototype, I concentrated on expanding our basic mechanic into ideas for engaging interactions, then pitching those ideas to the group. This process resulted in a lot of great features for Tessitron, including the linked enemies and the boss fight.
Sunday was when I got to dive into some nitty-gritty level design. Spacemars did a great job providing a nice level design framework. I could spawn enemies, change the camera angle, and move the boss with simple lines of code. Perhaps the best feature was the ability to disable/enable specific sequences, which allowed for me to easily test and re-test whichever part I was working on. Adhesion was another key player in the level design process. His intimate knowledge of the music allowed him to suggest the “mood” of each major chunk of the game. He also provided specific sequences that fit with the music which I could drop in at key points. I have a bit of a background in music, so it was really fun to collaborate with him on those parts of the level design.
Sunday night and Monday evening were my times to refine the bejeesus out of the sequences. I didn’t get to this point as soon as I’d have liked. I spent too much time on the beginning sequence, trying to build it perfectly on the first try. Spacemars reminded me aptly that I needed to do the broad strokes first and refine later. Throughout the process, the challenge was to balance three aspects: learning, difficulty, and musicality. I had to choose which aspect to concentrate on and when, attempting to create moments that touched on two or more of them for maximal fun.
If I could change anything about the game, I would tighten the relationship between the enemies and the music. Adhesion’s musical sequences were great, but I felt the ones I added between were inconsistent in quality. With more opportunity to refine, I could tweak those sequences to mesh better with the overall experience. That said, I’m very pleased with how Tessitron turned out. Everyone on team RADMARS is insanely talented, and I feel really privileged to work with them!
And of course we have the illustrious Spacemars:
Everyone else wrote a mountain of text so ill keep this one short~
good:
Development went smoothly for the most part, no major snags.
Three.js is really an awesome (all be it poorly documented) library.
Teamwork, mumble(voice chat server), and git(version control) is a must.
Simple core idea, made gameplay simple, which kept the game engine simple (for the most part) KISS to the max.
Planning ahead pays off, we thought through things very carefully (thanks brendo)
(as a result) very minimal feature creep while developing.
bad:
time time time, never enough T.T lots of polish i never got to.
want a better control setup. ( Just not sure what it would be ?_? )
should have had color blind-friendly version *_*;
Really proud of this one, I think its the best radmars game we’ve made so far, was hella fun to work on. 😀
And last but not least, mine:
Another Ludum Dare, another chance for RADMARS to flex! After 3 consecutive 2D pixel art games (using melonJS, a great HTML5 game engine which we would highly recommend) we decided to do something at least a little bit more experimental – we wanted to do something in 3D, and despite not preparing enough before the compo (as per usual) we still nailed it. Plus it was a music game, something I’ve wanted to try my hand at for a long time. So!
The good:
-Audio! Of course. I’ve always wanted to focus more on music & sound design for Ludum Dare (previously I had to pick up most of the coding), and this was a great opportunity. I spent most of Saturday working on the song & doing sound design – the latter is not something I’m super experienced with, but it was really interesting to have the chance to try my hand at it in a more serious way, and it was a lot of fun too. Being very familiar with my tools (Ableton Live, NI Reaktor, Massive, Pianoteq & of course iZotope Trash 2 & various other iZo plugins) was great of course. Plus it was a really cool experience collaborating with Brendon for the enemy sequence melodies – an interesting challenge trying to come up with melodies that fit into particular sections of the song as well as being appropriate difficulty-wise for progression in the game.
-three.js – an awesome 3D library for the web. We didn’t lean on it too hard, but in terms of basic features and performance it was awesome, and it looks great (I wish we had time to do shaders!). A few rough edges in the API though.
-Team resourcing – as usual everyone had very clearly defined roles, and good tools to support working together (git, google docs, mumble) so we never really stepped on each other’s toes or blocked each other.
The bad:
-Browser audio still kinda sucks – this is really annoying. It’s good enough to make a decent music game, but I still don’t trust it enough to make a proper strict-timing rhythm game – I don’t think it’s low latency enough. In some sense I wish we were more ambitious and maybe tried to do it anyway, but that might’ve been a disaster. Plus there are still random bugs like the music cutting out super rarely, and looping that never works (why can no JS audio library do this right? ARGH). Sigh.
-Brainstorming – we came up with a good idea eventually, but coming up with it was particularly difficult this time around. We didn’t find the theme particularly inspiring at first, though it did help us pare down some of the details later on, which was nice.
-New tools/frameworks – even though our idea was pretty simple and not too extensive as far as 3D engine requirements go, there were a few issues along the way. We ended up having to write some framework/enginey stuff like a loading screen and proper animation timing towards the end of the compo, which was pretty frustrating since those had some scary bugs at first. Definitely something that should be separated out into common code we can use next time.
All in all I’m really happy with how everything turned out. We took some big risks but they definitely paid off, and we made a great game in a genre I’ve always wanted to take a crack at. As always, can’t wait until next time!
Tags: because it's more fantastical, Ludum Dare 26, postmortem, timelapse
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!