About BadgerPriest

CS Masters student at Berkeley who likes to make things in his spare time.


Ludum Dare 33
Ludum Dare 30
Ludum Dare 29
Ludum Dare 27
Ludum Dare 22
Ludum Dare 20
Ludum Dare 19

BadgerPriest's Trophies

The You Made Me Play For Far Too Long Award
Awarded by NicoM
on May 8, 2014

BadgerPriest's Archive

Shattered Worlds Postmortem

Posted by
Thursday, September 11th, 2014 4:34 am



True to my promise in my last postmortem, I worked in a team again for LD#30. We had a great mix of veterans (Alex, Greg, Natasha, Tikhon doing coding, and Jordan doing art and design) and newcomers (Beth doing level design and writing, and Aylan doing music and SFX), and we’re pretty proud with our end result: Shattered Worlds.

Let’s talk about what we did right and wrong. But words are boring, so let’s illustrate this postmortem with a selection of some of the lolcommits that some of us took during the jam.

What Went Right

Simplicity over complexity

Unlike last time‘s brainstorming session, where we tried to combine many ideas together into a very complex game, this time around we tried to distill our ideas down into a core gameplay element. We tried a few ideas that involved manipulating properties of different worlds before finally settling on the mechanic of overlaying levels together.


A mechanic that gave us a lot to work with

At the same time, we were fortunate to not be constricted too much by our gameplay mechanic. We were able to come up with a wide variety of settings and obstacles to go with it, from bees to bears to lasers.


Good team composition and task management

Having a team of people with diverse talents came in handy once again, as we were able to split up the work pretty well. Compared to last time, we had one more designer and a few fewer programmers. This seemed like a pretty positive change: two designers meant that a lot of thought went into every aspect of level design and also that Jordan was free to focus more time on the art assets, while we had just enough programmers that we all knew what we were doing and weren’t stepping on each others’ toes too much.


Distinctive style and flavor

We tried hard to make a game that looked and felt unique, and I feel that we did a pretty good job in that regard. Giving each world type a completely different palette and style helped (initially we were hoping to have distinctive music for each world too, but sadly our musician didn’t have quite enough time to make that happen), as did the quirky in-game messages. There are certainly places where we could have used more polish, but overall I think we didn’t do too bad in the style department.


Hint system

We always think our games are easier to figure out than they actually are, simply by virtue of playing them over and over while making them. In light of this, Tikhon had the foresight to propose a hint system to guide players when they needed help. Many of us initially thought that hints would be unnecessary and would make the game too easy, but we have since seen the error of our ways: quite a few comment specifically mentioned the hints as an important component of the game.


What Went Wrong

Switching frameworks in the middle of it all

For the first day of coding, we used EaselJS. Easel is ok, but none of us knew it particularly well, and it didn’t seem to have anything built-in that would help us make a platformer (all in all, we essentially used Easel as a wrapper for canvas). Our code quickly became a tangled mess of modified example code we found online and our own attempts at doing things like collision detection. It was clear that we couldn’t really go on like this.

The solution was PhysicsJS, an awesome physics simulation library that had all the tools we needed to cleanly and efficiently create the physics for our game. Unfortunately, porting our code over from Easel to PhysicsJS was not as easy as we had hoped, because the two libraries represent objects and their interactions in completely different and incompatible ways. Come Saturday evening, Tikhon began to spearhead the effort to switch to PhysicsJS while the rest of us continued working in Easel, but by Sunday we realized that the only way PhysicsJS would work for us would be if we essentially did a complete rewrite.

This was a huge decision. Basically all the code that we wrote on Saturday and early Sunday had to be scrapped, and we had to build up the game almost from scratch. As Sunday came to an end, we just barely got a couple of levels working. The switch to PhysicsJS was complete, but it left us with less than a day left to implement most of the levels. Somehow, we still managed to finish. I still think the decision that we made was the correct one — our old physics were horribly buggy and PhysicsJS enabled us to do a lot of cool things that we hadn’t even considered at first (like movable crates in the zombie level, which we got essentially by accident). If we’d stuck with Easel instead, our final game may have had a few more levels in the end, but it wouldn’t play nearly as well. Of course, the best thing we could have done in hindsight would have been to actually research our framework / library options ahead of time rather than >24 hours in.


Balancing was pretty hard

In particular, the low-gravity space levels — while very cool conceptually — proved to be an enormous pain to plan for during level design, because for every level after the first space level, we had to consider the possibility of the player activating low-gravity and try to make the level non-trivial to beat. We definitely didn’t do the best possible job here: some levels are still much too easy with the use of low-gravity.

If we’d had a little more time, we had plans for a system where some levels would be disabled from overlaying other levels, based on game objects not being able to overlap one another. This feature would have conceivably enabled us to make more levels without having to necessarily consider every possible pair of overlapping levels.


We couldn’t get the controls quite right

