This is my first LD (and first post, so I’m told an “I’m in” is appropriate). These past few months I’ve been doing a lot of porting with the ENIGMA game engine, so I’ll be using that for my submission. I’ll link to my Github fork, which has minor code fixes:

https://github.com/sorlok/enigma-dev

Graphics will mostly likely be done in the GIMP, and I’m still playing around with options for sound.

Good luck to everyone! Looking forward to this!

I was not originally going to blog, but as this is my first Ludum Dare, I didn’t realize how many “tiny pockets” of down time there are. For example, I am waiting for a cup of tea to brew, which is not enough time to start something substantial, but is just enough time for a quick update. After working through the night, I have most of the SFX and music generated, and have some basic interactions. ENIGMA was a good choice; it keeps me from having to organize resources myself, and handles a lot of cruft code for me so I can focus on design issues (and bad art!)

Good luck to everyone! I can’t wait to play all your games, but for now it’s back to work for me!

Sneak preview!

I’ve found that the limiting factor for me is not, surprisingly, time. Rather, it’s focus. The mistakes start to pile up, and the desire to perfect the details that need perfecting diminishes. Fortunately, I am still on track for finishing! But the next time I do this, I probably won’t shave as much time from my sleep budget.

Good luck to all in the last half day! Here’s a brief preview of how things are shaping up for me:

Just a quick update; my LD31 entry, “Sad Little War-Bot”, is now up for Windows, Linux, and OS-X!

http://ludumdare.com/compo/ludum-dare-31/?action=preview&uid=28370

One of the great things about using ENIGMA is that porting was a breeze; the Windows port took literally 20 minutes. The OS-X port took a few hours, due to a bug with mouse positioning. I’ll be pushing a patch upstream for this.

Below is a screenshot, but for now I am super-excited to get started on all of your games!

Playing these games is tons of fun! Here are some I enjoyed so far:

Network Programming – Oh man, the audio on this one is not to miss. You’re trying to reclaim your soul from within a series of TV channels, by doing minigames while some hilarious background audio plays.

Escape Character & OMNI – There were a few “trapped in a computer” games, and these were the best. Escape Character is really on top of its look and feel, while OMNI is really clever about moving the screen (but a little tough to control).

Squishi – There were also a few “rebuild the screen” games, and this one does it best, I think. It also ramps up the difficulty slowly, which is a nice change from lots of the platformers.

Hit and Slide – A networked brawl? Count me in! Has a few mechanics issues, but I found myself playing a lot more of this game than I needed to just to write the review. It’s just fun!

Owls Ever After – Explore your memories and find inconsistencies to get around the fuzzy areas in your past. Also has a really great visual style.

Microphyla – Very Metroid-y. Solid mechanics, lots of fun, very well designed.

Shifting Dungeon – A dungeon exploration game where the dungeon scrolls and shifts around you. Another great take on the theme.

Photo Bound – Took me longer than normal to “get it”, but the concept is solid and pretty clever. Nice visuals, and decent controls.

I’ve been really impressed by the creativity and technical prowess of many of the entries. Really cool games, guys and gals! Keep it up!

Hello everyone! I wrote Sad Little War-Bot for Ludum Dare 31, and now I would like to talk about the process of creating the game. This is an exercise in reflection, and I hope my good decisions and foolish mistakes can be useful for other developers to know about as well.

I really, really, really love games. I love playing them, I love talking about them, and I love designing them (on paper). Going into the Ludum Dare, I mostly wanted to just stop making excuses and start making games. My “stretch goal”, if you will, was to make something people could enjoy, that expressed some story or emotion that they would find worthwhile.

Pre-Compo Decisions

Despite being good in general-purpose languages (C++, Python), my past attempts to write a game were all eventually shelved. Recently, though, I’d had a lot of success porting games. I recently ported both Iji and An Untitled Story to Linux and OS-X, using the open source game engine ENIGMA. Even though Unity is more industry-standard, C++ is more hardcore, and Haxe is more interesting, I figured “Well, I want to make a game, and I know ENIGMA, so I should probably use that!” And this decisions is the only reason I completed my game.

Themes and Angst

Let’s talk themes! I was not a big fan of the theme when it was announced, because it was second-to-last on my list of pre-compo theme ideas. Some items higher on that list, for reference:

