About fleegle2000


Ludum Dare 32
Ludum Dare 31
Ludum Dare 30

fleegle2000's Trophies

Dare To Play - LD 37
Awarded by LDA
on January 3, 2017

fleegle2000's Archive

UCON Post-mortem

Posted by
Monday, April 20th, 2015 5:47 pm

Check out my game here!

This was my third consecutive and also third ever Ludum Dare entry. I’m beginning to feel a bit like a seasoned vet – however I found this one to be the most difficult yet. I now have an established method for completing a Ludum Dare game and am much more familiar with my tools now, so I could focus more on creation and spend less time struggling with my tools. The difficulty was due mostly to (A) my distaste for the theme and (B) setting my sights higher on what I intended to accomplish. I am pleased to report that most of the features I planned made it into the game. You can check out my repository here to see what didn’t make the cut for submission.

A screenshot of the finished product:


As usual, before the competition I wrote down a brief list of idea for each theme. I couldn’t come up with much for “An Unconventional Weapon” so when the theme was announced I had a bit of trouble coming up with an idea. I had written down something about creating a weapon from parts, so I used that as my core, but then I had to decide how the player would use that weapon. I made use of some of the ideas I came up with for other themes (another benefit of brainstorming on all the themes before the competition), which included containing a “blob” monster for the “It Spreads” theme. I had also written down ideas for combining parts for the “Four Elements” theme, and there are probably some elements from other themes, too.

I like to maintain my ordinary routine when working on game jams – I eat and sleep like I normally would, take regular breaks (not too long though!). Since the theme was announced at 9 P.M. my time, I spent the evening brainstorming, went to bed at a decent hour, then got up bright and early the next day to start coding. In the first few hours I got the core mechanic working with simple programmer art, then worked on the toolbar and workbench mechanics and the guts of the UI, again using placeholder graphics. By the end of the day I felt pretty good about the mechanics, and decided to leave content for Day Two. I spent most of the second day working on the graphics, starting with shader code to give the blob its truly blobbish appearance (you can see what the blob blocks looked like before if you use the debug feature). The last half of the day was devoted to fixing up the UI, adding sounds, and finally coming up with some music. I spent the last few hours squashing some bugs and improving the visibility of UI components. This time around I really felt the crunch in that final hour before submission. I wanted to make the text on the screen pop a little more, and I wanted to add more/clearer instructions as the controls were not as straightforward as previous entries. I definitely sacrificed a little bit of usability to improve on other areas, and I would say that is probably my biggest regret, as I normally try to make the controls as intuitive as possible.

Some screenshots I took during development:

ld2                                                  ld4

Things I wanted to add but didn’t have time for:

Originally, when you used a weapon on the blob, it would take time for the rest of the blob to adapt to the attack. I had in mind a simple “neural” propagation that would send a pulse back through neighbouring blocks. Players would be able to prevent parts of the blob from adapting by cutting them off from neighbours. Would have been a cool little mechanic that would have added a bit more strategy to the game, but alas there was not enough time.

I wanted each part to have a unique sound, so when a weapon hit the blob it would play the sound of each part together, giving each part combination a distinct sound.

I wanted to add a targeting reticule when the cursor was over the map, to make it clearer that you could shoot at the map. This would have been super-easy to implement and was more an oversight than a time issue.

There is a graphical bug with the blob – if you haven’t noticed it yet, just pretend I didn’t just say that :) I spent a little bit of time trying to debug it, but I couldn’t figure it out and had to move on. I plan on releasing a post-compo version and my number-one goal is to squash this bug.

I made it easy in the code to adjust the difficulty, but there is currently no way for the player to change the difficulty level. I would have liked to let the player choose the difficulty – I probably ended up making it too easy (if you are fortunate enough to find good parts early it is pretty easy to beat the blob).


I’m pretty happy with how things turned out, overall. It feels good to know that there isn’t much I would have done differently. Aside from adding the things listed above to the post-compo version, I will probably add more levels, different colored blobs, and better-looking parts.


