Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!
Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created. You NEED ratings to get a score at the end. Play and Rate games to help others find your game. We’ll be announcing Ludum Dare 36’s August date alongside the results.
New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.
Finally got around to editing the timelapse video for Nightshift Hope you enjoy!
Next up, I will edit the trainwreck of a first episode of let’s play your LD games. As many of you (five people that were there) know, everything that could possibly go wrong on a stream did go wrong, but it was fun nonetheless, so we’ll be trying on a slightly more powerful machine next time. But, submissions are still open, so:
We are Imperial Unit, a 2 man indie developer based in Australia. Ludum Dare 35 was the first game jam we have ever participated in – and we scraped through just in time to submit our game – Roamin’ Hordes.
Roamin’ Hordes is a hybrid between a tabletop wargame and a tower defence. We tried to think of something different when it came to the ‘shapeshift’ theme and we were inspired by the geometric nature of historical warfare, with ranks of troops arranged in formations, and having to change their shape to manoeuvre and hold the battle line.
Below is a time-lapse video of the game development, and a play through showing the real time large scale combat in action.
One of the goals was to show off huge battles with thousands of troops – which we accomplished by handling unit movement, animation etc. with the particle system in Unity. At the peak of the battle there are around 4000 soldiers displayed and performance remains fluid.
We tried a new approach with art, by first creating 3D voxel models, and then turning them into pixelated 2D sprites. We were aiming for the retro style that existed between hand drawn pixel art and modern 3D realism. In the end there was enough detail and animation that you could zoom from the map wide view into individual combat between formations.
We wanted immersive sounds to add to the atmosphere of being in a big battle, and spent some time to implement positional sound effects so you could hear the direction of marching barbarians, flying arrows etc.
The game only includes one scenario, and we didn’t have a lot of time to test the balance, but it seems to have turned out well – the scenario is definitely winnable, but it usually takes people a few attempts to understand the attack patterns and develop a counter strategy.
We were a bit slow paced in the first days, and found ourselves rushing and sleepless at the end, which meant several planned features had to be dropped to finish a playable game in time. The main ones were not having unit icons to make them easier to identify when zoomed out, a lack of variety in the barbarian units (we wanted calvary, chariots etc.), and only having one scenario.
The pacing of the scenario is not ideal, mostly as a consequence of only having one scenario, so it had to function as a tutorial as well as a challenging scenario. This means the first few waves feel too slow and easy, while things ramp up in difficulty in the later waves – having to go through the early waves again on replays can be tiresome.
There were several limitations with the particle system within Unity (for our unconventional use), which meant that parts of the code had to be re-written, and sprite atlases has to be changed and arranged in a specific way to work properly.
Too much time was spent background art (about 1.5 days) which would have been time better spent on creating enemy units and developing other scenarios.
Thanks to those who have tried out the game – all the feedback has been constructive and really helpful for us. For those who haven’t played it you can give it a try here.
Whew, another Ludum Dare down! Good job everyone – I’m enjoying what I’m seeing from other people’s efforts in this collective insanity.
This time around, I put together a game called Robot Escape. The weekend had its share of ups (I finished! I had fun! I’m proud of my idea!) and downs (I started over 12 hours late! I lost 2 hours to a power outage!) and I’ll put together a proper post-mortem soon enough. For now, the timelapse:
This LD was quite different from what I’m used. I had a few short slices of time in which I could work on my entry through the weekend, until I was finally able to work almost 10 hours straight on Sunday’s afternoon (the only part of the jam that I did timelapse).
Here’s briefly what went right/wrong:
What went right
I finished something
I used the theme on the narrative (in a way that I rarely do)
Even though running out of time, I was able to explain the theme in-game
Graphics were done quickly and (mostly) smoothly
Also, the flapping of the evil fairy!
I was able to do three (pretty simple) variations for the game’s theme song
What went wrong
The idea was too big for the time I had (less than 24 hours)
Everything is as rough and unpolished as possible
Gameplay is really dumb
I was away from my battle station until mid-day, on Sunday
And here’s the timelapse, taken for around half the time I worked on the game.
Later, I’ll write a proper post mortem. I’d like to explain why I didn’t have much time, how I got the game idea, how I quickly done the graphics… etc.
In total I spent about 30 hours making this game, 27 of which were recorded (I forgot to start the recording yesterday morning).
It’s outright scary to see that I spent almost all time programming instead of working on assets and even scarier to consider how much time I wasted moving code around for refactoring purposes. I guess I should look for a more efficient approach to making games. Or maybe a more efficient language than C++ 😉
I was thinking about writing a postmortem too, but I doubt anyone would be interested.
Trying to be ready for the next Ludum Dare, I’ve been searching for a tool to do the timelapse on MAC.
After some search, I found out that there’s no one simple solution for that, like we have for windows.
We only have one command line for that, which does not support multiple screens, and webcam.
Because of that, I did some home work, and found a way to do that.
I created one script which do that more or less automatically, using some open-source tools.
Basically, I do screen captures using the native screencapture
And webcam photos using imagesnap.
After that, I merge all the files using imagemagick
And to finish, I use the ffmpeg to create the video.
(First of all, I was originally concerned about not having enough votes when I started this post, but I’m all good now. That said, you should still play my game because it’s cool, but perhaps consider playing other games too, there’s still time!)
Tamamystery is a cutesy virtual pet game with nothing mysterious or nefarious involved at all. Nope. Why would you suggest that? Also it’s in Flash, so there’s no download or anything, which means you should totes play it!
Now that that’s out of the way, lets get to what this post is about: How I came to using papercraft for my Ludum Dare game!
The first thing you’ll notice is my freakish hands holding some type of paper-craft device. But it wasn’t always going to be this way…
Once I knew I was going to do something Tamagotchi related, I started off by doing the classic Google image search to get ideas.
So many Tamagotchis…
I also watched some Youtube videos to get an idea of how the Tamagotchi gameplay typically works. I also came across this Tamagotchi device with the little cake on the top, which I liked, and is why I added a bow on the top of my toy.
Apparently if you’re into Tamagotchi videos then you also want to know how to make a Crochet Mini Coin Pouch
So I started creating the graphics of the game. I knew I wanted the game to look like a real device, and so it had to be fairly realistic looking. So I started in GIMP, first by taking photo of an actual Tamagotchi and adjusting the colours a bit. Using that as a basis, I was going to try to essentially redraw it in GIMP, but soon realised that it looked pretty bad, and was going to take a while to do.
(I’m not very good at this way of doing art)
So I ditched that idea. Then I remembered “Hey, I’ve done nice vector stuff in the past, right? I’ll do it in flash!”. I quickly realised that THAT was going nowhere too.
I was hoping the grid would help me make things even, but I couldn’t even get the curves to look right
So I drew this little place holder graphics and moved on. Also, here you can see I had the idea of having a background that’s permanently etched in the game, like some Tamagotchis and small toys do.
The “figuring out graphics is a problem for Future Jez” graphic
Then I tried to figure out what it would look like on paper, and an idea hit me: If I can make it look good on paper, why not just use that as the graphics as is! I have a whole bunch of cardboard in my room (I often use it for craft things for kids), I had everything I needed really.
Even though I wasn’t trying to make it look good, I felt like this sketch was better than my my actual graphics attempts
The actual process of making the toy wasn’t too hard, all I did was draw each piece lightly on the cardboard in pencil and then cut out the outline. I made sure to measure out a piece of cardboard with the same dimensions as the screen so that they lined up.
To put the pieces together, I used Blu-Tack, which is good for two reasons. Firstly, because it’s not permanent so you can move things around. Secondly, it makes the pieces stick out a bit, so you don’t just end up with a flat piece of cardboard, but instead have something with a bit of depth in it. Depending on how much Blu-Tack you use, you can adjust the height of each piece a little bit.
From side on, you can see the layers… kinda. That screen is coming of a little.
To get it into the game, I just took a photo on my phone, put it on the computer, and then skewed it a little bit to compensate for the slight angle I took it at. Then I scaled it to make sure the screen was a nice multiple of the game window size, in pixels, because otherwise you get awkward half-sized pixels or blurry edges due to anti-aliasing, and nobody wants that.
This one is nice in the way that you can clearly see that it’s made of paper, it’s not as obvious in the actual one.
It looked pretty good at this point, but I felt like it needed colour to look more like an actual device. So I added in the colour in GIMP by using layers with the “Multiply” blending mode. If you just transparently overlay a colour, you lose some of the contrast as all your shadows become lighter, whereas with multiplying, you preserve all the blacks as black, and keep the subtle paper texture better. That’s a little tip for ya.
Whee! Timelapses! (click to see the unsquished version)
And to add in the hands, I just took a photo of me holding it with one hand in the different positions, and photoshop’d that in with GIMP (am I allowed to say that?). It would’ve been nice to set up a tripod and take photos of me holding it in the different positions to get the shadows right, but that also would’ve taken a bit longer and would’ve meant I had to skew, scale and colour 4 photos instead of 1.
Whee timelapses again!
And that’s it! I had a lot of fun with using papercraft, I might try to make an all-papercraft game next time. I’ll probably need some better equipment though.
Mount FuJ is a take on tower defense, or defend the castle style games. You play as an active volcano trying to protect the village that has popped up just below at your base. The village is under siege from an unknown enemy that is sending wave after wave of pikemen and horsemen units. The village will fight back, but it is no match for the army. You must use your volcanic ways to rain down lava balls on the enemy before all of the buildings are destroyed.
[Features that didn’t make it: If you are successful, the village will flourish and grow. However, as the village grows, it begins to spread into the range of your lava, so you have to be very careful to do more protecting than damaging.]
This was Zoe’s first game jam, and first game related project. Loi and Myself have been working together since Ludum Dare 30, and have formed Roaring Cat Games under which we publish our work. Our team formed as we were brainstorming at the live Ludum Dare meetup with GameDevLou. This was the first time that Loi and I have worked with a dedicated musician and sound designer (which was awesome).
Zoe used Logic Pro to record, mix, and compose music. She user her Casio Privia PX-160 keyboard as a midi controller to write the segments needed for composition.
Loi used his usual package of Adobe products but heavily worked in Photoshop to generate the art assets. However, this jam, he added a new tool into the mix with Spriter2D. Spriter really let him focus on the art and fluidity of the animations when during previous jams he was having to worry more about manually framing animation sizes and pivot points.
I chose to go with libGDX for this game jam as it is the framework I have the most experience with for games. While I’ve been doing some 3D work and learning unity since Ludum Dare 33, we knew we wanted to go with a 2D game for this jam, and I wanted to eliminate engine knowledge as a possible roadblock. We always like to challenge ourselves in some way with our projects though, so I did decide to throw Ashley ECS into the mix. I had used it for LD33, but only sort of embraced the ECS approach. For tooling I used: IntelliJ as an IDE, GIMP for placeholder art, and Git for version control.
We presented a less finished version of the game as the real-world Jam wound down on Sunday about 7PM:
Our brainstorm session was a bit longer than usual this time around. The existence of two possible themes really seemed to throw a wrench in our creative process. We kept falling into the trap of trying to force both themes into the game rather than focusing on one theme and discarding the other. Loi and I had also discussed trying our best to find a hack’n’slash to fit the theme, so I think that had us always coming back to “is this better than just building a hack’n’slash?” In no particular order, and with no further explanation, here is a list of some of our ideas:
Auto-run with Attack, Duck, and Jump all in two buttons
Snake/Centipede style game
Save the iceberg
Ninja absorbing souls into an ever-growing sword
One-punch man training simulator (w/ boss fight)
Tree vs. Lumberjacks Survival game
Avoid the expanding Objects
Dark Maze Puzzler
Grow and Shrink objects to get out Puzzler
TRex growing up
Lion hunt and roar
When we got to the end, our top 3 ideas were between a Growing Sword hack’n’slash, One-Punch Main Training Sim, and a combo of Volcano and Protect the Iceberg.
As a whole we were most interested in the One-Punch Man game, as it had the opportunity for lots of humor, and working with a story/world we all enjoyed. However, as we started designing out how the game would play, we realized that the mini-games were fun as a concept, but boring in actual gameplay. We came to the conclusion that we couldn’t make the game fun enough to move forward on.
Next in line was the Hack’n’Slash with a growing sword. We discussed it, and the game play was going to be pretty simple and fun, and the environment had a lot of potential for interesting visuals and sound. Unfortunately, once we started looking at some of the features that would need to be implemented and the number of animations and art assets required to match our vision, we realized that the scope was just a bit too much. I personally had some major concerns that I wouldn’t be able to figure out how to implement the sword mechanics we wanted in code. I kind of regret giving into that fear looking back, but it was probably the right call. Loi can blame me for dashing his Hack’n’Slash dreams until the next jam.
As we began finalizing our third choice, the volcano game, we all kind of realized it might fit our strengths really well. Zoe seemed confident that she could produce the tense, dramatic soundscape we were designing toward. Loi found the concept might lend itself to a painted style he’d been wanting to try out. I felt there were some interesting challenges in the code, especially with only my second project using Ashley ECS, but was all doable in a Jam time-frame. On top of this, once we all got on board, we began expanding some of the possible mechanics, and the game was sounding pretty fun.
Our process for building out the game was straightforward.
Work up a list of all the known assets (art and sound) we would need
Work up a list of all the programming features we need
Task out the features in order
Build each feature to implementation
Repeat 3 and 4 until the Jam ends
Check out this timelapse of the programming effort over 3 days:
While there was no intention this jam of keeping Loi and Zoe from playing the game until the end of the jam…it still happened. Due to the development tools, having the game up and running where we can all play it isn’t as simple as I’d like it to be. This means that unless everyone on the team sets up their machine for development, the only way to play is to jump on my machine.
I think we should have done more small 5 to 15 minute breaks where we all get together to test a mechanic, listen to a piece of music, or analyze an animation or set of art assets as a group. This is something that was missing from our process this Jam, and I think it did limit what we accomplished.
What Went Well
The art and music for the game turned out fantastic. Zoe and Loi nailed it, and I love the feel of the game with them in combination. The soundtrack is nice and tense, with a subtle yet still noticeable buildup of urgency. Combined with the SFX and the lava animations, it makes for a very cacophonous battlefield scene. Yet, somehow with all the explosions and battlefield tension, there is a soothing calm to the experience as well. About halfway through the jam I could see that the music and art were going to need to take the main focus of the game.
The collaboration between the team went smoothly. We were each able to spend the majority of our time in our own tasks but were able to stop and discuss next steps/changes as needed without any issues. I think being in the same location really helped with that, and I can’t recommend enough that you try to join a real-world meetup if possible.
Coming together on Monday after our day jobs, we were able to pull off a lot of work right at the end. Sunday at the end of our day, we barely had a game. The wave system didn’t work, there were no sound effects, there was no balance to the enemies, and worst of all the game didn’t do anything to highlight the great soundtrack. On Monday we were able to take a step back, prioritize the features to make it a game, and knock them out with just a few minutes to spare for submission. This final crunch period went really well, and it was very satisfying to see how quickly we could get things accomplished under pressure.
What Didn’t Go Well
Coming up with a damn name for the game… This is the first jam I feel like we never had a clue what to call the game. If anyone has any great ideas for what this game should be called leave it in the comments below. We were just drawing blanks the whole time.
I feel like I was the weak link in this jam. I’m not sure what happened, but between saturday about lunch all the way through sunday about 10am, I just couldn’t get anything going. I was writing code, but it was all non-essential background placement or environment building code that I could have (and should have) knocked out towards the last few hours. I think I was dealing with a rough combination of:
Exhaustion (I had not been sleeping enough all week prior to the Jam)
Doubting my abilities to implement features
Lack of clarity on how some of the mechanics needed to work
Worry that I may have talked the team into a game that just isn’t fun
I definitely should have started working on having the lava destroy enemies much sooner as that is the key mechanic of the game. I had the lava-firing and charging really quick, and it then just didn’t do anything with it for almost 24 hours. I made the mistake of not building the basic mechanic up front so we have time to tweak and make it fun. On the plus side, I’ve learned that lesson (for at least the second time now! :)) and will be able to remember this instance to hopefully keep it in my mind going forward.
In the end, we feel our game has a pretty fun mechanic hidden inside of it. We’d like to tweak some of the known issues (spamming lava is an auto-win, no visual indicator to know how charged up your lava is) and add touch controls. This would allow us to release the game out for mobile devices as a little time sink. We’ll definitely need a scoring system, and a way to indicate that fun you’ve lost. The win sequence needs some work as well.
“I was very excited for this Jam and challenging myself with Ashley ECS. While I’m disappointed in my output for the Jam, I was able to build out some pretty generic Systems and Components that will be useful for games in the future, and I plan to clean them up so I can open source them as an additional library for other libGDX developers. I’m very proud of the work our team produced, and I hope the shift in focus on Art and Sound comes across for those playing our game. It was an exhausting, humbling, stressful jam for me, but as always I’ve learned a ton and am even more ready to jump into our next projects.”
“So, the whole week leading up to Ludum Dare 34, I was filled with excitement! Excited to create something new! Excited to take a break from RCG’s personal 3D project and get back into designing 2D characters and environments again. In the days leading up to the Jam, I started playing around in Spriter 2D (an animation creation and management program that I had been wanting to learn since the last Ludum Dare), because I was looking forward to making a hack and slash. Spriter 2D would have been perfect for animating action frames, as one of its unique features is bone-rigging and attaching them body parts and objects. Spriter 2D was very productive; it saved me a lot of time with image file management, ease of exporting animated frames, and having a simpler, yet more extensive, animating options that were non-existent in Photoshop. It allowed me to focus more on content creation rather than spending a lot of time on filename and manual frames export, which can be tedious and time-consuming when you trying to create a smooth animation sequence.
As always, I wanted to challenge myself to a new art style every Jam. This time, it was watercoloring in Photoshop. I haven’t used watercolor paint since I was a wee-lad, and picking it back up again felt a bit strange, especially now that I am doing it digitally and my paint brush is my tablet pen. The hardest part in the beginning for me was getting the brush settings just right to give it that wet outer-edge water-effect look. Below is my custom brush settings that I used throughout the Jam (works best with a drawing tablet, as it emulates brush pressure and strokes). It was nice to use watercolor inside of photoshop without the mess to clean up afterwards”.