• Artificial Life, Machines  — I had this idea of a world without humans, where “AI” (advanced robots) look down on “Machines” (human-created robots) because they were only programmed to mimic awareness, while the AIs were actually self-aware. I figured our hero would be a machine who goes on a quest to construct an awareness module.
• Chaos — I had this idea of a shooter where you could only fire grenades, and enemies would chain-explode.
• ☃ — Based on the games I’ve seen so far, everyone kind of expected this to be the theme, and had some clever snowman-related game up their sleeves. I did too, and it’s a secret! But it involved a snowman boss jumping around an arena.

In the end, I punted on the theme, and just weaved together the three themes listed above to create Sad Little War-Bot. I guess the theme actually helped me, though, as it kept the scope of my game in control.

Time Breakdown

Here’s a timeline of development, compiled from my time-lapse video. There’s also a total breakdown of time spent.

Total Time Spent (top) and Full 48-hour Timeline (bottom)

I took a lot of small breaks, because maybe I’m getting too old to pull double all-nighters without losing my focus. 😀

Tools

Pretty standard stuff:

• Audio: sfxr and Abundant Music for generating, Audacity for editing. Liked Otomata, didn’t end up using it.
• Graphics: GIMP for most things,  Explogen for explosions.
• Game Engine: ENIGMA

Early Design Evolution

Because I was upset at the theme decision, I spent the first hour generating audio. I also imported some fonts, and did some basic game engine setup tasks (plugin selection, etc.). After that, I had my first design chat, and decided to make what is basically a top-down arena shooter. I knew early on that I wanted to integrate the “chaos” theme, because escalating object interactions are pretty easy to do in ENIGMA. At this point, I had the idea: “you are a spy working as a baker who is uncovered by a spy working as a toy maker. Both of you have explosive tools related to your cover jobs”. No robots yet!

Our Hero

I started implementing the basic mechanics. I actually had a really hard time implementing collision detection, so it’s a good thing I didn’t decide to make a Zelda-esque game! Instead, I “faked it” (that’s a term the pros use) and then immediately cut from the game anything that relied on precise collision detection and movement. I then moved on to implementing the first weapon (the grenade launcher) and the first enemy (the toy ducks). I originally envisioned multiple weapon and enemy types; the latter actually happened, while the former was cut.

You get the idea…

At this point, I was really unhappy with my game at a fundamental level. It felt too much like an excuse plot to remake Hyper Princess Pitch. Call it artistic integrity or plain old stubbornness, but I didn’t want to even submit the game if I wasn’t proud of it. So, I reviewed my list of pre-compo ideas, and decided to tell my Machines vs. AIs story, but with a twist: you’d control a robot designed for war that was to be decommissioned, and your only means of defense was an over-the-top grenade launcher. I was significantly happier with this idea, and it also let me shake up the enemy types a bit. I figured the AIs could be using merchandise from various mall shops to attack you in the courtyard. Thus, a toy shop, a gardening shop, and another shop –at the time, I figured some kind of hardware shop that had tiny robots (this eventually became the comic book store). I had the idea that if you killed enemies (rather than, say, them killing themselves with explosions) then you would get a star, and that the north wall of the room would contain vending machines that you could buy health from with stars. I also wanted it to be possible for you to complete the entire game without killing anyone yourself, and that would change the ending. I didn’t have time for the latter, and I removed the vending machines (in favor of the “beam of death”) for another reason, explained in the next section.

Game Design Is Hard!

I am in no way a game design expert, but I try to be diligent. To that end, I’ve been watching Extra Creditz, which I would wholly recommend to anyone looking to design games. Every episode, they talk about how design decisions impact the player in potentially unexpected ways.

So why didn’t I make multiple weapon types? Simple: it gave the player too much choice. I put myself in the shoes of someone playing my game: I would be lucky if they gave me 5 solid minutes of attention (hey, there’s 4,000 games in my LD31 queue!). More weapons meant more controls (e.g., a “switch weapon” button, or a “buy” button for the vending machines), which meant ~1 minute spent learning mundane details. More weapons also meant more potential play-styles, some necessarily better than others. That meant the player could waste ~1 minute playing through a level in a sub-optimal (i.e., “not fun”) play-style. So that’s 2 out of 5 minutes wasted! Instead, I added variety another way, using an idea I borrowed from Super Meat Boy: don’t vary the player, vary the environment (enemy count and lineup, in my case). I think the key here is that I made the right decision for my game at its current level of scope: if I added 100 more levels, I’d probably re-examine weapon customization.

