Ludum Dare 29
Ludum Dare 28
Ludum Dare 27
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
Best Game of Ludum Dare 29
Awarded by Rother Games
on May 1, 2014
Most twitch viewer's - by far!
Awarded by Aske
on August 19, 2013
General expression of well-wishing.
Awarded by xgeovanni
on December 5, 2012
Probably the most famous person with two trophies.
Awarded by Spaceoff
on September 4, 2012
Probably the most famous person with no trophies.
Awarded by xgeovanni
on August 27, 2012
This was my 8th Ludum Dare but only my second time doing a strategy/simulation game — which is weird, because those are the kinds of games I live for. I think the barrier is typically that coming up with game mechanics and balance is so much trickier for strategy/simulation games than a more arcade-y one. Additionally, most strategy/simulation games take a while to learn, master, and fully experience — and for Ludum Dare I always aim for something that is playable in 5-10 minutes.
What Went Right:
- Streaming. Nothing else keeps me more motivated, interested, on-track, and just plain-old entertained as much as streaming the creation process does.
- Low-FPS Pixel Art. I’m actually pretty quick at making simple 3d models so I’m not sure that it saved me any man-hours, but given the amount of stuff that would be visible, pixel art made more sense from a visual and technical point of view. The overhead on the CPU/GPU would be reduced, but also most of the animations in the game are set to run at 2 FPS…and they look good doing so. They only have 2 or 3 frames of animation, and that turned out to be ideal to show “work” happening without being too busy.
- My schedule. I always do the same thing, and it always works well. Friday is 1 hour thinking about the game I want to make, then 2 hours prototyping. Saturday morning I’m allowed to throw everything out and start over — but otherwise is all feature development. Sunday is meant to be all polish (though a few last minute features usually get developed here too). I always plan on submitting the game an hour before the deadline (that way I can deal with any last minute disasters). I get lots of sleep, and I try to go for a walk around the block every hour or two.
- Knowing my tools. I’ve worked with Unity and C# for three years now, including six previous Ludum Dares. While the 2d toolkit is still relatively novel for me, most of the fundamentals are solidly rooted in my brain now, which means less time checking documentation or figuring out the best way to implement various mechanics.
- Working within a genre I know well. While almost none of the mechanics work in any way like SimTower’s (there’s no elevators or day-night cycle), the fact that I was able to visualize the look and feel of the game before I started made it easier to stay focused.
What Went Wrong:
- OMG WTF IS WRONG WITH YOU. Every competition you say “I’ll just make something simple like a themed Pong,” but nooooooo…you have to go and make a game that requires a ton of animations, relatively complex AI, interactions between different types of units and different types of buildings, resource management, etc… The number and complexity of the bugs you had to squash was ludicrous. You are not a good example of what people should attempt during Ludum Dare. At least you didn’t do multiplayer again (LD 23 & 26).
- It’s an established fact that Unity really doesn’t perform well when you have many, many active GameObjects in a scene. They are just too “heavy”. Despite this, I went with a game where each tile is implemented via its own GameObject…with several components. This made development much quicker and easier, but I was taking a massive risk that the game wouldn’t be performant enough. I had to adjust the scope of the game (camera zoom level, victory condition) to help keep the number of tiles modest. Anyone who continues the play past the victory condition will start to experience poor framerates.
- God damn freaking gaps between god damn freaking tiles. Lots of people have experienced this issue with Unity 2d’s system, and no amount of Point filter modes or camera orthographic nonsense could get true pixel-perfect placement in Unity without using custom shaders. I will NOT be using the built-in 2d sprite system for background tiles ever again. It’s slow and doesn’t work right. I wasted far too much time trying to resolve this, and the issue can still sneak up in the final build at certain resolutions.
- No ability to do spritesheet/palette swaps using Unity’s built-in 2d animation system. Unity’s 2d sprite splicing and animation system is excellent for a lot of things, but because it does all the heavy lifting in the editor there’s no way to do a spritesheet substitution at runtime (to make it easy to have the different worker careers have different outfits). This is something that would have been possible if I’d written my own sprite handler (which wouldn’t have been difficult).
- Improper nutrition. I always prepare good, high-quality food before Ludum Dare…but this time I more or less forgot to eat it. I spent Sunday afternoon completely burned out until I had a proper meal and my energy levels shot up. I should have forced myself to eat more consistently.
What’s Going to Happen:
I was already working on a Unity Tile Engine. I’ve now added support for multi-tile, animated “rooms” and run tests to see if the performance problem was resolvable.
The Ludum Dare version needs about 30 tiles wide and maybe 30 tiles deep (about 900 tiles). I want to support an area that is at least 100×100 (10,000 tiles). So…I tested a map that was 1,000 x 1,000 (One million tiles). To make things even more difficult, I tested on a 3-year-old MacBook Air, the weakest computer I could get my hands on.
Visual FPS – Minimum Required: 60. I got 350 with ~100 tiles visible and 150 with ~500 tiles visible (which is so far zoomed out that you won’t be able to make out tile details).
Simulation Thread FPS – Minimum Required: 2. I got 30. On a 100×100 map, I get 3,800 fps. If I want to tempt ever more complex multithreading issues, I should be able to improve the performance even further for multi-core systems since I can easily chop up the map into chunks for simulation.
So I’ve definitely got an engine that can support an extended version of Drill18. It’s also immune to any weird “gap” issues in the background. People also seem to like the game. Will this finally be my time to release a polished version of a Ludum Dare entry?
“First superaddictive game on this compo” — TeamInCharge
“Complete 5 stars. I’ve been playing it for god knows how long.” — CoderMusgrove
“if I wouldn’t see your stream doing it, I wouldn’t believe you made it in 48h” — dusho
“Wow! this was the first game I [kept playing] after I was done rating it” — Dreii
“Fantastically fun” — zkenshin
“Impressive is the word.” — javifugitivo
“Oh my god the addiction” — tomvert
“Those small details and animations everywhere are what makes you love games” — PapyGaragos
“This blows most of the other games out of the park.” — Bevilacqua
People are constantly asking the same questions over and over, so I took it upon myself to try to write up a clearer version of the rules.
I look forward to Ludum Dare more than any birthday or holiday. Here’s my “I’m in” post.
Except for the time that I participated while flying across the Atlantic, I’ve always livestreamed the entire process from start to finish. For LD #28, I had tens of thousands of people watching me — and if you told me before all this that people would be willing to watch someone program in real time, I would have told you that you’d be nuts. I guess maybe it’s just my audience that’s nuts.
Tool disclosure: Unity, Photoshop, Audacity, Blender, and possibly the A* Pathfinding library from Aron Granberg, which I still prefer to the built-in Unity pathfinding. Additionally, I may use some code from my freely available Unity 3d tutorials. Specifically, I’m feeling a little “tilemapish”. I’ve done a couple of multiplayer games in the past, and if I go down that route again I’ll likely make use of Photon.
BTW, for all you Indie Devs — I do game preview/review videos on YouTube. I have 140,000 subscribers and I love to cover indie stuff (primarily strategy, simulation, and RPG games for PC). Email me at firstname.lastname@example.org if you have something you think I should see.
48 hours to make a game isn’t crazy enough. Why not add multiplayer?
You can play my LD #26 entry here: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=7862
I’ll be trying to make another multiplayer game this time, if the theme fits. Maybe something more strategy-oriented.
Watch the tutorial video here: http://youtu.be/AIgwZK151-A
I actually make a lot of Unity 3d tutorials, and my First-Person Shooter one is definitely the most popular of the bunch. Now I’m raising the bar by making a complete Multiplayer First-Person Shooter using only free stuff available in Unity.
What is covered:
- Building a level in Blender 3d
- Texturing and UV Mapping
- First-person character controller
- Photon Unity Networking, Cloud-based servers
- Matchmaking, room-creation, and joining
- Syncing character positions across the network
- Mecanim-based character animation (Running, Strafing, Jumping)
- Shooting, Taking Damage, and Dying
- Using RPC calls to broadcast events across the network
I didn’t think I’d be able to participate at all this Ludum Dare, as a result of being out of the country for business-related activities. However, I really didn’t want to break my 6-LD streak, so I decided to take my own advice: Just participate in any way you can, even if it’s just with an extremely simple game.
So when I found myself on a trans-Atlantic flight with no mouse, no Internet access, but with a small amount of free time, I decided to do the best that I could. What resulted is a infinite-frogger-style game with a very weak hacking theme. What I really wanted to do a riff on the Hollywood-style hacking visuals that you see in movies and tv shows. To do it right, I would have really needed some nice custom shaders, and that’s not something I can produce without more time AND access to copious documentation.
Still, in the end I produced an actual game. It has loss conditions (get “traced” by running out of time, smash into a firewall) and a goal (accumulate as many points as possible before you inevitably collide into the ever-speedier firewalls, or run out of time of course). My interpretation of the “10 seconds” theme is very obvious, but enabled me to focus on a very simple arcady game that would be doable in just a few hours.
I started the game when I was still in Germany, finished it up somewhere over the Atlantic, and uploaded it using the Toronto Pearson International Airport’s free wifi.
Things that I did this Ludum Dare that pretty much go against every recommendation:
- Throw away everything and start over from scratch after 13 hours into the competition with a completely different game.
- Make a 16-player multiplayer game. With automatic matchmaking.
- AI bots too, to fill any empty slots automatically. Make sure they have the ability to navigate a 3d space in real time, looking for powerups if there’s nothing to kill.
- Livestream the whole thing to almost 8,000 unique viewers and try to keep everyone entertained while coding.
- Include nearly 50 different death sounds, because it’s not like we’re on a tight deadline or anything.
Despite all these ridiculous challenges, I’ve completed what is by far my most fun Ludum Dare entry ever! At peak load, there were nearly 200 players connected simultaneously to the multiplayer servers. The only unfortunate thing is that now that the stream is over, there are sometimes no human opponents available — and they really make the game a lot more enjoyable.
If you’re going to test Shoot (AAA_FPS_GOTY), see if you can get a friend or two to connect at the same time. It’s way more fun than just fragging bots.
This visual makes death sting a little less.
Everything you see in Shoot (AAA_FPS_GOTY) can be made using entirely free tools.
I used the trial copy of Unity 3d Pro that was offered for Ludum Dare, but the free version would have been perfectly sufficient. The only “pro” feature I used was the shadow on the character — but a blob projector would have been just as good here. I also made use of the A* Pathfinding Project Free library as well as Photon Unity Networking. A free Photon Cloud server is used for matchmaking.
I used Blender for modelling — including making an animated character for the first time for use in an actual game. That was fun. The textures were drawn in Photoshop, but could have been made in Paint. I also used Substance Designer (trial) to get the ambient occlusion texture for the character as a learning experience, but I could have done the same thing just as easily (better?) in Blender itself.
The face of a killer.
Anyway, I hope you can take the time to try Shoot (AAA_FPS_GOTY) and pwn some noobs.
I have a bunch of easy to follow tutorials for Unity 3d available on my channel, including things like sound manipulation and networking.
Source code for the projects can be downloaded from here:
There’s not much in there that’s terribly sophisticated — but you may consider the code to be publicly-available libraries/templates for the purpose of using it in a Ludum Dare entry.
Good News: My toolchain seems to be in great shape.
Bad News: My Internet is poop?
The only reason I enjoy Ludum Dare as much as I do is become I can livestream the whole thing and get a few hundred of my viewers to keep me entertained while I work. It’s an amazing 48-hour party that just happens to result in a game being produced in the end. Unfortunately, my Internet seemed to cut out for a few seconds every few minutes, resulting in the occasional lag-fest, or an outright disconnect of my stream requiring me to restart it. This is very distracting and extremely frustrating. After calling it quits, I went and checked the various cables that my ISP setup as part of my fibre install and I think that I tracked down a faulty Cat-5 connection between the transceiver and the modem/router/firewall. I have replaced this and since then, my connection appears to have stabilized. Unfortunately, the problem was intermittent in the first place, so who knows. I’m also getting a tech from the ISP to check the signal strength on the actual fibre line, just to be positive.
I will be doing additional streaming this week (SimCity!) to see if things have stopped being poop.
Programming environment/library declaration: Unity 3d, including built-in standard library assets. Additional publicly-available libraries that might be used depending on theme and how feisty I’m feeling: Photon Unity Networking, A* Pathfinding Project, whydoidoit’s Loom, Unity Serializer, usfxr. Because obviously a multi-threaded, multi-player game with intelligent enemies and proper save/restore functions is TOTALLY doable in 48 hours.
Pong. I’m making pong.
Anyway… while other tools are not required to be declared, I like to list the ones that I’m likely to use because I like it when developers highlight useful stuff. I’ll be making use of some combination of: Photoshop, GIMP, Paint.Net, Substance Designer (including built-in Unity 3d substance generators), Blender, Audacity, BFXR, atrk-bu, SchismTracker, Spacescape, XSplit, Sublime Text 2, Notepad++, and more!
Livestream will begin at 16:00 UTC on Saturday, April 20.
I’ve already made one Unity 3d Multiplayer Tutorial, but there have been a lot of people asking for more depth and details, plus for an example of a multiplayer FPS specifically.
I’ve been in contact with the amazing people over at Exit Games (the Photon people) and they’ve arranged a 1,500 concurrent user demo server (my livestreams have peaked at 4,500 viewers — though I don’t expect that many tomorrow).
It should be an awesome time. This is also going to act as a warm-up for Ludum Dare. Make sure to go to the Twitch.TV channel and “follow” to be alerted when we go live.
If you can’t make it, videos should be available later on my quill18creates channel on YouTube.
I’m going to attempt to place the complete project on the Unity asset site afterwards, assuming I can figure out the submission process.
Like a smoker waiting for his lunch break, I am craving the next Ludum Dare. This will be my 5th time participating, and each time just gets more and more fun.
Why do I love LD so much? It’s a combination of things. Certainly I love making games, but that’s only part of it. Part of what makes it so fun for me is the fact that I livestream the entire process for my relatively large audience. There is something unbelievably gratifying about getting instant reactions about your ideas and massive amounts of feedback as you post hourly builds (most of it complaining about how it’s not a AAA-quality title). Last LD I peaked at around 600 concurrent viewers. I strongly expect that I’ll pass 1,000 this time (with 5,000+ individuals checking in over the full 48 hours).
For LD #23, I did a multiplayer strategy game (a sort of “Chess meets Starcraft”), which was a great way to bring my audience together. However, because games took a while to play out and because you needed to create a user account, the LD judges often were not able to fully experience the game. But since then I’ve done a tutorial for multiplayer in Unity 3d on my programming channel — and it’s got me thinking that I’d like to revisit the idea of doing a multiplayer game for LD, but now with instant, automatic matchmaking and much faster and shorter gameplay sessions.
I’m almost certainly going to have to drop a few bucks to acquire a server that can handle the required matchmaking (which is not optional, IMHO) — but I think that the pleasure I’ll derive from having my community play together (destroy each other?) will be priceless.
Being so close to the holidays, I have numerous engagements during this LD — but I’ll try to squeeze in a few hours to do something super-simple.
Tools: Unity 3d, Photoshop, GIMP, Blender, Audacity, BFXR, atrk-bu, SchismTracker, iTween, A*Pathfinding, Orthello 2D (maybe).
Will be livestreaming here: http://www.twitch.tv/quill18
Pre-LD Warm Up
Going into LD #24, I knew that I wanted to create a faster-paced, more “arcady” game, since my previous two entries were a turn-based strategy game and a moody story-based game. Two weeks before the competition, I decided to do a warm-up based on a theme that NEVER wins the LD voting…Evolution. So…yeah.
One valuable thing I learned, after a few dead-end ideas, is that while I *love* simulations and that I’m really interested in simulating biology and evolution…it was hard to find the game in literal evolutionary processes because it’s supposed to be rather…automatic and non-interactive. I couldn’t come up with something that was simultaneously enough of a “game” but also felt like “legitimate” evolution. Just making a _________ and tacking on an Upgrade system is pretty ridiculous. If that’s the kind of thing that’s acceptable, then 90% of the games on the market are about “evolution”.
Ultimately I decided that the right thing to do would be to start from a strong gameplay concept and use evolution as a pure story/visual theme, rather than a mechanic. So for my warm-up I ended up doing an (incomplete) implementation of a Tower Defense game in the style of The Space Game or Creeper World, where you are building a linked network of structures. You would represent a multi-cellular creature that was developing specialized cell/tissues/organs.
I still think the Tower Defense evolution game would have been great, but I didn’t take that route for the actual Ludum Dare because:
a) I’d already done a partial implementation and I always want to try different things.
b) I assumed that Tower Defense games would be very common submissions. Turns out they have not been, and now I’m wondering if I should have gone for the TD idea because I think it would have proven very fun and popular.
PINBOLOGY: An Overview
In addition to a more fast-paced, arcady game, I was also hoping to do something that had a very “physical” tone (this would give me a chance to really explore the physics engine in Unity 3d, something I have not done before). I decided to go very literal with the physicality and arcadiness and called up my love for classic pinball machines for my submission.
PINBOLOGY attempts to faithfully mimic the components, mechanics, and physics of old electro-mechanical pinball machines while incorporating zones, combos, and special actions themed around evolution. Fun gameplay would be top priority, along with a sense of real physicality. I wouldn’t have the opportunity to measure the actual physical response of different surfaces of a pinball table in 48 hours (different rubbers, plastics, wood, metals, glass, etc…), nor develop really good shaders, but I would do my best to create something that could possibly exist in the real world.
Five Things That Went Well
- Livestreaming: There is no better motivation to continue to work well past the point of tiredness/boredom/craziness than having up to 500 people watch you program. It does prove as a bit of a distraction at time, especially since I tried to narrate as much as possible and talk about why I was doing certain things and how I was doing them, but I still wouldn’t trade it for anything.
- Building Scenes in Unity 3d: I’m a programmer first and foremost, and I get turned on by things like randomly generated procedural content. That sort of thing is not appropriate for a pinball game, so instead I played to Unity’s strength: hand-placing objects. Since pinball tends to be extremely fussy about exactly where objects are, there was a CONSTANT need to tweak object placement, especially as new components were added in and the overall shape of the tabletop evolved.
- Building Objects in Blender: This was my first time doing a 3d game with anything more than basic primitives, and I wasn’t sure if I’d be able to figure out how to get everything working, but everything went really well! I feel that I pulled off some nice 1950′s components (bumpers, kickers, flippers) and somehow managed to make a complete mesh level that works well in the physics engine. I would have liked rounder curves and there’s one messed up set of vertices on the right-hand side that causes the texture/lighting to look a little wonky in that spot, but altogether I’m counting this as a win. That being said, while most of the objects were also quick to put together, the level geometry ate a LOT of time.
- Making What I Knew: As with writing a novel, programming a game that you already understand is a huge boon. I know what components make up pinball tables, I understand how objectives should flow together, and from start to finish I knew what how each feature would need to behave. I didn’t have to stop halfway through and re-evaluate my core gameplay mechanics. That being said…
- Learning Something New: I see LD as an excuse to try learn at least one new thing. You don’t want to overreach here, but this was my first time using Blender to create objects that I would then use in a game. This was my first time really using UV mapping and mesh collisions. This was also the most I’ve done with the Unity physics engine. This is significant, practical knowledge that I can draw on for the future.
Five Things That Went Badly
- Overspecialized Code: I failed to properly general the code for my components, so as a result I ended up writing very similar code many times. I should have planned things out a bit better so that I could have reused more of my scripts. Not only did this make debugging a pain, and reduce my ability to improve my scripts, it also substantially cut into my available time, which led to problem #2.
- My Schedule: I’ve always used the same schedule for LD’s, and it’s gone perfect in the past: Friday night is for coming up with the basic concept and doing a rough implementation to make sure it makes sense, with the idea that I can always restart Saturday morning if something proves unworkable. Saturday is when all major features get developed. Sunday is for polish, like replacing the placeholder art, adding sounds, main menu, GUI, etc… This time, I was still working on major features on Sunday — I was even added the rotating disc 45 minutes before the deadline! I had to do quite a bit of tweaking and tuning to the level mesh, and I had to rebuild the ramp three times to get the look, physics, and just general size and angle where I wanted it. This lead to problems #3 and #4.
- Artwork: My art is always going to suck, and I’m not going to freak out about that too much, but there are several things that I wanted to do and could have done which would have *dramatically* improved the game, but I ran out of time. A slightly better main menu, to establish the theme right away, would have been one thing. By far the biggest thing, though, would have been decals on the table surface to label various features. Real-world pinball machines have this for everything. “10,000 points”. “Ball Lock when Lit”. That sort of thing. Makes a huge difference for gameplay, but also theme. Decals would NOT have taken very long to do. Maybe an hour, tops. But time was that tight.
- Game Balance: This pinball machine is HARD. Many old-school machines are also this difficult (since they were designed to eat quarters), but this isn’t terribly appropriate for the competition. The Extra Life bar is set a little too high (partially because for a while there was a bug that gave away excessive bonus points). The DNA targets and Ball Lock area are rather hard to hit, partially due to the width of the table (because I wanted something “organic” looking and also to accomodate wide-screen monitors), and partially due to a last-minute change to the maximum angle of the flippers. The biggest problem with this isn’t that you run out of lives too quickly (you don’t have to feed it quarters to play again), but rather because it’s very difficult to execute the combos…and that’s where almost all of the theme lives.
- Theme Execution: Between the artwork deficiencies and the fact that a casual player may never unlock the “Survival of the Fittest” multi-ball, the Evolution theme is not obvious. To me, this is my largest failure because I’m actually extremely proud of all the “real” evolution references that exist in the game: Extinction events, geographical isolation, genes, etc… When you trigger a multi-ball, the color of the balls diverges from the parent — and the last one standing becomes your new species (i.e. its color is locked in as your ball color, at least until the next multi-ball). I think these things are GREAT…but they’ll only be seen by people who really know their way around a pinball table. You have to know how to trap balls, how to abuse various cycles, and how to tilt the table at just the right time. Otherwise? You just get a green pinball table and no real hint that the theme exists.
After LD, I always dream of developing my game further and turning it into a real, finished project. I don’t know if I actually have the time to do that, between my day job, my existing projects, my YouTube videos, and family time. But I would like to very much:
- Re-write the scripts that manage the component behaviours to be more generalized, so that components act more consistently and to make it easier to add more.
- Re-write the “toast” (notifications/achievements) system.
- Re-make the level mesh to be more polished, but also narrower (and therefore play a little easier).
- Add very nice shader effects.
- Add considerably more models.
- Add more tables with different themes.
- Add an in-game level editor and the ability to share and rate designs.
- Make a trillion dollars.
We’ll see how that goes.
In any case, I can’t wait for LD25!