Ludum Dare 37
Ludum Dare 36
Ludum Dare 35
Ludum Dare 34
Ludum Dare 33
Ludum Dare 32
Ludum Dare 31
Ludum Dare 30
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 Tutorials Award
Awarded by InfernoGames
on May 1, 2015
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
Might be Unity (if so, likely 2d).
It might be pure C# as a pure console application (roguelike? zorklike?).
Either way, the whole thing will be streamed at http://twitch.tv/quill18 as usual!
And of course I’ll be streaming the whole thing over at http://twitch.tv/quill18
Maybe this time will be the time I finally make a card game?
I’ll be streaming the whole thing over at http://twitch.tv/quill18 as always.
Unity, Photoshop, etc…
And this time, for realsies, I’ll be keeping it simple. Really. For real. Probably. Maybe.
For LD32, my entry featured considerably more sophisticated (though not necessarily better!) visuals and map generation than my usual entries. While I’m proud of the fact that I pushed my boundaries, it definitely meant that the gameplay suffered. In particular, many features that would have been fun and thematic had to be cut at the end.
This time, I want to end the compo feeling like I’ve created my most polished and “finished” entry yet. I want to do this by using minimalistic graphics (but with plenty of finesse, polish, and extra effects to make the simple graphics feel intentional and well-executed) as well as a focused set of core features. Basically, I’d like to make something that feels as cohesive and complete as my successful “Drill18” entry — though I’m certainly aiming for fewer features and less complexity, because that thing was a beast and I still have NO idea how I pulled it off.
I made a thing. It might be helpful for people.
Instantiating & Destroying large numbers of objects (bullets or large hordes of enemies) can sometimes cause a game to stutter during their creation or later during garbage collection. Object Pooling counters this by simply deactivating objects instead of destroying them, then re-activating them when you need a new copy.
All the pooling solutions for Unity I could find seemed overwrought and often required a bunch of advanced setup on a prefab-by-prefab basis. The solution I’ve come up with simply requires you to use SimplePool.Spawn() and SimplePool.Despawn() instead of Instantiate() and Destroy(). Pool sizes automatically grow to meet demand. There is an option to preload objects if you know you’re going to need to spam out a bunch of something very quickly (for example, projectiles for a bullet-hell shmup).
WARNING: NOT YET TESTED IN A FULL PRODUCTION APPLICATION.
I’ve never done an RPG for Ludum Dare before (also on the list: Driving game), so I really want to go in that direction if the theme supports it. I’ve been practicing my procedural dungeon map generation. As a bonus, this could also work really well for a Master of Orion style galaxy — instead of rooms, those could be stars connected by hyperspace routes.
Brown Blocks = Rooms
White Lines = Room connectivity graph, based on a relative neighborhood graph with a bit of minimum-spanning-tree work.
Green Blocks = Hallways based on connectivity graph.
Is there anything better than Ludum Dare weekend? No, of course not.
This will be my 11th compo and the 10th time using Unity along with the standard side tools (Blender, Photoshop, Audacity, etc…). I may make use of the CoreGameKit library from Dark Tonic and A* Pathfinding from Aron Granberg depending on what kind of game I decide to make.
I’ll be livestreaming the whole thing over at http://twitch.tv/quill18
I’m really hoping to make some kind of aRPG this time, because it’s one of the only genres I haven’t covered yet.
In preparation for Ludum Dare 31, I just put out two “quicky” videos demonstrating my simple controllers for 2d Platformer Characters and for 3d Vehicle Rigs in Unity. Full project download available. Totally free.
All project files for this (and many others!) are available here:
As usual, I’ll be livestreaming the whole thing over at http://twitch.tv/quill18!
I’ll be using Unity — though I’m not sure if it’ll be 2d or 3d. Depends on the theme, I guess!
I’m super excited to be participating in another Ludum Dare compo! This will mark the 9th time I participate in a row, and once again I will be livestreaming the whole thing — since to me that’s the best part about the weekend. I still don’t know why 10,000+ people think that watching someone program is a good way to spend the weekend, but I certainly appreciate the company.
My weapon of choice is Unity, Blender, Photoshop, and Audacity.
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?