Georgi used to have a mustache.

The inter-level cut-scenes were another time sink, but I was 100% determined to get them in there. If you’ve played the game, you probably agree: they allow me a few quick lines between each level to establish the motivations of Georgi and Dash, as well as the story of the game world itself. I also wanted a “break” between levels (but I didn’t want a pause button, since it ran counter to the chaos theme) and I wanted to give players something to look forward to after each level. I’m not a writer, but I think I was able to get people to chuckle while still drawing them into the world. Establishing Dash as the antagonist (but not a villain!) was my goal, and it was challenging!

Start! Go!

As for the complicated “zoom in” level intro, part of that was me just wanting to make something fluid and engaging. But it also served a purpose: it gave a consistent pattern to each level, rather than just dumping the player into the action. This was most important for the first level, but it also built anticipation for the final level (since it seemed that “9” would fit but “10” would not) and then the final boss (the “Oh my goodness, is he actually bringing in the snowman as a boss????” moment). And, it helped you track your progress, like slide numbers on a presentation.

The decision to make grenades explode if they hit other explosions was intentional. It had to do with another decision. One of the design chats brought up the idea of either a cooldown or a limited set of ammunition. This is pretty standard in shooter design, but I was strongly against it. Again, taking the perspective of the player, ammo caps and cooldowns just aren’t fun! In, say, a survival horror game, they serve another purpose, but my game was just a fun, spammy shoot-em-up. At the same time, I didn’t want to make the gameplay too reliant on button mashing. So, I built in this mechanic where your explosions could trigger your own grenades, adding a natural feedback loop that encouraged players to exercise self-control. In the end, some people hated it and some people loved it.

The beam prevents you from shooting the cactus.

Let’s talk about cactuses. The insane malefic nature of them served a purpose. In fact, each cardinal direction of the room had a distinct feel to its spawns. In order of creation:

• East — Mostly harmless. No contact damage; no intentional action against the player. I tended to put them on the top and bottom of the screen in long lines, to encourage players to stay towards the middle.
• South — Overwhelming but avoidable damage. Takes a long time to build up, then does massive damage. (I got the circle idea from Hammerwatch.)
• West — Intelligent, focused and deadly. These guys track you, and they can’t accidentally kill each other.
• North — Pattern-based damage. Easy to exploit, but they block your grenades, so North+West is especially dangerous (level 9).

The “hard mode” is the original mode of the game. I was worried people would be frustrated at dying and wouldn’t complete the game, so I made “easy mode” where every hit deals 1 damage. I still included “hard mode”, because I didn’t want to spoon feed the hardcore gamers who could take the difficulty spike. To unlock hard-mode, just start the game once and quit. The next time, at the title screen, press H for hard.

I specifically made a “cute” enemy the first thing the player sees, so that the player can empathize with Georgi’s intent to avoid harming things, if possible.

I originally planned for 20 levels, but I wanted it to be obvious when you were approaching the last level. Then I planned for 16, because the robot uses hexadecimal and everyone knows that right? (I think I was sleep deprived and delusional at this point.) Then I settled on 9, because only a single digit fit in the level intro scene. (Then I added the snowman boss and custom levels.)

When I was younger, I used to chain-play RPG Maker 2000 games. I just loved how so many people expressed themselves through game design. One thing that I hated from that era was the samey feel that you get when using a game engine. So I tried really hard to add tiny customizations when I could. The neon “Toys” signs, the flashy level intro zoom, the spinning crosshairs, and the overuse of particles were all under this category.

Intuitive!

The dots that “trace” to your crosshairs were an early design, and intentional. I first had the crosshairs follow the mouse, but found that it pulled the action too far away from Georgi. So then I bounded it to a circle around Georgi, but it was hard to see sometimes with all the explosions. So I added the dots and animated a path to the crosshairs. This really made it clear that the grenades were your primary means of interacting with the world. Many other games have done this kind of thing.

Ow! Ow! Ow!

