{"assets":[],"author_link":"author\/netguy204\/","author_name":"netguy204","cat":"LD #23","categories":["LD #23"],"comments":[],"epoch":1335415440,"event":"LD23","likes":7,"metadata":{"p_key":"78143","p_author":"netguy204","p_authorkey":"0","p_urlkey":"287152","p_title":"Little Mischief Makers: The Post-Mortem","p_cat":"LD #23","p_event":"LD23","p_time":"1335415440","p_likes":"7","p_comments":"0","p_status":"WAYBACK","us_key":null,"us_name":null,"us_username":null,"event_start":"1334880000","event_key":"10","event_name":"LD23"},"source_url":"2012\/04\/26\/little-mischief-makers-the-post-mortem\/","text":"

I made a game in 48 hours! And I even like it!<\/p>\n

http:\/\/www.ludumdare.com\/compo\/ludum-dare-23\/?action=preview&uid=5044<\/a><\/p>\n

\"\"<\/a><\/p>\n

I started preparing for this LD with the release of @mcfunkypant\u2019s\u00a0book \u201cThe Game Jam Survival Guide.\u201d I had been wanting to enter the\u00a0LD48 contest ever since I first heard about it 2 years ago, but the\u00a0survival guide is what finally gave me the confidence to try.<\/p>\n

Code preparations began a week before with the warmup contest. The 1 week deadline helped keep me motivated as I put together the\u00a0library of important basic functions that I knew I would need. I had\u00a0decided by this point to do a pixelated platformer because I felt like\u00a0that was comfortably within my skill level to accomplish in the\u00a0time. I used the warmup time to hash out rect-vs-rect collisions,\u00a0some really basic spring\/damper physics, and a set of map loading and\u00a0rendering utilities. This brings us to the first major thing that went\u00a0right<\/em>\u2026<\/p>\n

What went right<\/strong><\/p>\n

Using Bitmaps as Levels<\/span><\/p>\n

\"\"<\/a><\/p>\n

In previous projects I\u2019ve lost many hours of game coding because I attempted to create \u201cthe perfect level editor.\u201d Inevitably the process takes longer than I had expected, and my final product does far less than I had hoped. This\u00a0time, I was inspired by a friend of mine (who was inspired by Notch)\u00a0to just use the pixel data in an image as the map. Brilliant! This\u00a0means that I can take full advantage of my graphics software to make\u00a0rectangles and circles and rotations and flood fills\u2026 all those\u00a0things that I\u2019d never have time to implement in a homebrew map\u00a0editor. Then my game loads this image and translates each pixel of the\u00a0image into a tile in the world. It recognizes certain colors as being\u00a0tiles with certain properties (non-destructable, collidable,\u00a0non-collidable) and, if it reads a pixel it doesn\u2019t recognize as a\u00a0particular kind of block, it generates a slightly noised-up tile of the\u00a0same color and gives it some default properties. This technique slayed\u00a0the level-editing-dragon that has conquered me many times before.<\/p>\n

Choosing an Art and Game Style in Advance<\/span><\/p>\n

Two weeks in advance of the theme being announced I knew that I would\u00a0be creating a pixelated platformer. Having those additional\u00a0constraints in place really helped focus my thinking once the theme\u00a0\u201cTiny World\u201d was announced. Making the decision to make a platformer\u00a0style game early also let me write the necessary collision, spriting,\u00a0and map loading\/drawing code before the contest began.<\/p>\n

Being Ready with my Tools<\/span><\/p>\n

I devoted some pre-compo time to setting up a reasonably efficient\u00a0Clojurescript development workflow. I used cljs-build to monitor and\u00a0continuously re-compile my source as I changed it so I could very\u00a0quickly hop back and forth between emacs and the browser to see the\u00a0effects of my changes. I hacked my resource fetching code so that it\u00a0would keep the browser from caching anything while I was coding. I\u00a0even decided in advance that my nominal sprite\/tile size would be\u00a016\u00d716 pixels, and I figured out an appropriate scale to apply so that\u00a0the game would have the retro-pixelated look I was going for.<\/p>\n

Throwing Away My Early Ideas<\/span><\/p>\n

To quote Chevy Ray Johnston in \u201cThe Game Jam Survival Guide\u201d: \u201cA\u00a0great way to come up with an idea to fit the theme is to write down\u00a0the first five things that come to mind, then toss \u2019em. Those are the\u00a0ideas everybody else is already thinking of and\/or making.\u201d<\/p>\n

\"\"<\/a><\/p>\n

When the theme was announced I immediately starting doodling gameplay\u00a0ideas on my handy pile of scratch-paper. My first idea was a game centered around some kind\u00a0of proto-plasmic hero that collects nutrients and waste and\u00a0transports them around a human body. I\u2019ve now seen a few game entries that are similar to this idea, and I would have been pretty disappointed to write a duplicate game.<\/p>\n

\"\"<\/a><\/p>\n

My next idea was some kind of RTS \/ resource management game where you\u00a0lay out the major components and the transport systems within a\u00a0cell. I wasn\u2019t able to find the spark in that idea that would make me\u00a0confident that the game would be fun. After this idea, I also rejected another idea due to its\u00a0potential art scope.<\/p>\n

\"\"<\/a><\/p>\n

After looking up \u201ctiny\u201d in a thesaurus, I came across the word\u00a0\u201celfin\u201d and its synonyms: \u201csprightly, playful, rascally.\u201d Thus was born\u00a0the idea for a game about the little people who are always stealing my\u00a0keys. As I was telling my wife about the idea, she suggested the\u00a0collecting-and-stacking mechanic that ended up being central to the\u00a0game.<\/p>\n

\"\"<\/a><\/p>\n

What went wrong<\/strong><\/p>\n

Insisting on \u201crealistic\u201d physics<\/span><\/p>\n

The number one complaint I\u2019ve received from players is the\u00a0sluggishness of the controls. You see, I fell for the classic blunder of having the keyboard apply forces instead of velocities to the\u00a0character. It\u2019s my own fault. I even got that feedback from friends that I\u00a0asked to play the game after the first day of the contest. I responded to their feedback by\u00a0increasing gravity, increasing drag, and applying stronger\u00a0forces due to keypresses. This improved the feel, but it seems that any\u00a0perceptible\u00a0acceleration time translates to the player\u2019s mind as\u00a0\u201csloshy, unresponsive controls.\u201d Never-mind that that is the way it\u00a0works in real life\u2026 sometimes reality just isn\u2019t real enough for\u00a0video games.<\/p>\n

Not fully rewarding the player<\/span><\/p>\n

In my game, you race a timer and collect keys (while doing general\u00a0damage to some poor sap\u2019s house). I scored the player both on keys\u00a0collected and damage done but emphasized the importance of keys by\u00a0giving the player an implicit goal (e.g., \u201cYou found 8 of 12!\u201d) However, I\u00a0failed to reward the player for achieving my implicit goal! Sadly, it\u00a0never crossed my mind that players would want some gratification\u00a0for getting all 12 keys. It\u2019s obvious now. It should be one of the\u00a0commandments of game-creation\u2013look for ways to reward the\u00a0player. You can never reward them too much.<\/p>\n

Unclear instructions<\/span><\/p>\n

I had to watch new testers play my game in person before I realized\u00a0how unintuitive my animated instruction screen was. The problems are clear to me now: I have arrows representing arrow keys, but they don\u2019t really look\u00a0like keys; \u00a0I have \u201cSPACE\u201d written on a horizontal blob with the player\u2019s character sitting next to a tool, but that doesn\u2019t really\u00a0communicate \u201chit space to use your active tool\u201d like I had hoped. The instruction screen came late in my development process and after I had already\u00a0used up my available fresh-to-the-game testers. I should have opted\u00a0for simple text to explain the controls instead.<\/p>\n

Concluding Remarks<\/strong><\/p>\n

My final tool stack was:<\/span><\/p>\n