Fresh blood! Notch told me to :creeper:
I’ve never done ANYTHING to this level before, so priority will be release ready code, graphics and such can come later if time permits. I’m probably going to take a few days to brush up on my C#/XNA to save precious time googling.
The plan right now:
Looking back at the clock, at the start I felt way ahead, by the middle I felt I was behind, and in the end I finished 3 some hours early. Not bad for my first attempt imo.
Next time I’ll challenge myself more, now that I have a much better feel for things and my work flow has improved. However I’ll need to practice on my music and art skills, as they’re severely lacking.
While the event had its stressful moments and sleep deprived coding sessions, it was quite fun, and I look forward for the next one.
I’ve spent a lot of time doing game development, but I almost never release stuff. Always base code, game logic, and abandon. So going in I had a bit of a fear of not finishing LD.
Looking at it now, I can safely say LD has been the single most educational thing I’ve done in my entire life as far as game development goes.
Its so easy to fall into the trap of scope creep, or to say “Oh, I can’t work on this yet! I don’t have graphics from the artist!”. But when time is tight and you ARE the artist, it’s easier to start looking at solutions instead of problems; and it’s that line of thinking that keeps you moving.
I’m really looking forward to the next LD. In the mean time, maybe I’ll actually finish some of my other projects for a change of pace.
Obligatory timelapse:
Participating in my second Ludum Dare! Woo.
Tools:
– FlatRedBall (C#/XNA) for le code
– GraphicsGale + Corel Painter for graphics
– sfxer for sound
– Unsure on audio. Been playing with AutoTracker-C and openMPT, so maybe that.
I learned a ton last time, and hopefully I can release an even better game now that I’m used to the pacing and a bit more familiar with the tools
Sitting here at the 24 hour mark, and things look to be way ahead of schedule.. which is odd.
What we have is a polarity shmup. Most of the vastly different ideas got canned due to balance issues, but I’m still tweaking it a bit. Currently later levels introduce blue ships which can’t be absorbed.
I got a bit ahead of schedule so I’m adding unplanned boss stages in now, which are turning out to be quite fun and very challenging. General polish should be easy to meet and some has already been started. I’ve been going at a fairly relaxed pace too. Overall its a nice change from last year, and makes it far more enjoyable when I’m not frantically looking up documentation every 30 seconds 
Going for my third LD entry. So far each one has been progressively easier as I get a better feel for the time constraints and workflow. I feel LD has become a bit of a benchmark on how I’ve grown as programmer. I love it.
The tool list hasn’t changed from last year much
Code: FlatRedBall (C#/XNA 4.0)
Sound effects: Sfxr
Art: GIMP / Corel Draw / GraphicsGale
Music: Audiotool
Target platform will be Windows again. I’m hoping this theme is a bit more focused, as the previous theme was basically a non-theme.
Also for anyone who enjoyed my previous entry, I may be porting it to Windows Phone 7 soon, followed by android.
After breezing through two previous LDs, I felt this time I should push my game design out a bit further, both technologically and in design. I wanted something that I knew would be challenging; not just a game I knew I could complete in the timeframe.
With this in mine, I added some goodies to my game such as an upgrade system, expansive map sets, multiple weapons, and complex enemy types. I looked at parts of games I loved and used them as foundations for various game mechanics. In the end I had a lot more than I could hope to achieve, so i had to trim some fat, and began coding.
At first progress felt a lot slower, dangerously slow compared to previous LDs. I was worried I wouldn’t make the deadline so I trimmed out multiple weapons, shortened the game a bit, and scrapped additional enemy types. I figured I could add these back in later as time allowed.
When I woke up on Sunday I was pretty unhappy with the game. The nature of projectiles made them frustrating when facing Banshees, which were the most common enemy type in the game. I tried nerfing the banshee’s move speed and changing the movement patterns, but nothing really helped. The game had content and was going well progress wise, but it wasn’t fun. I actually considered throwing in the towel here.
After about an hour of level design to take my mind of gameplay, I had a bit of an epiphany. Prior to LD I had been playing Quake 4, and started drawing connections to my gameplay flaw and my frustrations with Q4’s nailgun. Ultimately the machine gun worked better in Q4 due to not giving Strogg any time to dodge your attacks. While the AI in my game didn’t dodge, the movement patterns were hard to properly lead. So I changed the player’s gun to an instant fire laser.
Everything just clicked at once. Suddenly you could easily hit most targets with minimal issue if you lined up your targets well; and early game energy limits prevent you from just spamming down everything in a quarter of a second. Upgrades made you choose between various gameplay styles. The aiming mechanic of enemies made sure you couldn’t just camp one spot and shoot when everything lined up; but instead rewarded you moving WITH the banshee, constantly leading its shots but still keeping lined up.
After taking some time to balance upgrades and flesh out some levels, I was cutting it a bit close so I ran a final polish run on the level set (though I would have liked to expand it), and submitted.
In the end I have mixed feelings about the final result. The endings aren’t really “proper” endings, and there’s no menu/config/pause/etc. It feels incomplete to me. But despite having some spare time at the end where I could have mocked up some quick simple menus, I was sick of coding it when I submitted; and I felt that a rushed menu would be worse than no menu at all. On the other hand it’s a lot more than I could have done previously, so as a progress indicator it’s great. LD is never about winning to me, it’s about seeing what you can do. Testing your limits and learning new things. Seeing what you’re capable of…. And in that regard it’s been a roaring success.
Play/Rate: http://www.ludumdare.com/compo/ludum-dare-21/?action=rate&uid=3130
I’ll see you nerds in October :3
I’ve found more than one Love user now who uploaded nothing more than their game’s .Love file. Now technically this is fine, since it’s everything needed to run the game AND source! How convenient!
Unless you don’t have the Love game engine installed.
Now in a normal circumstance it might be reasonable to ask someone to install the engine to run your game. However, in the case of Ludum Dare, we have a mere 599 games to play, test, and rate. When I find games that require much more work than “click link and play” or “download, unzip and run”, I find it very tempting to just move on to the next entry.
The fantastic part is that there’s a very easy solution to this! As detailed here, you can easily build executable packages for windows, linux, and mac! These binaries will be easy for users to download and run without being burdened with installing whatever additional software you might have happened to use in your project, making it quick and painless to rate.
Note that this process falls under “Porting” which you can do at any time after the submission window! So go forth my minions and make your entries ready to run!
I’m in, probably, but I’m not going to be able to submit my usual level of terrible game. I’ll be interviewing in Washington Friday, which means WOO PLANE RIDE.
To be fair I could have picked any time when I was scheduling this, but I totally forgot LD was that week. I can only blame myself for this terrible predicament.
So with that in mind, I’ll likely be at the interview, or just getting back to my hotel when the theme is announced (Timezones, woo). Then I’ll be on a plane from 6am sat till 3:30 (Timezones, woo), so I’ll get back and likely pass out from jetlag, giving me the plane ride to sketch out a prototype (for as long as the battery on my laptop lasts) and whatever productivity I can squeeze out of my worn out husk of a sleep deprived body Saturday night/Sunday.
In keeping with tradition, I’ll be developing with:
I missed LD22 due to being out of state for an interview for an awesome job
Well, I got the awesome job and I’m happily situated now. Just got my rig rebuilt a couple of days ago so nothing but freshly installed software and shiny new hardware.
Same song and dance mostly:
I’ve got to sit down over the next few days and spend some quality time relearning FRB since a ton of awesome features and tools have been added.
While the rest of you are wiping the sweat off your brows and enjoying the afterglow, the countdown for the Jam is silently ticking away.
So, want a progress update? `Course you do.
So what do we have here? Well, long story short it’s a fully functional level. At this point the game is more or less feature complete. There are a few minor cosmetic bugs to work out (Lasers, please stop hating me), and a few mapping wishlist features I’m looking toward doing (Splitting outputs, counters, toggles, XORs, etc). At this point the last day can be spent mostly on level design and tweaks.
Menus are still missing in action, but we don’t need anything too complex so it’s more of a 5 minute code job than anything.
I finished, but I’m not happy with it. Lets call it a failed experiment.
To better illuminate this, lets rewind a bit.
My first Ludum Dare was LD19. I went in with a framework I barely knew and a set of balls made of pure steel. As someone who had spent a lot of time in the game dev world, I knew the thing I needed to succeed was a microscopic scope, so I did just that. I started with the very core of the game and worked outward. It all went very well. By sunday morning I was effectively done and had over 10 hours to polish and add features. The game shipped with all kinds of neat stat tracking features and generally felt very complete. It even had menus!
LD20 was more of the same. With a LD under my belt I went in with more confidence, but the same approach. The result was a similarly well polished Shmup with leaderboards and bosses. I focused on the elements that my LD19 entry failed at (mostly the sloppy controls) and again walked away very satisfied.
LD21 got a bit more ambitious. I went with an idea I initially wasn’t sure how to code. Google came to the rescue and End Of Line; my best rated/personal favorite game came to life.
LD22 was missed due to a job interview (I still tried, but couldn’t get power on the flight which was during the middle of the compo 
For LD23 I went for the jam. Knowing I had an extra day, I went fancy on a rotation mechanic that ended up being a complete nightmare to code. It went OK.
Totally missed LD24.
Which brings us to now: LD25. On previous LDs I’ve always been more or less feature complete at the halfway mark, so the second half is adding features and polish. I wanted to see this time if I could start with a much more complex idea to start with. Instead of taking the “start small, work up” approach, I wanted to try the “Start big, trim to size” angle.
The compo started at 6pm friday here. By 1am I was pretty sure I’d cocked up.
I had, at this point, coded the core idea. I had a spaceship that you could equip modules to, with energy/armor/shield systems. But I was beginning to realize how complex this was going to become. There were a lot more interactions going on that I’d originally anticipated, and it was looking to be a mess of code. However, Saturday was a long block of time, so I soldiered on.
I hammer through Saturday and before I know it it’s 3am and I’m still a LONG ways from even having victory conditions. At this point I know things have gone sour. It turns out slashing scope is a lot harder than adding to it. When your core gameplay relies on all these little features, you realize that cutting them gimps the gameplay rapidly. You’re left trying to pull weeds from a desert; there’s just nothing to remove.
Sunday. 7am. Alarm going off.
There’s a loud voice in my head screaming “turn off the alarm, go back to sleep, you’re not going to finish”. That voice is beautiful. It’s music.
But no. If I quit now I’d have wasted all this work. I begin to quietly wonder how many “5 hour energy” drinks is too many. According to the bottle: 2. Now you know.
I had one goal at this point: Finish. Any feature that hadn’t been at least partially implemented and wasn’t gameplay critical was cut. This sadly ended up really murdering the “fun” since the enemy spawn patterns and waves ended up getting gimped pretty hard. However, 2 minutes before the deadline, I’m literally hammering out the last bugs in the fitting window.
So here we are. It’s done.
However, the game itself isn’t important. It never is. LD isn’t about winning, it’s not about making the best game of them all, or even making a good one. It’s about learning; and I just got a fantastic lesson on scope. I picked up the idea knowing it would be a wonderful test of just what the limit is for a 48h compo; now I’m pretty sure I know. LD26 is right around the corner, then I’ll get to take a remedial course and see how much I’ve really learned.
tl;dr version: Start small, build up. Never the reverse!
So instead of an “I’m In” post, here’s an “I’m done” post. My toolchain changes a lot depending on what I make, so this is a much more practical way of listing what I actually used, vs vague plans.
As a note, this was my first LD where I didn’t use FlatRedBall. I’ve been doing more HTML5 stuff lately so I figured I’d just make the full dive. For the next LD I should work out some better solutions for audio and possibly write some base code to deal with a lot of grunt work I had to slog through for asset handling and preloading. Lesson learned I suppose!
Entry: Super Dash
Tools used:
Languages/Technologies:
Timelapse:
Another LD under the belt. First, here’s your obligatory timelapse:
This one was a bit interesting, in that I usually finish the majority of the game by the end of Saturday, and get the Sunday time span to polish and tune. However, this time it was very down to the wire (as evidenced by the lack of a menu, or really much of anything in the UI department)
A lot of this ties back to my early decision to leverage BulletML instead of writing my own bullet code. This was a sensible option by any measure, and I stand by the decision; the bullet patterns would have been much less interesting without it. However, I’d never used it before and this ate up a lot of time while I tried to figure out the best way to interface with it.
The second issue was a lack of a clear direction with the narrative. I pulled a magic trick out of the hat literally an hour from submission and got it done, but I was heading into Sunday with little more than a flimsy arcade game with no end.
This was also a bit interesting in that it was my third shmup. I know it’s not exactly original to keep using the same type of game, but I find it rather interesting to reflect on how my approach changes each time I do it.
I also hate my art slightly less than usual. This was a “half cheat” in that I used other pixel art as reference and as a palette sample, though I made sure not to ever steal from the original work of copy sections 1:1. If you look at the art you’ll realize it’s bad enough that that excuse is easy to back up~
On the other hand, the music is especially bad. I tried using a new program this time, but I didn’t know it well enough and ended up making no progress, which quickly lead to frustration and me hammering out the simplest thing I could without wasting any more time.
Overall I’m pretty happy with the result. I enjoy playing it, and there’s a “true ending” that probably nobody will find.
It's no secret that we've made more than a few narrative games for LD now. What's perhaps less apparent is HOW we make them, or more precisely: "How do you make narrative games with branching outcomes in 3 days and not go insane?"
Lets take a wonderful journey through the history of our narrative LD games. What worked, what didn't, and how I changed my approach each time.
The first stab I ever took at telling an actual narrative was waaaay back in LD34. There was an attempt with an earlier entry actually, but it's mostly been lost to time (and it was mostly just a last minute joke) so lets start here for the sake of cohesiveness. LD34 predates the new site, so a direct link to the entry can be found here.
In this entry, I originally just wanted a way to show the controls and some hints, but at the last minute I added a simple story to it.
Implementation wise, there's not a whole lot going on here. The levels are defined with a length in pixels, and at any given offset we can inject text into it.
In this example, there is a bit at the beginning of the level, and a bit more halfway through. The actual levels have predefined patterns, so the dialogue is placed at times where no ships are on grid, and we can pause the timer until the player clicks through the dialogue.
Next comes LD36. Once again, this predates the new site, so here's a link to that entry. This was my first Jam, complete with an actual artist, so I had a surprising amount of extra time, which I used to tell a more detailed story. For this most part, the technical approach was the same as the LD34 game, but since this game had lots of menus, there were more places to drip in additional pieces of narrative. For example, the shop:
Shop items all have little bits of background info in them, which helps build in world building. The shopkeeper also has a pool of dialogue he selects from on top of the usual "Welcome!". Nothing magic here, just a quick string array.
Which brings us to LD40.
With Lovely Kana, we were writing what was essentially a text adventure game, so there was a stronger need for dialogue variation and, more critically, a need for players to make choices. So I wrote this abomination:
No, the code hasn't rotted, it just really looked that bad for reasons. Anyway, this system essentially existed to build a condition based event pool. For each phase of the game, it would run through all of the possible events in a given group, then discard any that didn't meet the requirements given the current gamestate. From the remaining events, one was selected and run.
This works quite well at a glance, and it let us build a wide variety of events quickly. However, a lot of time was wasted building the tool itself, and it was difficult to visualize which events applied when. There was always the risk that changing a stat somewhere could create a "gap" where no events could match certain situations, or that an event would fire at the wrong time due to a typo. The tool itself also just kinda sucked; it's pretty hard to write a comfortable to use tool and the rest of your game inside the LD window, and I had to do both the code and the writing, so the actual tool was mostly just wasted effort.
Enter LD43
Silent whisper took what we learned from Lovely Kana, and doubled down on it, with a longer, darker, and more cohesive story. Rather than just being purely random events, the game was more a series of events and sacrifices you had to make to get to a finale.
The biggest change here was in how the writing was actually done. Rather than wasting time on a gui, the events were written in a giant XML file. In here, comments could be placed and events could be organized more logically. This didn't actually solve most of the problems from LD40, but did save a lot of time, as the time saved not writing a GUI could be invested into writing instead. The XML gave just as much insight as the old GUI, if not moreso, and could be more quickly updated to match changing requirements.
If there was a lesson from LD43, one might think it would be "Don't write GUIs". But what it really taught us was that the problems we faced with Kana weren't just one-offs. Even though I had more time to write, the script complexity issue was only amplified by it. It became this black box of data, impenetrable to even the one who wrote it. What would happen if I adjusted this number? no idea. Are there any bigs? probably. Can I find them? Only if I hit them during testing. Even then, the solution might just create another bug.
In retrospect. It's a miracle Silent Whisper worked at all. But I knew after that something had to change. And thus began my search for the Perfect Tool.
...which didn't exist. Sure, there are tools out there for writing dialogue in games, like Yarn Spinner and Twine, but none of them really did the things I wanted them to do. And so I wrote one.
Its debut was for LD45
With Zermatt: Zero, we had a goal in mind to push our narrative skills, and this new tool was going to be the way we did it. Calling back to retro visual novels, we had to deal with a lot of branching dialogue, game states, sequences, and other problems that would be extremely difficult to map out in text alone, so the solution was nodes.
This tool served its purpose well. Being able to more easily visualize the game flow through nodes made it much easier to quickly deduce state at any given time. Whole sections could be organized and discarded without worrying about breaking unrelated parts of the game, and even debugging was easy, since you could quickly jump through the story.
Another key aspect was finding the right balance between code and node. The goal here wasn't to re-invent blueprints; just to move high level game flow into a place it could be more conveniently visualized and edited. Essentially, nodes can do things like change what scene the game is in, set the CG, music, prompt the user for choices, and display dialogue. The game itself was responsible for actually responding to those events, and handling all the finer details of those interactions (like when to show movement controls, etc). There's always a cost to placing each node, so make it so only had to place as many as you needed to control the flow of the game. Busy work should always be moved to code.
This tool saw some incremental updated through subsequent LDs, with the addition of containers for better organizing, improvements to the UX, and adding additional features to it such as remote console and debugging features. But there were still problems. One of the biggest was simply that it was time consuming to place complex logic trees. Since each condition needed to be an explicit node, you would often have massive trees of conditionals that were just as hard to parse as their old XML counterparts.
Which leads us into LD50. This entry is an interesting jumping point since the general premise of it is similar to that of LD45, but with newer tools and more experience.
With latest iteration of our narrative tool, the biggest goal was down to improving readability and ease of use. Simple logic can be placed directly inside links (highlighting them yellow). Logical blocks can be surrounded with comments to quickly identify what they do. And the contents of each node has been moved to the inspector/side bar, instead of on the tree itself. This moves a ton of visual clutter out of the tree, and makes it much easier to rapidly identify what nodes are doing and where you bug may lie.
Further, since this new tool is integrated directly into our engine, nodes can interact more directly with our engine. For example, dialogue nodes pop up a live preview of the in-game interface at the current line, so you can adjust the expression, line length, and pacing without needing to run the scene in the actual game.
There were also some under the hood changes like moving away from JSON, towards a custom format that survived git merges better, and changing how the engine interacted with nodes such that we didn't need giant piles of macros to keep things type safe.
Are we at the perfect solution yet? probably not. LD50 has once again highlighted issues that need improved. For example, we need a way to visualize the how the game will execute through the various game states, as a common bug we hit during development was when none of the conditions were met, and the game just soft locked. But we already have a solution in mind, so it's just a matter of iterating and trying again next LD.
With each game we learn something new about our workflow, and find more ways to optimize it. As a benchmark of progress, between LD45 and LD50, our script grew over 3x in length, which implies I've either gotten way faster at typing, or the latest iteration of our tools have just enabled me to be that much more efficient.
Hopefully this look into how we write our games has sparked some ideas within you. I'm not about to assert my way is the best way, or even a good way, but it's certainly not the worst way we've done things, and hopefully it'll help you add something cool to your next LD entry.
Thanks!