I made the damage a “string of numbers” pouring out of Georgi to give the player some idea on how bad the situation was without requiring him or her to look at the health bar, way at the top of the screen. I also played a jarring noise, to try to make it clear “this is bad, step away from the (cactus|duck|laser).”

Final Thoughts

I am extremely proud of the game I made: I was able to finish on time, and it expressed to the people who played it exactly what I wanted to express. Reading the comments, I am overwhelmed by the positive feedback, and I’m so glad that I could make something that people enjoyed playing. And thanks for your constructive comments; you all had some good suggestions for improvement.

In terms of the Ludum Dare, I feel like I budgeted my time well, and was always aware of my limitations. I think I did the best that I could given my current skill set. I will definitely enter the Ludum Dare again. I’d like to focus on tighter mechanics next time, as well as more mood-oriented environments.

Overall, this was a very positive experience for me.

Goofs, References, and Pure Luck

That’s it for the main post, thanks for reading this far. Here’s some random trivia:

• The cacti are named after a character in Wandering Hamster, “The Mad Cacti”, which is also one of the OHRRPGCE’s developers.
• “Start! Go!” is from Minecraft Bingo. I’m a big Lorgon111 fan.
• I listened to OC Remixes, the Radiant Historia soundtrack, and the Bravely Default soundtracks while working on this game.
• I wrote a string parser for each level, so that I could write, say, “W5:S2D:”, which translates internally to “wait 5 ticks and then spawn 2 ducks”. I did this entirely to speed up level development, but when describing it during a design chat, someone thought I was talking about a level editor. Then I thought “huh, I could just read this from a file and allow custom levels”. And voila! Custom levels almost didn’t make it in, because the game would crash upon loading them unless you built in Debug mode. So… I built in Debug mode. But it was down to the wire.
• I totally lucked out with the OS-X port; ENIGMA can be a bit flaky across different platforms, but it only had a tiny bug on OS-X. I actually did all the development on Linux, so for both Windows and OS-X my thoughts were “well, maybe it’ll work”. Props to the ENIGMA developers: it worked just fine!
• I had a hard time coming up with the design for Dash (the AI). At some point, someone suggested that Georgi looked like Wall-E, which then motivated Dash’s sleek design (based on EVE, of course).
• I accidentally deleted the “screenshot” program at 2am on the first day. So my time-lapse, naturally, blips out at that point for an hour or so.
• I took a ton of small breaks, and this helped me stay sane. Where possible, I had design discussions with various friends so that a break wasn’t entirely wasted. I also lost 2 hours going for a long walk and grabbing dinner, and 1.5 hours with an unplanned nap. I think I had a mini burnout in the middle of the compo.
• I always tried to keep Georgi and Dash gender-less, but I sometimes slip up and call Georgi “he” and Dash “she”. But canonically, their genders are up for interpretation.
• I only crashed the game engine once.
• During one of my meals, I watched an HCBailly Let’s Play episode.

I’m in for Ludum Dare 32! I’ve been brushing up on my ENIGMA for this compo, and am really looking forward to it!

In the mean time, why not try out my LD31 game? 😀

http://ludumdare.com/compo/ludum-dare-31/?action=preview&uid=28370

The LD32 was my second Ludum Dare, and I wanted to make an RPG. The post-mortem will come later, but the short version of the story is that I succeeded —but the game was crippled by two show-stopping bugs:

1. Collisions with objects in battle could hang the system (especially rocks).
2. The first miniboss was a surprise battle that could easily kill you.
3. Bonus! Enemy turns took far too long in battle.

To my dismay, the game I worked so hard on had a mixed reception. People generally liked it, but they (very understandably!) were frustrated by these glitches and imbalances.

With that in mind, I decided to release a post-compo version with a few tweaks here and there to address these issues. Since I only had 1 free link, I listed the Post/Pre compo for Windows (which is by far my largest download count). The page description has all 3 versions. All versions are available from the entry page, and all are clearly marked.

If you’ve already played the game and are curious about the story, a full gameplay video is shown above.

In for my third Ludum Dare! This time, I’m mixing up the tool set:

• RPG Maker VX for game engine
• Not entering Graphics/Audio categories.

That’s right, I’m doing the Jam! This is a big experiment; I want to focus 100% on design and storytelling this time. Will it work? Will it crash and burn? Find out… next (next) week on: Tales from the Ludum Dare, Episode 33: Attack of the Killer Game Engine!