We spent some time making the game feel right as a platformer, and even had some of our platformer-loving friends playtest it from time to time, but we never got the feel quite right, not even within PhysicsJS. Fortunately, this doesn’t seem to bother too many people, though aforementioned platformer-loving friends were a bit unhappy with it.


Not much of an ending

You go through 11 levels accompassing four different worlds and fight through everything from space battles to a zombie siege, and when you reach the end you get … a dialog essentially saying “The End”. It would have been great to have a real ending of some kind, but by the last hour of the jam we unfortunately still had our hands full just making the rest of the game work. Alas.


All In All

We’re pretty happy with how Shattered Worlds turned out, and LD#30 was a great experience overall. It seems to me that we’re improving as game creators and as a team (well, it’s not exactly the same team, but it’s close enough), though we’ll have to wait for judging to end to see how true that is. Hopefully we can make participating in the LD Jam a regular thing. :-)

>> haven’t tried Shattered Worlds yet? you should! <<

Shattered Worlds: Trailer and Playthrough Video

Posted by
Thursday, August 28th, 2014 12:21 am

If you’re stuck on a specific level or just want to see what Shattered Worlds is about, we’ve put together a trailer and playthrough video that will help:

Shattered Worlds Trailer and Playthrough

Has your interest been piqued? Then check out Shattered Worlds, a puzzle platformer with a twist. All feedback is much appreciated.

Asteroid Tycoon Postmortem

Posted by
Wednesday, May 7th, 2014 5:17 pm

For this Ludum Dare, I worked with a group of friends to create Asteroid Tycoon. I’ve done the Compo a few times in the past, but none of us had ever game jammed in a team before, and it was quite the experience. I’ve learned that doing Ludum Dare with a team brings with it both enormous benefits and unexpected challenges.

What went right

Diverse talent

Being able to work with an artist, a UI designer, a game designer, an amateur musician, etc (some people filled multiple of these roles) was an amazing experience compared to previous Ludum Dares. For the first time, I’ve submitted a game that actually looks and feels really solid.

Combining multiple ideas together

During our team brainstorming session, a few ideas became big hits: a candy-box-like about building an asteroid mining empire, something involving moles and tunneling, and a game with programmable robots. The idea for Asteroid Tycoon came about as we realized that we could combine elements from these three ideas into a coherent concept.

Constant balance tweaking

Gameplay elements underwent many changes as work on the game went on. For example, the robot upgrade progression initially was triggered by amount of minerals collected (a different mineral for each robot), but switching to a depth-based system proved to be a lot more enjoyable for the player. For much of the weekend (at least once we had something playable), at least one person (usually a team member taking a break) was playing the game at all times, so we constantly had feedback that we used to adjust parameters, and in many cases, rework entire mechanics.

Cute little touches

Little things like the marquee seem to have made a big difference in enjoyment and immersion. Also, some of our last-minute graphical tweaks, such as the beaming-down animation from the ship, improved the look of the game rather significantly.

What went wrong

Repetitive music

Once we had a short loop of music, we deemed that “good enough for now” and decided to come back to the music situation if we had time. Unfortunately, we didn’t have any more time to work on music, and the result was slightly disastrous, as the constantly repeating main loop proved to be annoying to many players. We quickly added a mute button, but the damage was already done. In the future, I’d hesitate to add music unless it was sufficiently varied to not be a hindrance.

Not enough organization

Never having worked with a team on Ludum Dare before meant that my default workflow was an informal, poorly defined task list and a single development branch in git. This is reasonable enough for one person, but proved to be a disaster when working with a team of 7 people. On several occasions, lack of communication led to two programmers separately implementing the exact same feature or our two artists stepping on each others’ toes. Meanwhile, all work being on a single branch meant that nearly every commit resulted in a merge conflict, which proved to be very time-consuming in the long run. In retrospect, we should have had a more well-defined task-assignment scheme and used feature branches.

Gameplay not explained clearly enough

The primary gameplay mechanic in Asteroid Tycoon works as follows: you first click on a robot to build and then click on a destination square for it to try to move to. However, we didn’t explain this very clearly within the game itself, which led to many players thinking that they had to click on the surface or on the spaceship — the result being that the robots reached their destination immediately and from then on proceeded to move in a way that would have appeared to be more or less random to the players.

To make matters worse, important information is conveyed to the player via printouts that regularly appear but go away on the next mouse-click. What we didn’t anticipate was that most players click around so quickly that they don’t even get a chance to see the printout before accidentally closing it (old printouts are still saved in the top-left panel, but most players never bothered to use it).

In retrospect, we should have done a better job of explaining exactly how gameplay works from the start, and come up with a different way to hide printouts (perhaps by giving them a Close button). These are both hopefully things that we will work on in the post-Jam version.

Only starting work after 18 hours