Now that the hard part is over, I look forward to seeing what the rest of the community has made. See you next time!

Third Time’s a Charm

Posted by
Thursday, April 16th, 2015 6:27 pm

Hello fellow LDers,

This will be my third Dare, having done #30 and #31 before. Check out my earlier entries if you haven’t already. I recently released a new post-compo version of WORLDS (#30).

I am using most of the same tools as last time, though the custom library I am using is more sophisticated than last time, and I am going to try to use Tiled or Tile Studio if I decide to make a tile-based game.

As with my previous attempts, I’ve been going through the list of final themes and coming up with ideas for each one. I must admit I am not as enthused about the options this time around (but at least there’s no Snowman :)).



Notepad++/Sublime Text 3 (edit in sublime, run from notepad)

Lua/LOVE engine

LOVE helper libraries

Custom physics/graphics libraries – LoveTemplate

Tiled/Tile Studio (if a tile-based game)



CgMusic/Ableton Live 6.0.1 (bundled version)

Daybloom Post-Mortem

Posted by
Tuesday, December 9th, 2014 12:43 pm

This was my second Ludum Dare, having previously done WORLDS 2D in LD30. You can check out my latest entry here, and my previous here.

Daybloom, by fleegle2000

Daybloom, by fleegle2000

Having one under my belt I thought the second one would go a lot smoother. While that was generally the case, I did experience a few hiccups and frustrations (although thankfully I didn’t run into any show-stopping bugs – so from a coding perspective it went pretty well).

Before the competition began, I went through the theme finalists and jotted down a few ideas for each (well, most. There were some that I didn’t generate any ideas for). I was dreading the prospect that Snowperson would get picked, because I generally dislike snow and holiday-themed games. In the event that it did get picked, I planned on doing some *ahem* creative interpretation of that theme.

Some of the ideas I played around with before I knew the theme were a Pokemon-esque collectible animal game (Artificial Life), a game about being stranded on an asteroid, inspired by the Philae lander (Deep Space), and some kind of endless runner (You Can’t Stop). I tend to interpret themes fairly literally, as you can see.

I knew that whatever I was going to do, I wanted to play around with procedural generation, as I had just started exploring that aspect of game development and wanted to flex those newly-minted skills. I had also been thinking about the Playing Both Sides theme which clearly had an influence on my final design. I wanted to try adding some story elements this time around, too, as my previous entry had minimal story.

When the theme announcement hit, I was extremely relieved, not only because Snowperson didn’t get picked, but because it fit with some ideas I had been playing with in my head. Fortunately I had come up with a few ideas for the theme beforehand. One thing that’s nice about brainstorming before the competition begins is that you can often incorporate ideas you’ve generated for other themes into your game. It means you can hit the ground running and spend minimal time in the brainstorming/design phase.

I decided that I would try livestreaming my progress this time, so I fired up Open Broadcaster and announced it on Facebook and Twitter. Almost immediately, I felt uncomfortable. It felt like someone was looking over my shoulder, and I have trouble concentrating on the task at hand in those situations. So, after about two hours of very distracted development I called the experiment and shut down my broadcast. A combination of little sleep the night before and the added pressure of the camera made me very unproductive in the first couple hours. Once I shut down the broadcast I felt like a huge weight had been lifted and I was better able to focus.

I had the idea to use a radial oscillator to simulate a roiling sun. I would change properties like frequency and amplitude to alter the appearance of the star. The star was essentially just a polygon with points generated by a noise function, using additive blending to cause overlapping parts of the polygon to brighten. I decided that the main goal of the game would be to maintain a delicate balance between the star growing too large, or collapsing and going supernova. Of course there were some issues with plausibility, since that’s not really how stars work, so I added the fantastical element of a “being” living in the star that could affect its properties. This gave the game more of a science-fantasy feel, so I ran with that in generating the rest of the story elements. The player could feed the being, pacifying it but also causing the star to grow larger. To counter this growth, the player could also “attack” it, which would cause the star to shrink but oscillate more erratically. If the star “roiled” too much, it would collapse, and if it grew too large, it would fry everyone in the system. Now I had to come up with a plausible scenario in which the “caretakers” of the star would both feed and attack the being living inside it. Drawing from an idea I had when I had considered the possibility of the “Playing Both Sides” theme being chosen, I decided that there would be two opposing factions, one that felt that the being needed to be fed, and one that felt the being should be attacked. The player is forced to alternately placate and enrage the beast. To keep the player on her toes, both actions had a random modifier that would reduce the possibility of reaching perfect equilibrium (spoiler alert: after some playtesting I realized that it is still possible to find that equilibrium, but it’s mostly dependent on luck). The player would essentially have to see-saw and hold out long enough to beat a timer. That was, in essence, the entirety of the game.