Edit: I’ve been playing around with the idea of randomly generating dungeons. Since I’m doing the Jam, I thought I’d write the generator and integration code (bleh! boring!) early, and focus entirely on balance, story, and mood (yay! fun!) during the actual Jam. Code is here.

Greetings! I hope by now you have all had the pleasure (or misfortune) to play my LD33 entry: “Trump 3016“. The game stars Donald David Trump as he strives to reach Saturn in time after losing the Pluto debate to the cyborg-enhanced Hillary…. you know what, let’s try this again:

It’s a Trump-themed RPG Roguelike! (Dare I say… the only Trump-themed RPG Roguelike!)

The Good

• I started with a simple Ruby script I had written to generate random dungeons. This was a helpful jump-start (which relegated me to the Jam, but that’s fine).
• I really love the feel of exploring the random floors. This is what I’m most proud of.
• Comments from my last 2 entries indicated people liked my humor and storytelling best (graphics and audio least). So I focused on that.
• There is an absolute abundance of Trump out there. The story basically wrote itself.

The Bad

• The battle system is woefully unbalanced. The game is unplayable past level 10.
• I didn’t count on having pacing issues; 72 hours is a lot harder than 48! Props to all you Jammers.
• RPG Maker has its own host of problems. I totally understand if you are allergic to RTP (but at least watch the intro!)

The Ugly

• I lost a lot of time tracking down assets. It’s easier when I can just draw something (terrible) and be done with it.
• This game might become a whole lot less funny in 2016. Sorry in advance!

Some other cool things about the game:

• If you talk to the suited NPC near the doors, you can get a “Fabric of Reality” early  —this lets you enter the random seed for the next level, which will consistently generate the same level each time. Try entering your name, or any random information. Maybe you’ll spawn a cool layout.
• It is cross-platform, which is no small feat for RPG Maker games.
• It exists! We now live in a world where a Trump-themed RPG Roguelike exists! Huzzah, and you’re welcome!

If I were to do this again, I’d enlist someone else to do the battle balancing, or I’d streamline combat to focus on HP, Attack, and Defense (and Ikari).

I had a lot of fun making this game, although my next LD probably won’t use RPG Maker.

Last minute, but I’m able to make it!

Here we go! (I did this correctly, right?)

Intro and Plug

If you haven't yet played A Boy and His Card, please do so now! This postmortem spoils a lot of the mechanics and surprise of the game.

Toolset and Onset

I've done a bunch of Ludum Dares, and wanted to get back to basics. So that meant learning a new set of tools, with a focus on modern deployment (especially mobile). Here's what I settled on: * Haxe Flixel - A development platform powered by Haxe, Open FL, and Flixel. * Sublime Text - A (paid) text editor that I happen to love. Opened my game in Folder view.

For visuals and sound, I opted out of both categories and used excellent open resources, touching up when I needed to: * OpenGameArt - A great source of graphical/audio resources. * Gimp - For image touch-ups. * sfxr - For generating sound effects.

I want to clarify that I had programmed zero lines of Haxe or Flixel before the Jam. I'm a decent programmer in other languages, but other than compiling the Flixel demos, I was going into this blind.

Also, I vowed to code this entirely on my Mac, because I was hosting lot9s and we wanted to have mobile setups. (Check out his game too!)

Theme and Despondency ##

So I didn't like the theme. "The More You Have, the Worse It Is" sounds really clever, but it describes a lot of mundane mechanics, as well as being super vague with words like "More" and "Worse". Fortunately, I didn't have time to dwell on this, as I quickly learned that I was in way over my head.

Lesson 1: Using a game jam to learn a new language is a great idea, but practice with the language first!

During the first 12 hours, I spent 7 hours sleeping*, and the remaining 5 re-compiling and re-launching the following on Mac and Android, trying to figure out why the scaling was different.

* I have this annoying condition, causing me to require 6~7 hours of sleep per day, called "being over 30".

In the end, I force-scaled every single sprite to match the expected display resolution. This was the wrong solution, since it caused sprites to look fuzzy on non-uniform scale values (i.e., mobile, or fullscreen), and it was too invasive from a coding standpoint. Way later, I learned that a better way to implement this was to apply a zoom value to the default camera, but that was far too late to change anything. The only benefit to this solution was that it allowed me to move on and start developing a game.