We made the conscious decision to not start work until noon (PST) Saturday, to give our brains plenty of time to process our different ideas. While this gave us lots of brainstorming time, it put us at a disadvantage time-wise compared to most Jam teams, and led to us being very pressed for time near the end (compounded by the fact that many of us had to go to work on Monday). In the future, I’d like to spend a little less time brainstorming and perhaps at least try to get a little bit of actual coding done Friday night.

All in all

After trying a Ludum Dare with a team for the first time, I don’t know if I can go back to doing the Compo! Not only were we able to build something bigger and more polished than any one of us could do on their own, but we had lots of fun working as a group. We’ll try to work together in future Ludum Dares.

As far as Asteroid Tycoon goes, we’re really happy with how it turned out. We’ll probably tweak it a little bit post-Jam — primarily to make the instructions more clear, make the music a little less repetitive, and fix some sneaky bugs that people have reported.

Compare Your Results to Your Past Performance

Posted by
Tuesday, September 17th, 2013 1:42 pm

I made a quick and dirty userscript that displays a “Performance” graph on all user pages. For example, mine looks like this:


The script can be found here.

To install in Chrome, download the script, go to Tools | Extensions, and drag the downloaded script into the page. To install in Firefox, use Greasemonkey. To install in other browsers, do something else.

Let me know how it works for you guys.

10 Second Roguelike Postmortem

Posted by
Friday, August 30th, 2013 2:49 am

Well, I’ve never done one of these before, so here goes nothing.

What went right

Long brainstorming session

I was fortunate in having a group of friends help me brainstorm ideas when the theme was first announced. About a dozen ideas were thrown around, some interesting and some worthless, until I finally settled on this one. My first few ideas were tempting but also ultimately crappy, so being able to bounce back ideas with other people saved me from falling into the usual trap of doing the first thing that fell into my head.

Playing to my strengths

This isn’t the first roguelikelike I’ve made, and for good reason, aside from loving the genre: I’m not any good at art, at all. In almost any other genre, I’d be forced to spend long hours putting together terrible art, but fortunately this wasn’t an issue for me here.

Not reinventing the wheel

For level generation and field-of-view computation, I used rot.js, an excellent set of utilities specifically designed for roguelikes. I probably could have managed without rot.js, but when you only have 48 hours, why not limit the work you have to do as much as possible? Using rot.js also offered the huge advantage of giving me something vaguely playable within an hour or two of starting, meaning that I could spend the rest of the competition working on making gameplay as fun as possible.

Addictive gameplay

My main objective with this game was making it as fun and as fast-paced as possible. To this end, I made death be completely harmless, let players immediately create a new character in one click and jump back in the game, and provided a silly soundtrack to accompany the dungeon romp. When my playtesters (er, friends) started to refuse to give me back the computer, I knew that I had stumbled onto something.

A little bit of flair

Roguelikes are inherently rather bland visually, so small touches to make the game look good were important for the player experience. Things like smooth lighting, a shiny experience bar, and a memorial to dead characters at the end of the game were all relatively quick to implement and provided a nice distraction from the big-picture stuff for me, while making the game look much more polished. Don’t skimp on the small stuff!

What went wrong

No good plan for the second day

Most of the game features (timer, dungeon exploration, combat, character creation) were completed in the first 24 hours, which made me very optimistic about the next 24 hours. However, while there were a lot of things that I wanted to do (including items, spells, and more interesting monsters), I spent so much time debating about what order to do them in that I wasn’t able to work most of these features into the game. In the end, my second day consisted mainly of making levels and creating the boss fight and ending, as well as doing a lot of playtesting and minor tweaking. Next time around, I’d like to budget my time a little more effectively, especially for the second day.

Not enough replay value

Well, you beat the boss, and then the game is over. Several playtesters told me the game needed to have a way to continue playing after the boss fight, but, given how messy my second day was, I declined to implement this at the time. I did eventually address this issue by adding an Infinite mode to the post-compo version though.

Dungeon annoyances

I didn’t spend enough time making sure that all dungeon stairs are reachable within 10 seconds. Sometimes the stairs aren’t, though they should still be reachable if you have a faster character (speed > 1.0). And I’m pretty sure there’s a (small) chance of the boss appearing in an unreachable location on the final level, though I haven’t personally seen that. Regardless, I should have spent more time ensuring that every game is beatable, regardless of luck of the draw.

Not enough lore

The game’s story consists of two paragraphs of flavor text that I hastily cobbled together as the minutes were counting down. I suppose it’s not that big a deal for a game that seems to have more in common with Quake than with Rogue, but it still would have been nice to have an actual story.

All in all

I’ve taken part in three Ludum Dares before, but this was by far my most successful one: I made a game that most players found to be fun, which is a feat that I have never really achieved before. Next time around, I will hopefully interpret the theme a little more creatively, and I hope to address my biggest issue from LD27: insufficient planning of secondary game features. Still, I’m pretty happy with Ten Second Roguelike. Let me know what you think!

[cache: storing page]