About CJ K (twitter: @cjkimberlin)

C.J. Kimberlin is a Seattleite professional programmer, aspiring game designer, amateur artist, and the most awesome guy ever, just saying.


Ludum Dare 32
Ludum Dare 30

CJ K's Trophies

"Cream of the Crop" - LD32
Awarded by Dreyan
on May 12, 2015

CJ K's Archive

Free open source 2D Platformer Controller for Unity

Posted by (twitter: @cjkimberlin)
Sunday, December 6th, 2015 4:47 pm


Hey all! Since available tools are allowed to be used I wanted to share my 2D Platformer Package that you can use for Unity!

GitHub Link

Right from the start you can have a character running, jumping, dashing, wall jumping and catching onto corners. Works with slopes and moving platforms too! Time is valuable in Ludum Dare, don’t waste it reinventing the wheel (unless ya want to learn how to :p).

Sharing PC2D: A 2D Platformer Controller for Unity3D

Posted by (twitter: @cjkimberlin)
Monday, August 3rd, 2015 5:57 pm

Hey fellow Ludumdarers,

48 (or 72 hours) isn’t a lot of time to implement your game! Since time is the most valuable resource, anything that helps save it is incredibly beneficial. To help others save time (and build better games!) I wanted to share a free open source 2D platformer controller that I have been building up for Unity3D.



PC2D GitHub Page

With PC2D your characters can run around, jump off of walls, and dash within minutes! Corner grabs? Slopes? Moving platforms? One way platforms? No problem!

To see it in action, my previous LD entry was built using the Controller.


Play Beep Boop

Hopefully this will be of use for others!


Beep Boop Postmortem

Posted by (twitter: @cjkimberlin)
Tuesday, April 28th, 2015 2:59 pm

I had to skip the last one but this time around I was able to participate in Ludum Dare again! My last entry did pretty well so trying top it was going to be challenge. Since I’ve been building up my skill as a game designer, I decided to focus heavily on something that has plagued me in almost every game I’ve made. Level Design, pacing, and the difficulty curve.

Play Beep Boop

What went right?


Execution for Beep Boop had to be simple. Not only because I was working on it solo for a game jam, but if my goal was to work on level design then that’s what I needed to spend most of my time doing. I leveraged every trick I could to make sure the scope of the project was achievable. I used my Platformer Controller package, kept what the player would do simple, kept the challenges simple, and used a very basic (but pleasing) aesthetic. And of course, most importantly, planned everything up front on paper.

2015-04-17 19.26.50

The result of this careful planning? Everything went smooth and I finish at around noon on Monday instead of hectically working until the last moment. Why Monday instead of Sunday when I worked solo? Well, I wanted to leverage some feedback from a playtest Sunday night.


I can’t stress enough how important playtesting is for any game. When you build a game as a designer you are working off of assumptions. With enough experience these assumptions are probably pretty good, but when you’re learning then these assumptions are often wrong. With playtesting you can identify the incorrect assumptions and correct them.

It can be hard to find time and people to run playtesting during a Ludum Dare but if you can then it’ll be incredibly valuable. I had three different playtesting sessions throughout the weekend, each allowed me to improve my design and create a better experience.

Level Design

My goal of focusing on level design, pacing, and the difficulty curve paid off. This is probably my best game in terms of balance and discoverability. I made an effort to tell the player as little as possible, with the exception of what buttons did what, and allow them to figure it themselves (with hints from the level design). Players far enjoy figuring out what to do rather than being told.


What went wrong?

Level Design

WTF?! Didn’t I just have this in the “What went right?” category? While my level design efforts did go very well, it wasn’t perfect. Looking at the analytics a few days after I published Beep Boop, I noticed a glaring issue; the deaths for one of the checkpoint sections was significantly higher than the others. It also happens to be the section that I lose most my players.

chart_1 (1)

While the difficulty curve should keep going up (on average), the failure curve should be roughly flat for this type of game. This is because the player’s ability at the game is growing along with the increasing challenge. The spike in deaths in the above graph shows that one of my areas is significantly too difficult for the player and should be reworked. Continuing to look at the graph, the final area is probably a little bit too easy.

Other analytics tell me which screens the players struggle with the most. These happen to the screens that I changed after my final play test. Coincidence?

Forward Thinking

