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. Be sure to Play and Rate games if you want a score at the end (we recommend 25 games). And with the holidays coming up, we encourage you to do it sooner than later. We’ll be back in the new year with the results, and the date for Ludum Dare 35.
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”.
I had to choose a very simple visual style because of the time I planned to spend on the programming (the amount of tutorial reading in the timelapse can attest of my experience in the matter), and it worked out pretty well in the end, with a visual style I’m pretty satisfied with.
I managed to set the scope of the game better, and to achieved a more polished game than with my preceding tries.
Overall, the working process and time management went pretty smoothly.
I did my first timelapse! Which is nice not only for the resulting video, but I realised that all these process screenshots were ideal to document my work and to analyse my workflow to make it better. I was also happy to have a vision of how the tree algorithm evolved with time, when working on it I was too busy with coding to screenshot every iteration!
What went wrong :
Due to my incompetence, I ended up with some bugs in the game which caused it to crash for some players, or to freeze. These are corrected now, but for next time, I’ll plan some time at the end of the jam to fix my mistakes! I lost some opportunities to get some feedback this way, and some interested poeple have been deceived, only because of me overlooking this issue when submitting the game.
I spent way more time looking for tutorials/information instead of actually coding, but this is a normal effect of my lack of experience with Unity.
Evolution of the tree generation algorithm:
For example, by looking at the screenshots here, made thanks to the timelapse, I can realise that the bigger trunks visible in one of the middle stages were quite interesting looking. For my next iteration of the program, I should allow to have a bigger size difference between branches and their children, to allow trees with this kind of style to grow.
Yup, got another timelapse up! This time, instead of using Chronolapse or FFMPEG to generate the video, I ended up using Blender instead. Let us know if it’s an improvement compared to the other videos in the playlist below.
Here’s our development process for hack.source.net, where I end up going circles debugging a ton of networking problems. Then a blur at the end where I drastically improve the graphics in the game. Ah, classic game jam panics.
Finally, find my (silent) development timelapse of my Compo entry Birds of Borg – it took a while, because I had to clean up the mess that happened from 3 Xserver crashes during the development :-X
“Birds of Borg” is a single- and multiplayer action game done as a HTML5 Web game with phaser and node.js/express/socket.io.
The breaks in the video have been shortened to 3 seconds video time, regardless of their real length. In case you wonder how long I actually slept, there’s a clock in the lower right corner…
A Post Mortem analysis of the development process will be published later. Probably tomorrow.
Have fun, and try to watch in slomo if the rapid screen changes make you sick 😉
Well, it’s done. I was working right up to the minute of the compo deadline, submitted on time, and then spent a bit of time puttering with a Linux port, fixed one stupid bug that survived, and played a few games – then slept for over 12 hours. But I did it – after 3 times overshooting my timeline, my Ludum Dare 34 game made it in for the compo.
One pleasant surprise I’ll mention now, though I’ll save the rest for a post-mortem in a day or two: since I just used Input.GetAxis, I had controller support the whole time, but didn’t notice until late on Sunday, so none of the in game text makes reference to it. The game is way more fun with a gamepad or joystick, if you have one handy.
And, finally, the obligatory timelapse of the weekend:
I developed a simple football game for the Mini Ludum Dare #63. It is supposed to have a fantasy theme, but I never got around to developing many of the features that I wanted. Although, I got most of the engine of the football game completed.