Ludum Dare 27
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
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
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!
Pinbology is a retro-style pinball game where the zones, combos, and actions are themed around evolution. Originally I’d considered doing a Tower Defense game, but I thought that this would be far more unique.
Historically, pinball games have been themed with virtually every topic under the sun, from westerns to poker to movies — though I’m not sure if one has been made with “Evolution” before.
It was a challenge to create a physically accurate simulation of a 1950′s style electro-mechanical pinball machine while also conveying the spirit of the theme and doing some things that are only possible in a computer simulation.
I believe that my implementation of various pinball components (bumpers, kickers, spinners, drop targets, and rollovers) is relatively true to life, though unfortunately the lack of sample sound from a real cabinet blunts the authenticity. Additionally, it’s important to note that Pinbology works best with a fast computer, especially one with hardware-accelerated physics.
On the other hand, I was able to introduce elements that are impossible or impractical in the physical world, such as an organic “puddle” space to play in — a sort of platonic pool of primordial ooze where early life may have developed. Additionally, I wanted to introduce some over-the-top “toasts” when various events occurred, partially as a way to increase excitement and communicate the theme, but also because in many real pinball machines it’s not clear to the player what actions are activating various bonuses and enabling various combos.
Some of these are obvious, such as the camera shift when your “creature ball” enters geographical isolation, or the particles and lighting that emanates from the “breeding pool” (i.e. the ball lock mechanism that triggers the multi-ball). Some of these are more subtle: For example, when a “multi-ball” (a.k.a. “Survival of the Fittest”) is triggered, the color of the balls diverges from the “parent” ball, and the last ball to leave play is considered to be the dominant species and its color is used to spawn future balls.
My first goal in this, my 3rd competition, was to create a game that was first and foremost fun (especially considering the moodiness and over-ambition of my last two games). I really believe that I’ve accomplished this, but I also hope that I’ve also successfully expressed the theme — albeit in a unique and more indirect manner. I resisted the urge, both for time and also for the faithfulness to pinball, to add extreme “evolution” mechanics, such as changing the ball physics mechanics or transforming the paddles. These would not have been difficult to do (a mere tweaking of scaling, for example), but they didn’t feel appropriate for the game.
This game was made entirely before a livestream audience of 200-500 people. While I created all the art and program code myself, they provided invaluable moral support and inspiration, and I want to thank everyone who watched. I can’t wait for LD #25!!!
I haven’t done a proper “these are my tools” disclaimer yet, so here we go:
Unity 3d, Monodevelop, C#
Blender, possibly MakeHuman
Photoshop, GIMP (which is better for pixel art IMHO)
BFXR, Aviary, Audacity
A* Pathfinding addon for Unity 3d, if needed (but after LD22, I’m going to try to avoid this level of complexity)
XSplit for live streaming
Ruby on Rails + Heroku for a possible leaderboard + level creation server, depending on what I end up making
This weekend I spent 4-5 hours livestreaming a personal warm-up for Ludum Dare to make sure that my workflow in Unity 3d and Blender was ready to meet the challenge of another game jam. I may do another warm-up this upcoming weekend as well.
- My Unity knowledge seems up to snuff, even when it comes to doing new things that I haven’t explicitly done before.
- Even though I didn’t finish the game (which was never my intention during the warm-up), I created a LOT of content in about 4 hours. I’m working much, much faster than the last time I used Unity for Ludum Dare. Both because I’m more familiar with the tools, but also because I think I’m structuring my content better.
- I can whip out (very ugly) 3d models in Blender extremely quickly, which is good. Animating a convincing walk cycle is still probably out of line for a 48 hour competition, but I’m happy that I can have more than cubes and capsules this time.
- Focusing too much on the “theme” before deciding on the “gameplay”. It’s too easy for me to get overly focused on mechanics and simulation and to forget that I need a game in there.
- Not deciding on a single aesthetic first. None of my models really looked like each other — they weren’t even the same size. I need to keep this in mind a little sooner.
- Finding out that there’s no native IK support in Unity 3d, which is a real shame. I don’t have the experience to write an IK Solver in a 48 hour compo either. It would have opened up some interesting possibilities.
- I got really frustrated trying to sort out the “gameplay” issue and even snapped at the livestream chat, which is very much not okay. I was feeling overwhelmed by trying to read so much chat and filter ideas. Taking a 10 minute was all I needed to sort out my brain, get some inspiration, and be balanced and level-headed again. I need to schedule more breaks, especially early on when we’re still in the “idea” phase. Walks are good. (Also, it helped to turn off the mic/camera for a little while and just get “in the zone” with the programming for a bit, rather than try to entertain people.)
- Is it good, bad, or ugly to use a well-established gameplay mechanic (“tower defense”) and just try to adapt it to a theme? On the one hand, how many truly unique gameplay mechanics exist out there? Most things are just something that already exists (first-person, platformer, rts, 4x, side-scroller, etc…) with a twist. Trying to come up with something completely innovative is hard/impossible in general, and to come up with something spontaneously AND finding a good way to implement it in 48 hours is probably idiotic. Many of the best and most original LD submissions (and artistic/original indie games) ARE things like platformers with a twist. Braid, VVVVVV, and Super Meat Boy are — in many ways — basic platformers. And yet they stand out as completely unique at the same time.
I participated in the last two Ludum Dare competitions, and I’ll definitely be back for LD #24. This time, despite being very happy with my web-based multiplayer game created in Ruby on Rails, I’m going to head back to a more traditional game using Unity 3d. Can’t wait!
Read about my previous projects here: http://towerdive.com/ludum-dare/
It was a very non-standard decision to program my Ludum Dare as a Ruby on Rails web app, but the game I ended up with is incredibly feature-full and remarkably complete — which is not something you can often say after 48 hours!
Fish Tank Commander features:
- Multiplayer, turn-based tactics game (similar to Advance Wars…or chess!)
- Four exciting unit types: The Speedy Seahorse, the Tanky Turtle, the Brutal Betta, and the Cheap Goldfish.
- Elo ranking system (like in professional chess) and XP earning for each game. See how you rank! Challenge people of your skill level!
- Built-in map maker and a voting system
- Notification system lets you know when it’s your turn…or when your opponent concedes! (Coming soon after LD: Optional notification by email.)
- Sublime Text 2
- Photoshop and GIMP (turns out Photoshop sucks for pixel art)
- Twitter Bootstrap
- Git, Github, and Heroku
What Went Wrong:
- Discovering that none of my several available web servers were running Ruby 1.9+ and being unable to upgrade them. I ended up having to sign-up with Heroku to do the hosting, but this was indirectly good — see below.
- The AJAX interface for moving the units can be a little laggy. Unfortunately, there wasn’t enough time (and expertise) to develop a WebSocket solution — this will come after Ludum Dare is finished.
- Not enough time for me to play the game, so some good balance tweaks only became obvious to me after the deadline when I could get in a few matches.
- Not enough time to implement the several pages of additional features the game deserves! Especially automated matchmaking and email notifications. Hurry up and finish voting so I can improve the game!
- The battlefield doesn’t look quite as much like an aquarium as I had hoped. It needs some kind of border around it that looks like fish tank walls. One art please.
What Went Right:
- Really knowing my programming language. In LD #22 I used Unity 3d, which I’m not very experienced with. But I use Ruby on Rails every single day for work. This was still a learning experience as I don’t use RoR to make games, but it meant that I didn’t have to use documentation as extensively (just occasionally to check parameter ordering for complex functions).
- A great schedule. Just as with LD #22, my plan was to use Friday for ideas and a skeleton/outline of the app, Saturday for core gameplay, Sunday for “fluff” like finalizing the art and adding auxiliary features. Despite complaining about not having enough time to do everything, I actually did much, much more than I thought would be possible in 48 hours. I think that midway through Saturday I felt that I had enough “game” to have been satisfied with submitting then.
- Working with Heroku. I’ve been wanting to play with this sort of dynamic, cloud-like hosting for a while and I finally got the opportunity to do so. Even the the fact that I wasn’t able to use my existing (and therefore effectively “free”) hosting is going to be a boon, as I’m feeling more motivated to complete all the features I want to make a very professional product.
- Good, high quality food at the ready. I made a pork roast on Friday night and had plenty of pre-washed spinach, lettuce, and other vegetables ready to go. Saturday and Sunday morning started with a huge breakfast, and I made sure to consume a lot of high quality food the rest of the day. It kept my energy levels high.
- Going for walks. It only took me 10 minutes to go around the block, but the four or five walks I took throughout the weekend were great for recharging my batteries.
What Went Awesome:
- Streaming the whole thing and having hundreds of my YouTube viewers keep me motivated (and provide me with a to-do list of feature requests that will keep me busy for the next year).
Once voting for LD #23 is complete, I’m going to get back to work on this project and turn it into something really, really amazing. I can’t wait.
What I have so far in my Advance Wars inspired “War in a Fish Tank” web app game:
- Users can sign up
- Users can create their own maps!
- Basic combat system designed (but not implemented)
- 4 basic units programmed: Goldfish, Seahorse, Turtle, and Swordfish
It ain’t much to look at so far, but I’m loving my progress.
But now, time for bed!
EDIT: The repo! https://github.com/quill18/ld23-tiny-world
I already did my “I’m in” post, but hadn’t fully settled on the tools. I’m going to bite the bullet and commit to a heavily-server-side web app in order to force myself to make a different kind of game. Nothing real-time or arcady. It’s going to be a bit weird incorporating sound, but it’ll be an interesting learning experience.
jQuery, Bootstrap, and SoundManager 2
Photoshop and/or Paint.NET
BFXR, GarageBand, Audacity
Sublime Text 2, Git
Xsplit, TwitchTV, Premiere, Handbrake
I’m going to be spending a few hours livestreaming my warm-up for LD, so if you’re interested in watching drop by http://twitch.tv/quill18 and make sure to hit “Follow” to be alerted when I go live. I expect I’ll put in a bit of time tonight (around 7-9 EDT), plus a few more hours on Saturday and Sunday. Note: My channel is primarily for gaming and there will likely be a sizeable audience and a good chance that I’ll also be doing some Let’s Play.
I figure that the best way to do the warmup is to random from 1-100 and get a theme from the list at http://sos.gd/themes/?view=results — but since I don’t want to spend a full 48 hours I’m going to roll ahead of time so I have a chance to think a little before I dive in.
Roll Result = 46. Theme = “This is your dungeon”.
Interesting. I always love roguelikes and even old-school text adventures, so that gameplay screams out right away. But the “your” part of the phrase is making me think that maybe the player should have some ownership of the dungeon. Should I be looking to Dungeon Keeper for inspiration?
I have several hours to think before I can even start programming, so it’ll be interesting to see where my brain goes. (Programming Language: I want to do a web app with lots of server-side stuff in Ruby on Rails. Front-end will be HTML/JS.)
LD22 was my first go at Ludum Dare, and I had an indescribable amount of fun doing it (play my game, read the post mortem). A big part of why it was so amazing was because I livestreamed the whole thing, and a significant number of my YouTube subscribers turned out to watch (I believe I averaged 200-300 viewers the whole time). Many of the ideas for the story and gameplay came as a result of discussions with the viewers in real time.
It also felt stupendously good to finish a game, which I know a lot of other programmers can relate to. It gives me hope that maybe one day I’ll quit my job and turn to game development full-time. In the meantime, I have LD23 to look forward to!
Last time around, I made a game in Unity 3d. I’m a huge fan of this framework, though because it’s only a part-time hobby my actual expertise with this (or any game framework) is relatively limited. This limits my ability to perform as efficiently as possible and prevents me from dabbling with the more advanced features, but this isn’t necessarily a bad thing for a 48-hour compo. I may use it again, depending on the theme.
However, I’m wondering about doing something that is far more inline with my day-to-day expertise. It would be different from the “standard” submission, which carries both good and bad baggage. It’s also possible that I’ll be spending more time than I’d like with “low-level” functionality. Namely, I’m thinking of developing a game as a web app that would include considerable server-side functionality (as opposed to doing a JS/HTML5-canvas thing — though such features may make an appearance). Programming in Ruby on Rails is what I do every day — could this translate to making a game? There’s considerably latency implications, though this can be minimized depending on the type of game and through AJAX techniques (or web sockets, though this WOULD be new/unknown territory for me). Dungeon Crawl Web Tiles is a really impressive example of what’s possible. It also opens up certain multiplayer possibilities WITHOUT needing to muck around with the more complex issues involved in typical multiplayer games.
I may make a test/practice/warmup game to experiment with these techniques, though April is looking VERY busy right now and I’m not sure when I’ll find time.
Developers often do a “Post-Mortem” after completing a project, exploring the things that went right and wrong. This helps them keep track of what they’ve learned and also help other people who are going to try the same thing.
What went right
“Alone” is really a mood theme, rather than a mechanics one, and that had me a bit stumped at first. All the neat “physics” and “sim” ideas I had in my head needed to be thrown out. The gameplay was to be a slave to the story, which is pretty much the inverse of how I usually think.
Right from the beginning, I had toyed with the idea that the protagonist is not literally alone — just that he feels alone. Paper Town takes that the next level and places the player in the mind of someone who is psychologically damaged and is living in a world where he perceives himself to be alone and can’t recognize the presence of people around him who are trying to help.
I believe it’s an idea that can resonate with a lot of people. You may feel lonely, but at the same time you pull away from other people and avoid talking to strangers. This explores the extreme outcome of that: The character will in one line of dialog lament the fact that everyone has left him, but in another line of dialog scream “LEAVE ME ALONE” to the nebulous entities that sometimes appear.
It’s through the development of the story via note pickups that the character finally gets a chance to recognize that his solitary universe is self-inflicted and that he can break out of it through a true desire to be with other people.
For a lot of people, the spirit of Ludum Dare is to build everything from scratch — or as much as is possible without implementing your own programming language and basic library of functions. However, I very much wanted to build a complete game and starting with a fully functional gaming engine went a long way towards ensuring that. Being able to drop in primitives and start programming behaviour 5 minutes after deciding on an outline for my game was incredible. Not having to worry about how to load images and sound, nor do physics, was likewise amazing. Also, having access to some great pathfinding middleware was also exceptionally helpful, though it brought its own problems (see below).
On the other hand, since my challenge wouldn’t be about the base engine, it means that I had to make certain that my execution of the theme was top notch. I wanted to tell a complete story, and I wanted to make sure that there was a way to win and to lose the game. I think it takes about 10 minutes to win.
I didn’t have the time or the ability to do any 3d modelling, but I did as much as I could using pure primitives (cubes, planes, spheres, and capsules). I’m also pretty keen on my moody lighting effects.
While there are certainly things I would have liked to have gotten done if I had more time, I actually didn’t feel very rushed during the 48 hours, and I think a lot of it had to do with having a solid time plan right from the beginning.
The theme announcement and start of the competition was at 9:00 PM my time on a Friday, so that evening was all about coming up with the idea for the gameplay and story, and to setup the initial environment in Unity (terrain, character, a simple building, and the ability for the player to click/pathfind around the obstacle).
Saturday was planned to be “gameplay” day. I generally didn’t worry about the actual looks/art. The game just had to be playable, and by the end of the day all the major gameplay features were present:
- Randomly generated city, including 4 types of buildings, streets with intersections, lightposts with actual lights
- Enemies that would spawn, patrol around, and chase the player if they saw him — dealing damage if they got close.
- Pickups for the player, which would be stored in inventory
- The ability to create a “paper doll” with the right items. A “paper doll” is a turret that shoot bullets at enemies.
Sunday was planned to be “story development”. I know it may seem weird to play on having 50% of your time to do all the “real” features and 50% of the time to do “fluff” and polish, but in practice the big features don’t take that much time. They’re often far more straightforward and easier to understand. It’s the fine-tuning that can be really time-consuming, but it’s also the thing that truly sells your product in the end.
I think my final story is a bit cliche and maudlin, but still works to really sell the theme. This time allocation meant that I was also comfortable spending time making sounds and intro/end screens, which I think are an important part of the “complete” package but often get overlooked in the face of adding more gameplay features.
Things I did on the final day:
- Redid city generation (it was crap and the road/fence were very crap)
- A dialog system, allowing the story to be told during gameplay (and also to explain gameplay mechanics as they come up)
- Added a new pickup type: Notes. These are used for the victory condition and also trigger lots of dialog.
- Changed player to WSAD/Mouse movement
- Fiddled with the pathfinding multiple times
- Rebalanced the enemies and pickups multiple times
- Added a day/night cycle, which looks good and controls enemy spawning
- Intro screen!
- Win and loss screens!
- Sound effects!
Food and Drinks
Lots of good, satisfying food at my disposal. No junk food, and nothing that would leave me with messy fingers. Also, everything could be prepared in just a few minutes, minimizing downtime.
- Bacon and Eggs
- Avocado with Sriracha hot sauce (sooooo goood)
- Tuna salad
- Leftover ground beef/veggie casserole
Note that these are low-carb, high fat foods that fit into my Keto diet. If someone on a standard diet ate like this for 48 hours, they’d probably feel a bit foggy-headed, which wouldn’t be ideal for the competition.
This was by far the single best choice I made with regards to Ludum Dare. Having hundreds of people watching me all weekend kept me motivated and entertained and provided me with a veritable army of beta-testers! I had to create all the game code and content myself, but having people provide immediate feedback was invaluable.
Many Ludum Dare games don’t have any sound, or at best just include a few bloops and bleeps generated with a tool like BFXR – which was absolutely my plan too. However, in practice I really wasn’t happy with these sounds. I felt like their arcadiness took away from the mood of the game, and I’d just about given up on the sound (which was already an Final Hour job)…but my stream viewers made a case for the importance of sound and music. And I’m happy they did!
So I went to Plan B for sound, which was simply to use my microphone. Sound effects for item pickups came from flipping pages in a book (Python & XML in a Nutshell), and music came from something I’ve never done before: Me playing an instrument in front of an audience. I played a few bars of some badly off-tempo blues scale on my harmonica and then slowed down the recording (which also lowered the pitch). The result is a haunting soundtrack (with two songs) that – while far from good – is way better than no sound at all.
What went wrong
One of the resources that was in my toolbox even before the theme was announced was the great A* Pathfinding middleware by Aron Granberg. It’s a very simple drop-in solution that makes it pretty easy to add basic pathfinding to a project. I like to use it by attaching an empty “pathfinding target” gameobject to my units and just moving that target around to make things happen.
Unfortunately, I ran into some limitations with the default way of using the middleware that caused to pretty serious problems and almost wrecked my whole idea. I wanted a fairly large city for the player to explore, but the combination of a large area with the need for a fairly fine pathfinding grid (to be able to maneuver around furniture around buildings) meant that we were generating far too many nodes and Unity would crash. After some fiddling, I was able to find a compromise between city size (3×3 blocks with 2×3 buildings each, for a total of 54 buildings) and grid resolution. At that point, things seemed to work pretty well until I started balancing the game.
It quickly became apparent that I needed quite a few enemies to appropriately populate my relatively large city space, but as I increased the number of units my pathfinding system started to lag. Luckily it’s pretty intelligently designed, so the actual game performance was unhindered, but the pathfinding request queue was taking longer and longer to get through. This wasn’t necessarily a problem for the AI, since it’s not the end of the world if it takes them half a second to change to a new path in response to stimulus (it just makes them a tad easier to juke).
For the player’s mouse-controls, however, it was a big problem.
One of the first things I added to the game was a click-to-move functionality. Reasons for this were varied, but a big part of it was a drive for simplicity. I wanted a game that was utterly intuitive for anyone to play.
My initial approach was to do a raycast from the screen to the ground when the mouse was clicked, which worked great. Unfortunately, Unity doesn’t provide a simple way to eat mouseclicks when the player hits the GUI, so interacting with it meant the player was moving unintentionally.
The second approach was to have the ground react to OnMouseClick events, which worked just as well but wouldn’t be triggered when the user was clicking on the UI. Unfortunately, it also does not trigger if the user is clicking on another model, including my road segments and building floors, so I had to ensure that my “HandleMouseClick” behaviour existed on all relevant objects, including pickups. This worked okay. Until I ran into my pathfinding issues.
During the day, everything was pretty good (minus a little funniness due to the pathfinding grid resolution), but at night when enemies showed up, there was a noticeable delay when clicking due to the pathfinding queue being pretty full.
In the end, I gave up on mouse controls and switched to WASD/Arrow controls, leaving the player feeling very responsive.
I’d decided pretty early on to make the building outer walls quite low, that way the player could easily click on the ground inside and also not worry about the player being hidden behind a wall (due to my fixed camera angle). This lead to me having to fiddle a bit with my line-of-sight tests with enemies, because they shouldn’t see the player through a wall. I had to make sure that my raycast was low enough to be blocked by the short walls, but high enough to not get screwed up by the lip around the road or the strange mesh deformity on the player’s capsule model. It ended up being kind of fiddly.
It would have been nice to put an invisible wall around the buildings and have them block enemy LOS rays, but between the UI, the “shade” block inside the buildings, and the invisible walls I couldn’t figure out a way to allow mouse-click raycasts to get through while blocking enemy raycasts.
Of course, that was all moot by my switch to WASD/Arrow movement, but that change happened way too late in development to save me any trouble with the enemies.
Randomly generated content
This always SOUNDS so cool, but for a game like this I’m not sure it does anything for the gameplay, nor am I sure that it saved me any time. Yes, placing individual buildings would have been a pain, but I spent so long having to tweak the system so that the buildings and roads all ended up in the correct location that I think it took longer than doing it manually would have. And it’s still not perfect! There’s slightly more space on one side of the blocks than on the other.
Even things like Pickup spawns were totally random at first, but sometimes pickups would land on top of objects and be inaccessible to the player. Ultimately, I placed empty gameobjects to act as spawn points and that worked so much better (I also did this with enemies).
So if I *did* want randomized buildings, without having to worry about getting my placement math right, I should have manually positioned building placeholders and just have them be populated at program start.
Note that I had intended to make my city bigger (which is why I felt that random generation was the way to go), but I had to scale down my plans due to pathfinding contraints. I do think my final city is a good size for the actual game.
The idea that the protagonist has devolved to making paper dolls in order to combat his loneliness came about very early and was meant to be a major part of the gameplay, adding in a “tower defense” component. However, this never came to be and as a result the act of creating the paper dolls and their use in gameplay is rather secondary. It’s still better than not having them at all (and having the game just be about exploration and hiding), but I think more could have been done with them.
To a certain extent, the weakness of the doll theme is a result of the time limitations with regards to creating more enemy types and behaviours and just general game balance. I also think that the dolls are dependent on a certain amount of art development — I think they deserve a cutscene for their creation, to add real emotional depth.
Another contributing factor to not further developing the paper dolls idea was the conflict between static, unmoving, tower-defensive gameplay and the need to explore to find notes to advance the story (and win the game). Making the dolls secondary (and have very limited ammo) turned them into something that was just a tool to help you survive a bit longer and facilitate your exploration (and thus completion of the story).
I consider this project to have been a HUGE SUCCESS! I program all the time, but usually I’m making business-oriented web applications. I have started many games, but I’ve never finished one before. Paper Town may be rough, but it is a complete game and that makes me extremely happy.
Also, even if the game hadn’t worked out, we still had a stream that averaged 100 people for an entire weekend. That’s amazing!
I absolutely hope that I can participate in the next Ludum Dare, but I also hope that I can find more time to make games in general.