About 3beards


Ludum Dare 27
Ludum Dare 26

3beards's Trophies

3beards's Archive

Time To Game(jam)!

Posted by
Tuesday, August 13th, 2013 2:50 pm

LD27 is coming up and it’ll be my group’s 3rd LD! Unfortunately one of the beards will not be making it so we’re down to 2beards.

We’re changing it up a bit this time around! Listed is the framework we plan to use and tools that I will use.

  • Language: JavaScript/HTML5
  • Framework: Cocos2d-html5
  • IDE: IntelliJ IDEA
  • Art: Photoshop
  • Sounds: GarageBand and bfxr
  • Others: git, jslint, Tiled and TexturePacker


Should be fun!


None Too Shabby

Posted by
Thursday, May 23rd, 2013 5:53 pm

The results are in and they were pleasing indeed!

Our first Ludumdare was LD25 and result wasn’t too shabby all considering.

Plane Of Misery

#13 Innovation(Jam) 3.97
#29 Humor(Jam) 3.61
#96 Overall(Jam) 3.35
#105 Fun(Jam) 3.10
#148 Theme(Jam) 3.37
#150 Mood(Jam) 2.86
#179 Graphics(Jam) 3.10


We were incredibly happy with how we did but LD26 was a new competition and we had to do better.



#37 Fun(Jam) 3.69
#39 Theme(Jam) 4.10
#45 Overall(Jam) 3.80
#49 Innovation(Jam) 3.78
#126 Mood(Jam) 3.43
#239 Audio(Jam) 3.00
#245 Graphics(Jam) 3.31
#325 Humor(Jam) 1.94


Mission accomplished! In the overall category Plane of Misery was 22.6% which was awesome but Mobius was 6.1%!!!!!

Now the bar is set even higher.



Mobius Post Mortem

Posted by
Thursday, May 16th, 2013 1:26 am

Mobius Post Mortem

    From the perspective of 3beard’s C.J. Kimberlin


What went right?

Complete Game – Unlike our previous Ludumdare game, Plane of Misery, Mobius felt like a complete game. Sure it is pretty short (can be beaten by someone who knows how to beat all the levels within 10 minutes) and there would be some features that would have been awesome to have if we had the time (level indicator and possibly scoring of some kind) but the game was complete for the competition. The mechanic seemed solid and we created 21 levels that leveraged all the level mechanics of the game. We had sound (for those who played Plane of Misery this was a step up) and I was pretty pleased with the art style we went with (simple yes but we’re three programmers and not artists). We scoped appropriately and managed to produce a product that felt great for the time we had to work on it.

Mechanics – I’m certainly biased as it was primarily my job to create the mechanics for Mobius (physics, collision, ect…) but I felt that the end result ended up being quite smooth. It isn’t perfect, there’s a very obscure collision bug where the runner will flip out and skyrocket across the screen. One of my partners encountered it but we were unable to reproduce it to try to figure it out. Also I saw an odd collision behavior when a friend of mine try to jump at just the right moment at a bottom left corner and sent the runner in the opposite direction. Overall though the mechanic bugs seemed few and unlikely to encounter, which I find acceptable for a 72 hour competition.

Library Extension – Starting about a month before the competition, we spent time expanding the available functionality of the game library that we planned to leverage. This including creating runtime editing of objects, data reporting, UI functionality, parsing the output of a tiled level editor (cha-ching for Mobius), and much more. This was helpful, not only for the added functionality, but because in order to do some of these tasks, we had to dive deep into the library we were using which meant we were learning more about the environment we were working in. Information is usually good and it paid off for Mobius.

Warm Up – The week or two before the competition, I spent time creating a platform game with a single level using the library extensions we created. This ended up being very useful for multiple reasons. It had helped me figure out the gaping holes in the extensions we created, the same extensions that were using to create Mobius, it helped me further learn more about the game library we were using, and it help me learn about some collision quirks and issues that I would have otherwise spent time figuring out during Mobius. This may have been the most important benefit as some of these issues took me quite awhile to resolve and if I had try to figure it out during Mobius, it is possible the mechanics would not have been done in time.

Play Testing – +1 +1 +1 +1 +1!!! This helped out so much! We were lucky to have a few friends come over and try out our game in the various stages while we were working on it. I’m sure most fellow Ludumdarers would agree that it is incredibly difficult to judge aspects of your own game. Is the game fun? Was it easy to learn? Was this level as tricky as and fun as it is thought to be? These are hard questions to answer when you know the complete ins and outs of the game. So we had our friends play our game and they would tell us when they felt a specific gameplay mechanic felt odd or how easy/hard they felt a level was. This may have been the most valuable thing we did during this Ludumdare and I could not recommend enough that others do the same.

Dedicated Time for Level Design – For this Ludumdare, we allotted a set amount of time to be dedicated to level design. This was quite a bit different than our previous Ludumdare game where we were desperately still coding on Monday and spent the hour or two before the deadline creating levels. It turns out that level design is just as important as the game itself. In my opinion it is better to have less features and better levels then have a ton of features but the levels are terrible and not fun. We put aside time on Sunday to create levels for Mobius that friends were able to play and we dedicated most of Monday to creating and ordering the levels that we have created.

Managing Features – Managing what would be in the game ended up being an incredibly valuable tool while actually creating the game. We came up with a ton of ideas for Mobius during the competition and we would have loved to be able to incorporate all of the ideas, but there simply isn’t the time. Prioritizing what should be in the game versus what we would like to be in the game helped us push out a better product. We have a whiteboard where we worked and on that board was two lists. One list was all of the ideas that would be totally awesome to be in the game, and the other list was the items that had to be in the game in order for it to be ‘complete’. This helped keep things in perspective as we were dealing out tasks to be completed. Not every, or even most, of the items in the ‘nice to have’ list made it into the game, but some did and absolutely every item in the ‘must have’ list made it and it shows.


What went wrong?

Ordering of Levels – It’s interesting that I place play testing in the ‘What Went Right?’ category when I feel like we didn’t have our levels is an appropriate order by the end of the Ludumdare event and this is certainly an issue more play testing would have helped solved. The play testing we did do certainly did help us order our initial levels however there weren’t any friends available to help us out for the levels created on Monday (stupid jobs!).

Communication – There were certainly some communication issues with how each of us envisioned the game or at least how I envision the game differed from how my two partners did. It’s probably my fault, I’m sure I misunderstood them but regardless the original mechanic created Friday night for the game ended up being very different than how my partners envisioned it. This cost us some time as I had to change the mechanic on Saturday to match how the game was envisioned to be played.



Overall Mobius was an incredibly positive experience. Not only was the game much more complete than our previous Ludumdate event, I feel that it is genuinely a solid concept and a great game for a 72 hour competition. It’s my personal goal that Mobius should beat our previous Ludumdare game in the overall category and I think we will succeed. I learned a lot from creating this game and look forward to the next Ludumdare where I hope we will do even better.

[cache: storing page]