About dylanwolf (twitter: @dylanwolf)


Ludum Dare 37
Ludum Dare 36
Ludum Dare 35
Ludum Dare 34
Ludum Dare 32
Ludum Dare 31
Ludum Dare 30
Ludum Dare 29
Ludum Dare 28
Ludum Dare 27

dylanwolf's Trophies

K-Town Represent!
Awarded by Levi D. Smith
on August 26, 2014

dylanwolf's Archive

I’m in (plus resources for Unity)

Posted by (twitter: @dylanwolf)
Monday, August 22nd, 2016 11:08 pm

I’m in, using Unity as usual. In addition, I’ve gradually been building a collection of one-off C# scripts that can be used for basic behaviors such as:

  • camera scrolling/locking
  • visual effects (bouncing, etc.)
  • basic logic for match-3 and 2D platforming
  • helpers for sound effects
  • UI helpers
  • object pooling

Per the compo rules, they’re open for anyone to use: https://bitbucket.org/dylanwolf/ludumdareresources

Shifty Shapes now on Google Play

Posted by (twitter: @dylanwolf)
Monday, July 4th, 2016 4:41 pm

I finally released the Android version of my Ludum Dare 35 game Shifty Shapes on Google Play.

LD35 Post-mortem

Posted by (twitter: @dylanwolf)
Monday, April 18th, 2016 6:52 pm

Here’s a quick rundown of the ups and downs of my compo entry, Shifty Shapes, which was written in Unity.

What went well


Usually I make some notes about the top themes in each round of voting, but this time I went in cold. (Honestly: I have a few different game ideas floating around in my head right now, so I was open to doing something off-the-cuff.) I had all of the rules for the game written down within minutes of the theme announcement.

The sliding concept was inspired by a board game called Ricochet Robots that I played in analog gaming at Geek Media Expo, plus standard match-3 mechanics which I’d already figured out an algorithm for in Ludum Dare 30.


I knew I wanted this game to have some nice visual effects, since I envisioned it as one of those shiny mobile puzzle games.

Fortunately, there weren’t a lot of moving pieces in the concept, and I started building the effects early (even before I’d replaced the placeholder art).

Animation is something I don’t tend to think about (or I think about so late in the jam that it’s complicated to implement), but a little bit seems to go a long way.

Bouncing UI elements and blocks/items flying to their respective counts were easy to implement. I feel like my biggest win was making item and score counts only increment when the block/item reached it.


The main riff was based on something I’ve played around with before on guitar–variants of C, with Am and Em thrown in. It worked pretty well, which means I spent about 10 minutes working out the tune, leaving most of Sunday for recording and mixing.

Unity UI

Because I wanted new blocks to fill in like a circular progress bar, I ended up having to mess with Unity UI early (as it supports “filled” images). I’ll confess, it’s something I’ve avoided for the longest time, because it’s intimidating.

Rather than mess around with the large block of numbers that don’t seem to change anything (Unity just recalculates the X and Y positions when you change them), I’ve preferred to stick to world space, Camera.orthographicSize and Camera.aspect, 2D Toolkit, etc.

However, I feel like I’ve made serious progress learning Unity UI thanks to this game. And because I didn’t need to dip into 2D Toolkit for text, I think this is the first Ludum Dare where I’ve had no Asset Store dependencies.


There are few things more satisfying as a coder than being able to call a “Reset” method after a Game Over screen (as opposed to “screw it, I’ll just reload the scene”).

What didn’t go well

Block pop-in effect

One of my big plans for visual effects was to have blocks “fill in” like a pie chart. That’s actually pretty complicated if you’re using Unity’s Sprites, and I spent more time than I’d like trying to make it work. Once I realized sprite masking was going to require shader code, I gave up on this approach.

Even though I was reluctant to mess with Unity UI, UI Image supported this exact feature, and I got the effect I wanted. However, I wish there was a way to do this via Sprites, and I spent more time than I’d have liked chasing that solution. (Although, I did do this first thing on Friday night so I could budget my time.)


I’ve been playing around with Krita recently, and because of some of its pen and paint effects, I initially picked it over GIMP. However, the art I created didn’t feel right–it had a dark, hard-contrast feel.

This wasn’t Krita’s fault, I just wasn’t familiar with it. It was definitely a case of thinking a tool based more on physical mediums would magically produce something “painterly” without me having to understand how it worked. I ended up redoing everything (except the cloud particles) in GIMP, and was pretty satisfied with the result, despite spending a lot of extra time on unused art assets.


Because I guess I have something to prove, I decided to try to mix in cajon, banjo, and mandolin in with guitar. I can’t tell whether it works or whether it’s all out of tune, because my first impression changes each time I listen to it.

I suspect part of the problem is I changed the speed on the guitar part in Audacity, and then tried to increase the pitch by the same percentage to compensate. Also, I’m not enough of a musician to pull this sort of thing off with consistent quality (which is why you’ll note all of the non-guitar tracks are mixed very low).