Coding and Haxe

My goal for all of Saturday was to write as much code as possible in Haxe, and to hopefully get a map screen and some semblance of combat. When I am having trouble with a theme, I tend to default to RPGs, since I like them more. In addition, I had brainstormed aloud "Wouldn't it be great to make it so that the more debt you had, the worse it got?". This would eventually turn into the credit card madness you see before you. It was around this time that lot9s's laptop started screaming. (It makes sense if you've played his game.)

Haxe as a language is very well designed. The syntax feels a little like Javascript (which is bad), but with strict type safety (which is good), and the ability to cross-compile into multiple backends (which is pretty magical). It relies heavily on callbacks, and has a lot of other cool features that I avoided because I had limited time to learn things. It is also well-documented, which helped a great deal. I had a plugin for Sublime Text that provided syntax highlighting and auto-completion, but it added an unbearable amount of slowdown. Just the syntax highlighting would have been enough, in my opinion.

Haxe Flixel was just amazing. Someone clearly did their homework, because the framework was both fast to develop with and powerful for deployment. Lots of toolkits promise easy cross-platform export, but Haxe Flixel really delivered. I developed the entire game altering between testing on Neko (a fast VM) and Android (to get some mobile aspects ironed out, like Touch vs. Mouse), and then exported to Web, Mac, Linux, and Windows, and it all just worked. There was one minor issue with Web: I had to convert all my audio files to Ogg Vorbis format. But that was clearly documented, so I don't blame Haxe Flixel for this.

I also want to re-iterate: Haxe is a typed language. This means you get fewer vague errors at runtime, as the direct and obvious errors ("you called X on object Y, but it's class Z, which makes no sense") are caught at compile time. Some people prefer looser type models, but I'm a big fan of strict typing, so Haxe worked really well with my coding style.

Lesson 2: Finding the right toolkit is worth learning a dozen new languages.

Words words words... at the end of the day, I had a basic world map, that you could walk around by clicking/tapping, and that would prompt you for "combat".

"Combat" in this case meant a window where the hero and the enemy would leer angrily at each other forever. Oh, and that map was made in Tiled, but is actually just a screenshot saved to "map_1.png". We'll call it a partial success. :)

Scope and Theme

At this point, I knew how I wanted to approach the theme: I'd make a game where you only had a credit card, and got yourself hopelessly in debt trying to do normal RPG stuff. (I wouldn't decide the name until submission hour, based on the first thing that popped into my head.) This meant having a shop of some kind, which meant I needed to get combat working. I wasn't 100% sure up until this point if I was going to do a full 3-day Jam or not, so I set myself a goal: get a functional combat & progression system by the end of Day 2, and then re-evaluate.

Fortunately, years of Ludum Dares have taught me a lot about scope. I chose not to do an Intro Cutscene, and settled on an auto-battler with three different elemental attacks. This would give players a little bit of agency, without being too hard for me to code or balance. Basic elemental triads are tired and overdone, but they do provide a small element of strategy, and are easy to understand by most players.

I was careful to put all of my long-term data in a "GameData" static class (a trick I learned from RPG Maker), so that I could simply swap in a new Game State when I wanted to switch to world 2, etc. I also put my damage and level up code into centralized wrapper functions, since I knew I'd have to balance the heck out of this game in the final hour or so (it always happens). For non-critical stuff, I just copy-pasted sample code and my own code as much as possible.

Lesson 3: Scope and Abstraction are super important. So is knowing when you can save time by being sloppy. This isn't production code, but it still has to run.

Once Day 2 was done (1 A.M. for me), I had most of a functioning combat system, and it was possible to kill enemies and progress from one world to the next:

RNG and Stats

Day 3, I started by adding a tiny bit of randomly-generated text: the world name was generated by pulling from a list of adjectives ("Blue", "Happy") and nouns ("Caves", "Market"), with the first world always being "Green Hills". I've gotten really good with using randomness effectively after my work on Last Dream: World Unknown (shameless self-promotion!), so I knew how much depth the right amount of RNG can add.