For a project that I wanted to focus on level design, I sure made it hard on myself. My approach to building the area system was not at all modular. While I could tweak what was in any given screen, it was a major pain to change the ordering of screens or even remove a screen altogether. This ended up being very limiting in controlling and tweaking the pacing and flow of the game.

Screenshot 2015-04-28 12.40.05

It’s hard to blame myself too much on this. I only had a few hours to build the system and went with what first came to mind. For future projects I’ll definitely have to keep this in mind.

An Unconventional…Weapon?

People seem to praise my use of the theme in their posts. I have a hard time buying it as there are no enemies to fight. Is it a weapon if you have nothing to fight?



I think the design behind checkpoints is fascinating and after reading all the comments left by people, it would seem that it is a bad design idea to have spaced out checkpoints.


Is it frustrating to have to redo an area you’ve already done? Absolutely. So is the correct answer just to checkpoint at every screen so you don’t have to? Well, not necessarily.

When designing a game, I find myself trying to remove the frustrations of my players while building on to the positive experiences they have. Having spaced out checkpoints definitely adds to the list of frustrations by forcing players to redo challenges, but it also add two very valuable positives that aren’t immediately obvious.

For a slightly twitchier platformer, I expect the player to need to master the mechanics to use later on. By requiring the player to redo sections when they die, I ensure they get the practice they’ll need for future areas. I can leverage this in my design and assume the player has had the practice they need in order to have a positive experience with future levels.

The second positive spaced out checkpoints give the players is perhaps more important. It feels damn good to reach a checkpoint. As a player progresses through a checkpoint section, the tension increases with the cost of failure should they have to restart. Hitting that next checkpoint relieves all that tension and feels fantastic. Chasing these experiences as a designer should not be ignored.

Does this mean all the feedback I received about the checkpoints are incorrect or unfounded? No, but rather than the obvious solution of checkpointing every screen, I believe it means that my balance is wrong for some sections (again, see graph above).

Not All Playtest is Useful

The reason I enjoy making games so much is that I get so happy when I see other people enjoy themselves when they play my game. Best. Feeling. Ever. I also cringe so hard when I see people struggle. I want everyone to enjoy my game, I don’t want to leave anyone out.

But this isn’t realistic. You’re not going to be able to capture everyone with your game. Improving the experience for one group of your audience can diminish the experience for another group. During playtests you have to be careful to ensure the data you are gathering is from your target audience or is otherwise less useful.

I went to a post Ludum Dare show and tell Monday night and had quite a few people play my game. I’d cringed every time I saw someone struggle and not have fun with my game. I wanted them to enjoy themselves. It sucked that they didn’t. They’d tell me that it looked like I did a great job but they don’t really like platformers and move on. Then someone else would come, groove the game’s pace, and have fun. They’d say that they love platformers and thought this was fantastic.

Does that mean I succeeded?

Unity 2D Platformer Controller Free on Github

Posted by (twitter: @cjkimberlin)
Wednesday, April 15th, 2015 10:58 am

Hey everyone!

I wanted to share the 2D Platformer Controller  I’ve been building up for awhile now. It’s a Unity3D package that you can drop in your scene to get immediate tweakable platforming mechanics for a player. It’s completely within the rules of Ludumdare and now you can spend your time implementing other mechanics instead of creating all the movement and jumping mechanics for the player.

Unity 2D Platformer Controller

The package allows your standard movement, jumping, air jumps, wall jumps, corner grabs, corner jumps, wall slides, and dashes. Every one of these features can be turned off or modified in the editor.

It’s open source and completely free. Why reinvent the wheel? Especially when you only have 48/72 hours!


100 Days Postmortem

Posted by (twitter: @cjkimberlin)
Monday, September 15th, 2014 11:16 am

Ludum Dare is awesome. A welcomed challenge every four months. In order to improve my skill at design, I spend most of my time creating simple prototypes to learn what does and doesn’t work. This has benefitted me immensely and I remained convinced that it is the right route to becoming a better designer. The downside to this practice is that I don’t have much to show for it. Raw prototypes don’t show off very well. However, Ludum Dare gives me the opportunity to release a game, even if it’s a short web game. It’s nice to be able to show people something with a little bit more polish to it.

For Ludum Dare 30 I created 100 Days. You are the EAS Indomitable, the first human vessel to explore deep space. Disaster strikes and you must survive for 100 Days before home base can warp the Indomitable back to safety.

100 Days Entry

What went right?