Build and release

To be fair, it went OK, but this is the first time I’ve been frustrated with myself for not planning in advance.

I always go in building for the default Unity 960×600, only to remember on Sunday afternoon that it’s slightly too large for the LD site’s embed (and even a little awkward in my browser). I really need to standardize on a resolution and aspect ratio before I go into a jam. I tend to just jump in the preview window and forget about this part.

Also, given that WebGL builds seem to take somewhat longer than Unity plugin builds did, I need to start planning for this in advance. Luckily, I did a release to itch.io on Saturday, so I was able to iron out some WebGL issues with particle effect sprites early, but it would’ve been stressful if I had waited until Sunday.

Lightbender: Post-Mortem

Posted by (twitter: @dylanwolf)
Wednesday, April 29th, 2015 8:38 pm

Here’s the usual post-mortem run-down for Ludum Dare 32: Lightbender. I usually do “What Went Right” and “What Went Wrong,” but there are elements of both in most of these categories.

Writing a Match-3 game in Unity

Posted by (twitter: @dylanwolf)
Saturday, August 30th, 2014 9:44 am
Dr. Mario (source: Wikipedia)

Dr. Mario (source: Wikipedia)

This year in SeishunCon‘s digital gaming room, I was reintroduced to the match-3 game. I’d played Dr. Mario when I was younger, but more competitive games like Magical DropBust-A-Move, and Tokimeki Memorial Taisen Puzzle-Dama were something very different.

Ultimately, I realized just how many more-or-less neutral decisions are involved in making a match-3 game.

During this year’s Ludum Dare, I decided to jump in head-first. I did a bit of a warm-up the week before, trying to build a Tetris-style algorithm that detected and cleared out lines. This tutorial from Unity Plus was a huge help. Of course, the Tetris matching algorithm–a complete row of tiles–is much simpler than an algorithm that picks out irregularly shaped patches of matching tiles.

If you want to see all of these code samples in context, check out my Ludum Dare 30 repo.

Ludum Dare 30 post-mortem: Parallel Puzzles

Posted by (twitter: @dylanwolf)
Thursday, August 28th, 2014 4:02 pm

What went right:

I felt like the scope was perfect for the limited amount of time I had this weekend. This was mostly luck, but I also knew when to quit tweaking and didn’t regret it.

The match-3 and block-dropping algorithms fell into place like magic. To be fair, I’d given it some forethought–I did a quick Unity refresher on Wednesday where I attempted to build the line-clearing mechanic of Tetris with help from this tutorial. However, that’s a much simpler algorithm and I didn’t have an exact plan. It was a leap of faith that paid off early, leaving all of Sunday for polish. (I’d probably remiss if I didn’t mention that the match-3 concept was inspired by the time I spent in SeishunCon‘s digital gaming room this year.)

I’m happy with the art. I didn’t stretch myself stylistically, and it’s not as crisp and detailed as what I’d hoped, but overall it feels pretty slick if you don’t look too closely. I love posting those screenshots because it feels like a “real” game (well, at least to me).

As in the past, adding a GVerb track covers over a multitude of recording sins. I’m going to say this a lot in this post, but this feels like cheating.

Driving 40 minutes back from the Knoxville Game Design meetup is always a good way to start thinking about design and algorithms.

What could have gone better:

I basically shoehorned a puzzle game into the theme. This was premeditated, mainly because I was itching to dip my toe into the genre. It restrained the scope by removing the need for level design, which helped. However, it also felt like cheating the system to start thinking about a game genre so early (especially since I feel like my LD29 entry was a much stronger “Connected Worlds” concept).

Overall gameplay was good, but not great. I’m happy with this in one sense–I didn’t make a ton of explicit design decisions, so I won the “go with whatever’s easiest” lottery. Still, I feel like the “flip or drop” choice is missing something. I enjoy the game, but I restart as soon as I clear out all of the obvious flip combos. Once I have to drop blocks, it’s like I’ve failed. I feel like a “flip or shift” mechanic would have been better.

What went wrong:

Because I wasn’t livestreaming, I tried to do a status update video on Friday night. OpenBroadcaster doesn’t work smoothly on my laptop. I wasted about an hour or so tinkering with OBS on a night I ended up staying up until 4am.

I don’t understand music. Originally, I picked the current chord progression as a base, then played some random notes over it on a second track. Seemed clever on Saturday, but on Sunday I realized it was too chaotic. After talking to Mike at the post-LD meetup, I think I need to study up on some music theory basics rather than hoping a clever experiment will pay off. (I feel like I’m reusing the same chord progressions and I always use a similar rhythm/picking pattern.)

