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.
If you are coming to MAGFest we are hosting a 2 hour tabletop game jam Saturday at 3:30. No experience is necessary and supplies will be provided. There are also several other really cool game jam panels this year including my “How to make a game in 48 hours” panel tomorrow! I hope to see you there!
Just a head’s up for anyone coming to MAGFest this year. We will be offering a small Game Jam track this year. Starting with a Q & A panel with some experienced jammers including 01010111 winner of Ludum Dare 32, and Susan Gold the President/Founder of Global Game Jam. After that panel we will take a short break and begin a One Hour Game Jam. This is not a normal game jam, instead of trying to create a full game the participants will be tasked with creating an original game concept and present it to the group. Also, it doesn’t need to be a computer game, it could be a board game, card game, or even (gasp) a sport. I’ll be hosting and hope to see you there!
Friday @ 1:00 – Game Jam Q & A – MAGES 1 – Chesapeake GHI
Friday @ 2:30 – One Hour Game Jam – Forum – Chesapeake JKL
Ludum Dare 34 had two themes “Growing,” and “Two button controls”. I tried to hit both making a 2 button controlled infinite runner with a vine growing in front of you. This was my first time using Unreal for a game jam, and tried doing many other things differently this time.
Going into the Compo I had some specific goals in mind…
Use Unreal Engine 4, my first time using it in a game jam.
Do all programming in blueprint to practice visual scripting.
Add music, planning to use Figure for iPhone.
Hooking up Unreal to ToritseSVN, my first time connecting the two.
Make a game that would work on mobile.
Proud to say that I accomplished all those goals and more with my entry. Though I struggled initially and wasted much time trying to solve issues with Unreal. What’s funny about Unreal is that some stuff is super easy but other stuff takes way longer you’d expect.
Friday – Concept
I liked theme this time around, thinking about how to combine two different themes was really fun. Two button controls works perfectly with my idea of making a mobile game. For growing I wanted to experiment with organic looking procedural level generation using spline meshs. I started by scribbling down about 10 possible game ideas. My best idea at the time involved 3 or more splines that you flip between using two buttons, maybe you are spiraling around the splines. I wasn’t fully sold on the idea though and wanted to sleep on it before starting any actual development.
Doodle I made late Friday night with my spline idea.
Saturday – Procedural level generation
I must have been thinking a lot in my sleep because I woke up with a completely new and fairly complete idea, racing along a tube shaped object, using the two button controls to rotate around. Something like the map in f zero where it’s a tube shape, but as an infinite runner. I decided to keep it simple and not try too experimental of an idea since I was trying a new game engine.
F-Zero GX – One of the best gamecube games
I started a new blank project with starter content. My first goal was getting the procedural generation working. A few weeks ago I followed a pretty cool infinite runner in unreal tutorial in unreal. I recommend that tutorial for a first introduction to Unreal. For my idea it needed do work much differently in order to generate the level along random spline. Also I couldn’t rely on physics since there is no collision generated from spline meshes and it would probably be too bumpy anyway so I started from scratch for the player movement and controls.
2 PM – Experimenting with level generation
I use TortiseSVN for all my home brew projects and heard that it had direct support in Unreal. It was fairly simple to hook and worked well, at least in this simple test case.
The level generation took almost all day on Saturday. There were some things from the content example project that helped me figure out how to work with spline meshes. I started out by generating a bunch of random spline curves and creating spline meshes for each section. This took a long time because of various issues I ran into with spline meshes. It would be nice to be able to visualize a spline mesh in game but I couldn’t find a way. I also had a problem with them twisting into a singularity and had to limit the maximum random angle that could be applied. I seemed to mostly have fixed it by limiting the maximum angle, but need to experiment with it more to figure out what exactly is going on.
Twist in spline mesh
For the spline mesh I started using the pipe shape from the UE starter content. That worked well enough for testing but I wanted to smooth the normals to be more round. I tried making a cylinder BSP by extruding it into a few intermediate sections and converting it to a static mesh, but that also caused lighting issues and bad UVs. I have never used Blender before but heard it was free so I downloaded it and set about making a simple cylinder. I found the interface to be extremely confusing and was constantly clicking on things accidentally that I would have to undo. Somehow after well over an hour I managed to make the cylinder, the UVs still don’t wrap properly but it’s good enough.
I spent a while messing around with the procedural generation, tweaking different variables that control how much it bends and stuff. I originally planned to have the track go straight up like a beanstalk, but noticed that it looked cooler when you could see the sun and horizon.
7 PM – Player movement down the track
With the level generation working I moved on to player movement. I wasn’t able to use physics for this game because the spline mesh doesn’t actually have collision. So the player moves along the spline automatically using controls to change the roll component. I started with a first person perspective, but after experimenting I noticed that seeing the player in front of the camera feels much better and helps players understand their collision size.
One problem with the splines in Unreal is there’s no built in way to remove a point from the front of the spline. I need to remove the parts of the spline behind the player as they went along. So I wrote a function that dumps the spline into an array, clears the spline, then dumps it back minus the front node, pretty sloppy but it worked.
I also added some obstacles to avoid that are randomly placed around the mesh, a score display, and damage the player when they hit something. I like to have at least the basic gameplay in by the second night.
Midnight – Made the player a rolling ball and added obstacles
Before going to sleep I crammed in a bunch more stuff like a high score save and blue pickups that give health.
Sunday – Making it fun and polish
I began the day by adding polish to make it feel more like a complete game. Generated a bunch of random sounds in BFXR. Added camera shake when you collide. Added a start and end screen. Play tested and did a full tweak pass.
I spent a while working on materials for stuff, finding it very slow to iterate in the Unreal material editor. The preview window would sometimes take a minute to update after making a tiny change and applying the material to stuff in the game took several minutes. I ended up just making modifications to the default materials. The thorn and berry materials was originally the default steel material but I added some code to make them emissive and colored. I also made a simple dot material for the pickup particle system.
The destruction effects were made by taking the cone and donuts meshes and making them into destructible meshes. I have them set to listen for overlap events from the player and apply a damage event with physics impulse. For the berry powerup I created a particle system from scratch. For collisions I just used the default explosion effect and default smoke when you die, and didn’t get a chance to tweak them. I also enabled depth of field and played with other visual settings and colors for a while.
I used Figure on iPhone to make the music. This is a great little program for making music quickly. I made a few 8 bar loops, then picked the best one and improvised with it in a live performance, changing around which tracks are played and adding tweaks/filters. I spent maybe two hours the most making the music. I also hooked up the music to speed up with the player movement and slow down when you take damage.
With only a few hours left in the jam I still didn’t have a jump mechanic. I really wanted do something when you press both buttons at once, kind of a way to sneak in a third button. So I added the yellow donuts you jump over. They work similar to the cones but are oriented differently. The jump physics were done from scratch, using a timeline to control the height.
Towards the end of the compo I had some time left so I added a bit of a difficulty ramp so it starts out straighter with a few less obstacles. As I was making some final tweaks and play testing and I had a few last minute scares. One where I noticed a major kink in the road caused by setting the max spline rotation too high. Another where I had lowered the start point to increase the initial fog density and that caused the yellow donuts to not show up, weird stuff. Thankfully I managed to fix those bugs and check it all in before the deadline.
3 PM – Better gameplay with heath bar and pickups
What went right
Unreal is a pretty fun engine to work with, but some seemingly simple things can often be difficult to figure out.
Using TortiseSVN with Unreal worked really well, though I didn’t need to do anything advanced.
I really tried hard to keep things simple and it worked out well.
What went wrong
Converting BSPs to static meshs in Unreal has some bugs and is very limited.
Blender is a very difficult and non-intuitive program to use, I spent over an hour trying to make a simple cylinder shape and still messed up the UVs.
Making material changes in Unreal was an extremely slow process with changes sometimes taking over a minute just to preview then when I save a change it wanted to rebuild all the shaders in the project. This seems like it really needs to me improved by Epic.
Made what I thought was a harmless change at the last minute and almost broke a major component of my game.
I don’t like how big my project is, just the final zip file is over 100 meg.
I made a 2 button infinite runner, press both at the same time to jump. This is my first time using Unreal for a game jam, actually my first 3d game jam. What’s funny about Unreal is that some stuff is super easy but other stuff takes way longer you’d expect I also made it fully in blueprint. Most of my time was spent getting the track generating well and player movement. Also I had to learn a lot along the way. I will write up a full postmortem soon.
Unreal is a fearsome beast but I am slowly taming it. Working on an infinite runner type thing rotating around splines. There is a lot more 3d math involved then I hoped but its working pretty nicely now. Compiling shaders sucks and blender has the worst interface I’ve ever encountered. Still I venture onward. Basic gameplay is working. Need to add more polish.
Just for fun, here’s a screenshot from earlier when it was having some problems…
You guys might be interested in watching this panel we did at MAGFest with some LD veterans including 01010111 who went on to win LD32. There’s some great info here for sharpening your rapid prototyping skills. Worth watching for first timers as well as experienced jammers. We will be doing another similar panel at next years MAGFest in Feburary and a mock game jam, I hope to see some of you there!
I’m going to try something different this time around and use Unreal. In the past I’ve always used my own open source game engine, The Frank Engine, but I’ve been learning Unreal for about a month and I think this will be a good exercise. I’m also going to try making it all in Blueprint, so no code either. This time I also want to make music, probably with Figure on iPhone.
Another Ludum Dare has come and gone, and I’ve managed to cobble together something that resembles a game. This time the theme was “You are the monster”.
Friday – Concept
I had some trouble coming up with a concept at first and started writing down as many ideas as I could. The idea of an old black and white monster movie came coming up. I was thinking about old monster movies like Godzilla which reminded me of Rampage so I played the NES version for a bit to help come up with ideas. The funnest part about Rampage is climbing on buildings and breaking them down, so I decided to concentrate on mostly that. At the time I wasn’t very confident on my idea though and was afraid to get moving very fast because I was hoping that a better idea would come up. I ended up wasting about a few hours adding some random feature to my game engine that wasn’t even used on this project.
The only real bit of development I did on Friday was to quickly block out what a scene might look like using the tile editor in my game engine. This screenshot shows about as far as I got the first night…
Friday night – 3 hours in – Rough concept
Saturday – Building Physics & Platforming Mechanics
I tried to hit the ground running on Saturday and worked through most of the afternoon getting the building simulation working. It’s a pretty simple concept. Buildings are made out of square blocks and connected to neighboring blocks in a grid. Blocks apply a force to their neighbor to keep them connected, and break if they get pulled too far apart. It took a lot longer then I hoped to get the physics tweaked out properly. It’s like if you apply too little force the the buildings just fall apart, but if you apply too much they freak out and explode. So getting that working took most of the day and I was discouraged at many times because I thought the idea would not pan out for technical reasons. One problem throughout development was that the physical simulation is fairly taxing and does not run at full speed in debug mode.
Saturday Night- 24 hours in – Physics sim on buildings
I also added some simple platforming mechanics and the ability to grab onto buildings. First tried using a distance joint for grabbing but threw that out in favor of just manually applying an acceleration to the grip point. Spent probably way too much time working on the player sprite and went through many variations. I started with my sprite from LD31, morphed it into something like Frankenstein, then went greyscale, and finally back to color with a more surreal looking sprite. I thought glowing red eyes would look cool, but it wasn’t visible enough and I wanted to draw more attention to the player so I switched it to be a glowing sprite with black eyes. There were a few revisions in between that I lost, and research into other ideas for characters.
Player sprite evolution
I wasted much of the night on Saturday. Took many breaks include a several hours long dinner with a friend. By the end of the night I was still not sold on my concept and it didn’t really come together until the next day.
Sunday – Fire, Enemies, Random Levels
I worked pretty hard on Sunday in an attempt to make up lost ground. Adding the fire spreading across the buildings was a major improvement in making the simulation interesting to watch. I also added a kind of electricity simulation that turns window lights on/off randomly if they are connected to the ground.
One major thing still missing was any kind of enemies that attack the player. I ended up with only enough time to add one enemy type, planes that fly around shooting the player with a machine gun when they are in range. The flight patterns took more time then I expected because I wanted them to fly somewhat realistically to match with the realistic physics on the buildings. Since the game wasn’t much of a challenge with only this one enemy type I ended up making the fires damage the player, still not sure if that was the right decision because it can detract from the joy of destruction.
I spent about an hour on Sunday adding sound effects. I’m not very happy with the results, but it’s better then nothing. There was a lot of other features that I probably could have skipped. For example there is an intro section where the player starts small and transforms. It was a cool idea but I didn’t polish it enough to call it out and it will probably be overlooked by most players. Also the little tiny humans are kind of hard spot, and their physics/AI is wonky but I wanted them to give a better sense of scale.
The last thing I added was the random city generation which I banged out in less then 30 minutes. It was a risky thing to add at the end, but I didn’t know what else to do after you destroy the city. There wasn’t time to add any randomization on the trees or little humans, so they always in the same places from the editor. I would have liked to add a lot more variety in building type and stuff but there wasn’t enough time for such luxuries.
What Went Right
Visually looks pretty cool and is fun to watch.
Physics destruction sim is pretty cool.
Gameplay demonstrates that this could be a decent game if polished.
What Went Wrong
Building physics is a performance hog. Does not run well in debug mode.
Sound effects are horrible.
Got discouraged, didn’t trust my idea, and wasted a good portion of the weekend.
Visual Studio keeps freezing up and I have to manually shut it down in task manager. This happened at least 10 times and throws off my forward momentum because I forget what I was working on and lose my place in the code.
Wasted too much time working on stuff that got thrown away or didn’t matter.
I’m glad that I participated in this Ludum Dare, though it’s not my best entry. I took a chance on a technically risky idea and it payed off pretty well. Also, I think this is probably my strongest in visual imagery in a Ludum Dare. I will continue working on it and release an enhanced version with 2 player support soon.
I had trouble deciding on an idea but pushed through as best I could and this is what I came up with. It’s mostly a physics playground but I think it looks kind of cool and with a little more polish could be pretty fun. There is not as much gameplay as I would have liked. Also the sound effects are really bad. I programmed the randomness in about 15 minutes at the very end of the compo so hopefully it works.