When the theme was released at 6pm I did not go anywhere near a computer. Since I have been making it a habit to design on paper every detail that will be in my prototypes, I didn’t see why I should do it any different for a LD game. Especially given the short time limit, I wanted every aspect of the game thought out upfront. If I missed some detail then I would consider that a failure. Before touching a computer I had the actions listed, the resources that would be used, the costs of moves, combat details, and even had drawn what I wanted the UI to look like. Because of this upfront effort, there were less surprises and I had a pretty good idea of what needed to be done by when.




Though knowing when features needed to be done didn’t mean they would be done in time. I also executed the features in scope efficiently. As a programmer, it’s really easy to get caught up in doing things the “right” way. Spending the extra time to make sure architect is clean or making sure the code runs as optimally as possible. KISS: Keep it simple stupid, especially for a game jam. The gains you get by doing it “correct” is not often worth the time spent.

The world generation for 100 Days is hardly optimal or even elegant. In a 200×200 space, random worlds are created based off of a probability curve which decreases the further away from the origin. Then another pass marks worlds that are connected to the origin world. Yet another pass will then walk from each world that isn’t connected to the origin and walk towards the origin until it hits a world that is connected. To make sure that the player can traverse at any depth a circle of worlds is created every 10 nodes. Finally, to keep options open for the player, random worlds are selected and additional worlds are generated walking away from the selected world.




Now I have very little experience with procedural generation. I do not know any common practices, algorithms, or techniques. My approach to the world generation was simply the most obvious option that came to me. I am absolutely sure that there are far more calculations than necessary, probably even redundant calculations, but I do not care. I had the entire world generation code completed before I went to the bed on the first night. A huge part of what I needed in the game, completed in a few hours. The negative impact of my straight forward obvious approach? 2.5 seconds. According to my analytics, the average load time for users was 2.5 seconds before they can play the game. I can live with that. To further drive this point, the AI uses limited DFS to find the player. I didn’t even attempt to use a heuristic which would not have been hard since I know where the player is. I didn’t need to. The game ran at 60 fps with the simple searching.

Though more than just programming features contribute to scope. Content is expensive. It takes time to build a diverse world, write an interesting script, or to have a wide variety of challenges. That’s not to say focusing on any of these for a Ludum Dare is a bad idea. We all want these things for our games, but it’s easy to forget or underestimate just how costly content can be. 100 Days was kept purposefully simple. The story was brief, only a few enemies and they all behaved the same way, and no sprite animations were created. Keeping an eye on how much content I’d have kept creating 100 Days in 48 hours possible.

Time Management

I see a lot of people who sleep little or none at all and work themselves past the point of exhaustion. This is not the way to handle a Ludum Dare. I understand why this happens, you only have two or three days to complete a game. Time is precious and you have very little of it. It’s easy to think that you need to spend more and more hours to complete your entry. I’d argue that doing this hurts your output and you can get more quality work completed by spending less time working on it. I make sure to get a full night’s rest every night, I regularly take breaks, and I’ll try to make sure I have a wind down period where I’ll do something else before going to bed. The thing is if I’m tired I’ll make mistakes. If I make mistakes I’ll get frustrated. If I’m frustrated then I’ll make more mistakes. The worst of it is if I’m frustrated then I’m not having fun. If I’m not having fun then I don’t want to participate. Sleeping and taking breaks both improved my output and made the whole competition more enjoyable.


In my opinion polish is the single most important aspect of a Ludum Dare game, in terms of being judged. I have seen otherwise uninteresting games receive high praise because of how polished the entry was. This isn’t really surprising. When most players only spend a few minutes on an entry it’s critical to leave an immediate impression and that’s where polish shines.

However, polish isn’t free and takes time to do. So it’s important to pick your polish battles carefully and even more important to pick your tools carefully. Leveraging cheap polish techniques can make your game feel much more complete without a huge time cost. For 100 Days I heavily leveraged tweening. For everything from moving, combat, to zooming the camera. Carefully picking an easing function for your tween can give your animations more flavor and improve the general feel of the game. Particle emitters are another great tool for creating quick and effective polish. In 100 Days the engines and explosions were created using very simple particle emitters.





What went wrong?


This is problem that just continues to haunt me and it reared its ugly head for 100 Days. It’s a goal of mine to make the interaction with the game intuitive enough to not require a separate tutorial screen. As a player I am annoyed when its necessary for me to look at instructions outside the actual game itself. To combat against needing a screen outside of the game, I implemented a help section in the UI that prompted text when the player hovered over an object. However, that only works if players realizes it is there and understood how to make use of it. Some noticed and figured it out, others didn’t. Those who didn’t struggled to grasp the resource aspect of the game leading to a degraded experience.