Overall, I don’t feel like I stretched myself like I should have. I stick to the same style musically and artistically because I don’t have a lot of range. I stick to Unity because it’s all I know. To be honest, I’ve had a few good ratings in past LDs, so I avoid the unfamiliar because I want to keep that up. Next LD where I have the time, I need to set a few goals–for example, use Inkscape instead of GIMP, or use a digital tool like PxTone or Bfxr.

Base code and fonts for LD30

Posted by (twitter: @dylanwolf)
Friday, August 22nd, 2014 2:13 pm

As with Ludum Dare 29, I’ll likely be using Unity scripts and tk2D fonts from my LudumDareResources repo and FntGenerator to create .fnt files for any new fonts.

LD29: “Upper Crust” Post-Mortem

Posted by (twitter: @dylanwolf)
Tuesday, May 6th, 2014 9:50 am

LD29: Upper Crust

What went right:

  • I typically scan through voting rounds 1-4 results before Friday to generate some ideas. I felt the “world-switching” idea for “beneath the surface” was the strongest one I had this time around. (Granted, the idea was a rip-off of A Link to the Past.)
  • I’m happy with the art. I’ve learned to work (rather quickly) with my sketchy “hipster art” style. I feel I pushed myself a bit further than last time, especially with the tileable spirtes. It’s still a little flat and distorted compared to trained artists, but it’s definitely good enough.
  • I didn’t create all the little mechanics that I’d initially brainstormed, but I was pleasantly surprised with what I did get in place and how it fit together. The comment that mentioned “unconventional combat” felt good. Up to that point, I didn’t consider this idea much more novel than the standard top-down action-adventure.

What could have gone better:

  • There’s decent use of the world-swapping, but it could have been better. I wanted the overworld to feel “safe” (hence why there are no enemies and you heal there), but it never became anything more than a waypoint.
  • As pointed out in the comments, the mana system was unnecessary. I still think there might be some use for it, to prevent you from just “teleporting” out of every sticky situation. It would need a lot of tweaking, though. Perhaps independent cooldowns on teleportation and lava burst would work better.
  • I feel like I phoned in the music. A few more takes and I could have ironed out some of the rough bits. I didn’t stretch myself with the Underworld guitar–it was what came comfortably to me rather than what fit the mood. I did stretch myself on the Overworld, but that means gratuitous mandolin which can be a bit jarring (it’s not my forte).

What went wrong:

  • Livestreaming. I assumed some of the glitches I was getting in Windows Saturday night was the result of livestreaming/recording (as my gamedev laptop is pretty mediocre). I didn’t have any viewers on my stream, so I shut it down. Now, I wish I’d at least recorded the full weekend to video so I could put together a timelapse.
  • This concept uses a lot of colliders–camera boundaries, pickups, enemies, hazards, clickable areas, etc. I wasn’t prepared for how colliders from two separate overlapping worlds might (unintentionally) interact. I didn’t fully understand which items should cause triggers versus collisions until later in the development. I lost a lot of time to bugs that just “appeared” when I added a new feature, and patched them with the code equivalent of spit, gum, and duct tape. A bit more planning into my physics layering and hierarchy and a bit less premature optimization would have been helpful.
  • PlayerController.cs is a hideous god object singleton that rules over the dystopian wasteland of game state with an iron fist. I started sticking player-related state there, and at some point just decided to put all my game state there, too.
  • I hadn’t looked at UTiled in a while and I’m not an expert on optimizing graphics. Saturday night I first noticed the tile maps weren’t displaying pixel-perfect and panicked. Scaling down to 640×480 was a time-saving hackfix, but it was disappointing. ViNull pointed out that my problem was in Unity texture compression settings, so it was a quick, simple post-compo fix.
  • I had an idea for a monster that would stand in place and hurl fireballs horizontally or vertically if you passed by. Since it wouldn’t be as easy to kill as rock monsters or avoid as lava, it would have added variety. Unfortunately, it was way down the list and didn’t make it in.
  • I started level design way too late. Saturday night I sketched out the 4 levels, and by Sunday I was too stressed to keep going once I built them out. I could have used more of the breakable rocks and enemies to add some variety to those levels. After playing through the game a few times post-jam (plus Armanky’s Strawberry in the Underworld, which does “world-swapping” better than I did), the squandered potential was painfully obvious.

Base code and fonts for LD29

Posted by (twitter: @dylanwolf)
Thursday, April 24th, 2014 12:19 pm

To avoid having to recreate some basic tk2d fonts and Unity scripts I’ve created during the past two Ludum Dares, I’ve set up a LudumDareResources repo on bitbucket.

I’ve also put up the barebones .NET application I use to create FNT files that I use with Unity 2D Toolkit under FntGenerator.

I’m not sure it’s useful to anyone else in its current state, but ideally I’d like to build upon it as I participate in more LDs.

LD28 entry released on Google Play

Posted by (twitter: @dylanwolf)
Monday, April 21st, 2014 2:49 pm

A quick shameless plug: I released the game I started as part of the last Ludum Dare on Android last week.

[cache: storing page]