Next, I wanted to add the player's stats on a side board on the left. Mostly this was because I had a ton of extra space (and expanding the world map would look bad), but in the back of my head I knew the player would need feedback lest the game feel obtuse and arbitrary (a lesson from past game jams). So I had "HP", "Power", and "Defense", and I knew my store would let you buy items that boosted these. Boosting HP made no sense, though, and I was worried that having just two stats could cause the player to become overpowered. So I made two decisions: force players to buy items from the shop if they wanted it to refresh, and add a dump stat called "Fashion" that did basically nothing. This was... a mistake, as we shall see later.

After programming the left panel (stats), I went to work on the right panel (shop). I randomly generated the stats the items boosted, randomly generated half of their names, increased their prices as you bought more of them, and created a fixed starting set of items to avoid baffling the player early on. (I actually botched this a bit: the starting set of items resets on each world transition, which is not what I intended. But it actually played well overall, so I left it in the game.)

I already had the debt calculation algorithm (from Day 2), so I next added in a set of stacking penalties that were granted when players ended a combat with debt to their name. At that point, I had the great idea of providing a randomly-spawning credit card upgrade that would increase your interest rate but erase your accumulated penalties. You know, just like in real life! I forced one to spawn on World 2, and then, on a whim, tied the spawn rate for Worlds 3+ to your Fashion stat. Mistake #2. I also kind of botched the debt calculation in a subtle way, so we'll call that mistake #3.

Ignoring mistakes, I had my final game. You could move between worlds and fight enemies, buy items, and manage your debts, as well as some fun little Easter Eggs. I balanced it for a few hours, made a few clutch last-minute changes (like actually printing weapon levels and HP values, or hiding the stats&shop to avoid overwhelming the player), and shipped it off for judging!

The Big Mistake

Most people who play my game get mired hopelessly into debt, which is the intended behavior. However, there are a lot of clever people out there, and some quickly figured out a winning strategy: 1. Buy a ton of items in World 1, until your stats all hit 100. 2. Fight the minimum number of enemies in each world (3 in World 1, and 2 for Worlds 2+). 3. Always take the new credit card. 4. If enemies become too powerful in the future, buy a ton more items.

This results in 2 battles between penalty refreshes, which is not enough to overwhelm the player (and the $500. penalty on death is a pittance anyway). And since Fashion>100 guarantees a credit card drop per world, you'll never have to worry about getting too many penalties.

So that's mistakes #1 and #2. Mistake #3 is a little more complicated: the crushing cycle of credit card debt that is present in real life doesn't manifest in the game. It's actually really easy to get out of debt, since the money monsters drop starts to outpace your accrued interest. And something is off about the way interest is calculated: even with a 100% interest rate, debt will keep decreasing. I think the time slice dynamics of when debt is calculated are off, so you get an unnaturally long grace period. And if you know what you're doing, you'll have no problem breezing all the way up to level 50+.

I still think the game does a decent job with the theme, since the dominant strategy is really hard to figure out if you don't look at the code (or this blog post).

The Tiny Mistakes

Briefly: * I forgot to include some way of increasing Max HP, and by the time I realized it, I had already balanced the early game. * I forgot to explain how elemental resistance works in the game. (It's in the Readme, so you know what that means.)

Final Thoughts

This game jam went really well for me, and I'm very happy with what I made. I really pushed my skills to the limit, especially with my goal of learning a new toolkit and language, but it paid off. People seem to enjoy or at least appreciate A Boy and His Card, which is praise that I don't take lightly. Most importantly, now I know that I can do a Ludum Dare entirely on the road (via laptop) in the event that I'm traveling during one of them (which happened during LD39).

For everyone reading, the most valuable thing I did that helped me in this Jam was, in fact, participating in lots of past Ludum Dares. This really helped me learn how to control the scope of my game, and gave me the tools to answer basic questions about coding, audio, and deployments. Regardless of what language you use (and I'd encourage you to keep trying new ones), I would like to personally encourage everyone thinking of doing Ludum Dares to just bite the bullet and go for it! Your first few entries probably won't be amazing (they could be!), but you'll learn a whole lot, improve your skillset, and have a lot of fun!

This is what all the cool kids are doing right?

Made with Word Clouds

Happy weekend everyone! If a shmup where the main mechanic is to sacrifice your powerups to get through tough segments sounds appealing, check out my LD entry: Pew! Pew! I'll also happily rate your game too~~

https://ldjam.com/events/ludum-dare/43/pew-pew