To improve on the understandability of my games, I think using more assets to be as clear as possible about how the interactions with the game works. I didn’t want the player to learn that they die if their fuel hits zero. I wanted the player to learn how to prevent their fuel from reaching zero. Using simple art assets to clearly show the next valid movements or larger icons for resources on planets can go far for understandability. It may not be elegant, but having a prompt that the player must click through that explicitly stated that additional help text is supplied on hovering could have made 100 Days much more approachable.

Grammar / Typos

This one is pretty embarrassing. The typos I really have no excuse for. The grammar I can at least claim ignorance, for what that’s worth. Luckily the typos are an easy fix that really comes at no cost. I need to write all my content in a proper word processor that can detect misspelled words. Easy. Grammar is trickier but a problem I want to solve. Writing more and having people proofread will help me with grammar. This postmortem has an excellent exercise on its own, and yes, I have a friend who has been proofreading it for me. Though he didn’t have time to check out this final version, so we’ll see how it goes.


This probably seems like an odd entry for a Ludum Dare postmortem but it’s certainly an area I came up short. Earlier in this postmortem I wrote, in great length, about implementation efficiency and time management. So why would I even be concerned about adding analytics to my game when it takes time? Because information is power. A big reason I participate in Ludum Dare is that it gives me a chance to try new ideas and when I try out an idea I want to learn from it. Analytics is another tool to help with learning about your game’s successes and failures. Anything that helps me learn is worth my time.

However, analytics only helps you learn if you gather actionable data, with actionable being the key word. I didn’t really have a plan when I started placing analytics into 100 Days. I basically decided to record as much as I could and hope that it was useful later. Some of the analytics worked out alright, as I mentioned earlier it took an average of 2.5 seconds for players to load my game. That was useful to know because it justified my decision to not optimize the world generator. But most of the data didn’t help me out in the end. Knowing that over 2000 extractions have occurred in my game is cool but not useful. What would have been useful? Analytics around the user experience. How long did it take before the player hovered over an item to read the help text? How often did the player do it? I knew fuel was the most important resource to manage, how many attempts did it take for players to learn this? Hindsight makes it easy, but these were the important questions.

My whole approach on how to add analytics to a game needs to change. Much like designing, this is going to require me to step away from the computer and truly think about. I need to sit down and ask myself what is it that I really want to know? And if I can learn the answer, what can I do about it? Once I have the questions that lead to actionable answers, I can start figuring out what data would help me answer the questions. As good analytics can help me improve everywhere, doing this correctly is perhaps the most important thing I can take away from this Ludum Dare.

Universal Analytics for Unity 3D

Posted by (twitter: @cjkimberlin)
Thursday, August 7th, 2014 4:26 pm

Hey! Remember that one Ludum Dare where you had lots of extra time and you wish you had a way to gather information about players who are currently playing your game? Ok, maybe not, especially on the time part ;).

Well I’ve just created* a logging interface to Google’s Universal Analytics for Unity3D that is quick and easy to use (and 100% free). With this you can learn more about players who played your LD game! How long did they spend at each level? How many times did they die? How many beat the game? How far did they get? Anything you can think of!


While I doubt people will have much time during the LD to think about and set up logging, I don’t think it’s against the rules to add telemetry after the competition (it doesn’t alter gameplay) and the information can be useful to learn about what further went right or wrong.

Information is power :)!


* Like literally just created. Bugs and issues expected! Going to be using it for a different project over the next couple weeks which will hopefully iron out any super common issues.

Let’s do this!

Posted by (twitter: @cjkimberlin)
Monday, August 4th, 2014 11:52 am

Ludum Dare already right around the corner? Yea! Seems like the last one just finished!

This time I may be going at it alone! So I’ll have to shoot for the 48 hours and then fall back to the 72 hour jam once I realized that I, once again, underestimated how long it would take me to get something done (software right?).


  • Unity 3D
  • Visual Studio 2013
  • Photoshop
  • Blender (if 3D)
  • Sound generators, my weakest area :(.

If I end up making a 2D platformer of some kind then it’s likely I’ll use my previously built PlayerController2D package. Besides that I might leverage any of the assets I’ve accumulated over the past year from the Unity asset store.



[cache: storing page]