Let me take a moment to explain my design decisions. First, from my past Ludum Dare experience and my observations of other entries, I learned that it is best to settle on a simple premise, focus on making a really solid core mechanic, then work on really polishing that core experience. I wanted to avoid the dangers of feature creep. I feel that it is better to make a short, simple game with a lot of polish than a longer, more complex game with tons of unfinished features. If any features do get left out, the player shouldn’t be able to notice (i.e., it should feel complete even if you know there are all sorts of things you meant to add but couldn’t get to in time). You don’t want the game to feel broken, and you can always add more features in a post-competition version.

Second, I knew that adding a random component could be problematic in that players might feel that they had little control over the outcome. I knew that this was something that would have to be fine-tuned, and I still don’t think it is perfect. I plan on tweaking the balance of the game in a post-competition version.

Third, with respect to the dialogue and characters, my decision to use “hats” instead of faces for the characters was motivated by a number of factors. 1) while I do have some artistic ability, I am not very good at drawing people, at least not without them looking more cartoony than I wanted. 2) the hats I picked are essentially “gender-less,” in the sense that there are no indicators as to whether the characters are male or female, or even whether “male” and “female” are legitimate categories for this species (the hats might suggest that the protagonists are roughly humanoid, but there is no indication in-game as to whether or not they are human). 3) the hats are more “symbolic,” adding a little bit of abstraction that fits with the action outside the dialogue box. It is important that the art style be consistent.

There were a few features I wanted to add that I had to scrap due to time, but that I want to add in my post-competition version. First, I had intended to provide more visual cues as to the status of the star. The radius of the star is easy enough to see, but it can be difficult to judge how close the star is to becoming too erratic. I did add a subtle background glow that gets brighter as the star gets closer to collapsing, but it is probably too subtle. I will likely add warning sounds as well to indicate that action needs to be taken, fast. I also wanted to make the win and loss conditions more visually interesting – currently you just get the characters telling you that you’ve lost (or won), which isn’t very satisfying.

I planned on adding more layers to the star, to indicate that the difficulty had increased. Currently there is a slight increase in difficulty as time progresses, but it’s hard to discern – I want to add more visual feedback, so the experience feels less “random.” It is actually less random than I think people realize, because they do not immediately notice the change in difficulty and attribute it to the usual random fluctuations. I also want to add more levels – with different starting conditions, effectiveness of the acolytes and bombs, and visual differences.

The mechanic for this game was simpler than the one I chose for WORLDS 2D (which was still fairly simple) but as a result I had a bit more time to really polish the experience, which I don’t feel that I did adequately for WORLDS.

That’s it for now. I hope that my experience might be instructive for some of you, and I also hope that you try my game (and WORLDS, if you missed it last time). This was another really valuable experience for me, and maybe next time I’ll be ready to give livestreaming another try. Enjoy the playing and rating portion of the competition – this is the really fun part! I am constantly amazed by the sheer number of great gameplay experiences each Ludum Dare generates, and the amount of talent and passion in this community is just incredible to witness.


Happy game-making!


Second Ludum Dare Entry

Posted by
Thursday, December 4th, 2014 5:48 pm

I was finally able to participate in LD for the first time at the last competition, and am looking forward to my second outing. The tools I’ll be using haven’t changed much from last time, though I’ve discovered some nice libraries since then.



Engine: Lua/Love + the HUMP library and custom library with general-purpose tool functions.

Graphics: Inkscape, Paint.NET, possibly Photoshop. I may use Tiled if I end up making a tile-based game.

Audio: Audacity and Bfxr for sound effects, cgMusic and Live for music.



I’m personally a fan of sleep, as I do my best work when well-rested. I will spend Friday evening brainstorming and coming up with a design document, then after a good night’s sleep I will begin the project in earnest.

The first day I will concentrate largely on coding – getting the core mechanic in place. The second day will be devoted to content creation, including level design, graphics, and audio. This is roughly the strategy I took last time, and it seemed to work out pretty well.

WORLDS2D Post-compo version

Posted by
Wednesday, October 29th, 2014 6:17 pm

After much delay, I am releasing a post-competition beta version of WORLDS2D. Beta, because the core features are there but I’m going to be adding more content. Right now there are 20 levels to play, which is far better than the paltry 5 levels the competition version had. The competition version was really just a teaser – there was no real challenge to the levels. Hopefully the new levels prove to be more of a challenge, and the experience will feel more like a real game. Please don’t hesitate to send me feedback! The feedback I got from the competition version really helped me polish the experience of the post-competition version, and I want to thank everyone who took the time to play the game and give me their honest opinions!



WORLDS 2D Post-mortem

Posted by
Tuesday, August 26th, 2014 5:44 am

So now that I’ve had some time to digest my experience with Ludum Dare, I thought I’d do a brief post-mortem.

Check out WORLDS 2D if you haven’t already.

This was my first Ludum Dare, and overall I’m pleased with what I was able to accomplish. Obviously there were a few things that I didn’t get to finish before the deadline, and there are a few things I would do differently next time.


What I was able to finish:

Core mechanic

Graphics, including an animated character, transparency effects on worlds, fuel gauge, “return to menu” icon, and end screen animations

Sound effects and music

Collision detection at world edges

Title and ending screens

Tutorial levels


What I wanted to do but didn’t have time:

More levels (I was just getting started)

Glyphs at the end of each level instead of the “goal reached” message.

Level selection on the main menu

Option to switch to fullscreen

Make the music quieter

Indicator for when a world is within range

Title music

Endgame music

Vanishing worlds (like ghost worlds except they fade out completely, killing the player. They do fade in again)

Unstable worlds (worlds that shake more and more furiously as they dissolve, have to get out before they dissolve completely, but are only triggered when the player enters them)

Non-numeric timer for unstable worlds


What I did right:

Finished key features and debugged them before moving on to the next item.

Spent some time at the beginning planning and making a list of tasks to complete.

Kept my normal sleeping schedule – I am far more productive when I’m not sleep-deprived.

Divided tasks up appropriately – focussed on core mechanics and getting the basics down on Day 1, then spent Day 2 adding sounds, music, levels and polish.

Spent the last couple hours making sure the repository was working right, that I understood the submission procedure and that there would be no complications at submission time.


Things I would have done differently:

I spent far too long trying to add obstacles within the worlds. I got bogged down trying to get the collision detection working for them. Thankfully I did eventually abandon in-world obstacles to focus on more important things, but I should have given up on it sooner or just put it on the list as an “if there’s time” feature.

I spent a bit more time than I should have polishing the end-game screen, but I wanted to give the player some reward beyond just a “you won” message.

I should have spent a bit more time designing and adding levels.

First LD entry

Posted by
Friday, August 15th, 2014 2:04 pm

This will be my first Ludum Dare. I have been following it for a long time but the timing never worked out for me before.

I will use the following tools:

Engine: Lua/LOVE

Editor: Notepad++

Graphics: Paint.net, Photoshop

Sound: Sfxr and Audacity, plus microphone. Possibly Live and a MIDI keyboard for music, and Fake Music Generator.

Libraries: lume, plus my own custom library (available at http://sourceforge.net/projects/fleegle2000ld30/) that includes some physics functions (oriented toward space games), commonly used math functions, and utility functions for copying tables.

[cache: storing page]