About netguy204 (twitter: @netguy204)
Ludum Dare 28
Ludum Dare 27
Ludum Dare 26
Ludum Dare 23
I’m now working to polish my game “Life of a Photon”. If anyone has some spare cycles for playtesting and tips, I’d love your input. Leave notes in the comments. My big questions:
- Is your purpose clear?
- Can you make progress towards that purpose?
- Is it fun?
My game “Life of a Photon” is taking shape. Did you know that a photon will travel 1.8 million miles in 10 seconds? That sounds like plenty of room for a game.
Press “Z” is simple. You’re a square and ever-increasing waves of rectangles are assaulting your position. Smash them by pressing and releasing the “Z” button.
This is the first game I’ve made that really centered around and focused on a single mechanic. All you can do is jump. But, strangely, reasonably interesting game-play emerges from that simplicity.
For example: The enemy rectangles can push you around as you try to squash them and if you get to the edge of the screen, you’ll die. Since all you can do is jump (you can’t directly control your drift towards the screen edges) you occasionally have to sacrifice some health so that a rectangle can push you back in the direction you want to go. This health/position tradeoff becomes increasingly important as the speed of the enemies increases.
My frequent co-conspirator Chris Wellons suggested adding a camera shake to emphasize the weight of the player. That simple camera shake and the enemy “pop” particle system really make the game feel solid and crunchy in spite of the simple graphics.
The game does lack “spice”. All that happens as you progress is that the enemies come increasingly faster. This, as shown above, leads to interesting game-play but it also starts to feel repetitive. Introducing more enemy types as the player progresses would help with this. Those new enemy types should also force the player into interesting choices. For example, I could add a flying enemy type that has the potential to block your jumps which would force you to make a tradeoff between taking damage in your jump or taking damage from the enemy that you were jumping to crush (or scheming to avoid both.)
I’m glad I didn’t spend any time on graphics during the compo but I’ve had a little time to experiment post-compo and I think that enemy animations and graphics can also serve to provide some of the missing “spice”.
Press “Z” wasn’t the game I started the contest with. My first game was a word association game that would ask the player to convert a given sentence into a goal sentence by replacing words with related words from a list. The theme “minimalism” would be captured with a strong contrasting aesthetic and clean typography. It sounded interesting in the planning stages but the prototype (that I spent most of Saturday building) turned out to be terribly boring.
Sunday I began again. This time “minimalism” meant “cut to the essence”. I was thinking about platformers and boss fights and thought it would be interesting to build a platformer that was only about the boss fight. As I was discussing the idea with my wife, we began talking about how the boss-fight would unfold and how the player would deal damage. I used “jumping on their heads” as an example. That got me thinking that a single button game about jumping on things’ heads might be fun.
I was able to prototype the fundamental jump-n-crunch in about 30 minutes. Even though the fundamental parameters (enemy speed, jump height, control loop) made it to the final version unchanged, this prototype also wasn’t fun. The crushing didn’t feel good. It wasn’t satisfying. I added a particle system and it felt a lot better. Then, I felt good enough about the prototype to show it to Chris. He suggested the camera shake and suddenly the game felt fun. I was surprised that pure aesthetics could take a game from dull to enjoyable.
What Went Well
- I picked a simple mechanic and built a game around it.
- The game isn’t content driven so I don’t have to make a ton of levels.
- The game _feels_ good and crunchy.
- Mac / Linux / Windows release process went smoothly
What Went Poorly
- Focus. The entirety of LD26 (including the failure) received about 10 hours. I had other duties to attend to for the rest of the weekend.
- The game loses novelty after a few levels. Needs some unique content introduced over time to “spice” things up.
- A minority of Windows users reported difficulties starting the game.
This Ludum Dare was a wonderful experience and I want to participate again next time.
Play and rate my game if you’re interested!
I’m in for LD26!
Ah, it feels good to get that off my chest. Greetings fellow LD jammers! It’s a privilege to be in your company again. LD23 was the last LD I was able to enter. Since then, I became a father and life got way less predictable (but also quite fun!) Now things have stabilized enough for me to participate again.
Last time my kit was HTML5 and ClojureScript and they served me well. But, I’ve been developing for the Ouya lately so I’ve built some new tools that I’m enjoying.
I’ll be using my new in-house engine GGL (pronounced “Giggle”.) Follow the link to download the mac/windows/linux version of my warmup game “trucker” along with the source.
In more detail, this year my kit is:
- C++ and Lua (via my GGL engine)
- OpenGL (again via GGL)
- Box2D (via GGL)
- Spriter (which GGL supports)
- Cfxr and my mic on sound fx
Last year I built a pixelated platformer. This year I’m planning to design something more action flavored and probably from a top-down perspective. I’ll be confining myself to a restricted palette because I’m not much of an artist.
I’m looking forward to seeing what everyone creates! Best of luck!
I made a game in 48 hours! And I even like it!
I started preparing for this LD with the release of @mcfunkypant’s book “The Game Jam Survival Guide.” I had been wanting to enter the LD48 contest ever since I first heard about it 2 years ago, but the survival guide is what finally gave me the confidence to try.
Code preparations began a week before with the warmup contest. The 1 week deadline helped keep me motivated as I put together the library of important basic functions that I knew I would need. I had decided by this point to do a pixelated platformer because I felt like that was comfortably within my skill level to accomplish in the time. I used the warmup time to hash out rect-vs-rect collisions, some really basic spring/damper physics, and a set of map loading and rendering utilities. This brings us to the first major thing that went right…
What went right
Using Bitmaps as Levels
In previous projects I’ve lost many hours of game coding because I attempted to create “the perfect level editor.” Inevitably the process takes longer than I had expected, and my final product does far less than I had hoped. This time, I was inspired by a friend of mine (who was inspired by Notch) to just use the pixel data in an image as the map. Brilliant! This means that I can take full advantage of my graphics software to make rectangles and circles and rotations and flood fills… all those things that I’d never have time to implement in a homebrew map editor. Then my game loads this image and translates each pixel of the image into a tile in the world. It recognizes certain colors as being tiles with certain properties (non-destructable, collidable, non-collidable) and, if it reads a pixel it doesn’t recognize as a particular kind of block, it generates a slightly noised-up tile of the same color and gives it some default properties. This technique slayed the level-editing-dragon that has conquered me many times before.
Choosing an Art and Game Style in Advance
Two weeks in advance of the theme being announced I knew that I would be creating a pixelated platformer. Having those additional constraints in place really helped focus my thinking once the theme “Tiny World” was announced. Making the decision to make a platformer style game early also let me write the necessary collision, spriting, and map loading/drawing code before the contest began.
Being Ready with my Tools
I devoted some pre-compo time to setting up a reasonably efficient Clojurescript development workflow. I used cljs-build to monitor and continuously re-compile my source as I changed it so I could very quickly hop back and forth between emacs and the browser to see the effects of my changes. I hacked my resource fetching code so that it would keep the browser from caching anything while I was coding. I even decided in advance that my nominal sprite/tile size would be 16×16 pixels, and I figured out an appropriate scale to apply so that the game would have the retro-pixelated look I was going for.
Throwing Away My Early Ideas
To quote Chevy Ray Johnston in “The Game Jam Survival Guide”: “A great way to come up with an idea to fit the theme is to write down the first five things that come to mind, then toss ‘em. Those are the ideas everybody else is already thinking of and/or making.”
When the theme was announced I immediately starting doodling gameplay ideas on my handy pile of scratch-paper. My first idea was a game centered around some kind of proto-plasmic hero that collects nutrients and waste and transports them around a human body. I’ve now seen a few game entries that are similar to this idea, and I would have been pretty disappointed to write a duplicate game.
My next idea was some kind of RTS / resource management game where you lay out the major components and the transport systems within a cell. I wasn’t able to find the spark in that idea that would make me confident that the game would be fun. After this idea, I also rejected another idea due to its potential art scope.
After looking up “tiny” in a thesaurus, I came across the word “elfin” and its synonyms: “sprightly, playful, rascally.” Thus was born the idea for a game about the little people who are always stealing my keys. As I was telling my wife about the idea, she suggested the collecting-and-stacking mechanic that ended up being central to the game.
What went wrong
Insisting on “realistic” physics
The number one complaint I’ve received from players is the sluggishness of the controls. You see, I fell for the classic blunder of having the keyboard apply forces instead of velocities to the character. It’s my own fault. I even got that feedback from friends that I asked to play the game after the first day of the contest. I responded to their feedback by increasing gravity, increasing drag, and applying stronger forces due to keypresses. This improved the feel, but it seems that any perceptible acceleration time translates to the player’s mind as “sloshy, unresponsive controls.” Never-mind that that is the way it works in real life… sometimes reality just isn’t real enough for video games.
Not fully rewarding the player
In my game, you race a timer and collect keys (while doing general damage to some poor sap’s house). I scored the player both on keys collected and damage done but emphasized the importance of keys by giving the player an implicit goal (e.g., “You found 8 of 12!”) However, I failed to reward the player for achieving my implicit goal! Sadly, it never crossed my mind that players would want some gratification for getting all 12 keys. It’s obvious now. It should be one of the commandments of game-creation–look for ways to reward the player. You can never reward them too much.
I had to watch new testers play my game in person before I realized how unintuitive my animated instruction screen was. The problems are clear to me now: I have arrows representing arrow keys, but they don’t really look like keys; I have “SPACE” written on a horizontal blob with the player’s character sitting next to a tool, but that doesn’t really communicate “hit space to use your active tool” like I had hoped. The instruction screen came late in my development process and after I had already used up my available fresh-to-the-game testers. I should have opted for simple text to explain the controls instead.
My final tool stack was:
- Clojurescript: [https://github.com/clojure/clojurescript]
- cljs-build: [https://github.com/emezeske/lein-cljsbuild]
- zynga/jukebox: [https://github.com/zynga/jukebox]
- Garage Band (iPad)
- Paper and a blue ball point pen
- Trello (to organize my thoughts): [http://www.trello.com]
- A very reasonable amount of sleep
Things I produced:
- My Game: http://50ply.com/ld23/
- My Timelapse
- This postmortem
- A new personal confidence that I can actually create fun games!
Ludum Dare 23 was a fantastic experience. I’m proud to say that I succeeded in my ultimate goal of making a game that I actually enjoy playing. Now I’m continuing to learn as the very talented LD community members evaluate my game and offer suggestions.
I’m coming to the end of today’s coding spree and I’m quite pleased with the results so far! You can play it here: http://50ply.com/ld23/
You’re the reason that one sock is always missing and no one can ever find the keys. Pick up tools, steal keys, mess stuff up!
Whew. I’m glad I had time this weekend to kick the tires! Again, my stack:
- http://github.com/netguy204/showoff-cljs (Clojurescript game library I’m putting together)
- http://github.com/zynga/jukebox for sound
- Photoshop, Garageband, Audacity
I met a lot of the goals I had set for my tool development this weekend:
- Reasonable collision physics
- Map data stored as a color coded png
- Entity protocol
I missed a few goals too:
- No text display
- No interactive objects
- No menus
I’m really glad I did this warmup. I feel much more prepared for next weekend. See you all then!
I’m in for LD23!
Im planning on making a pixel art platformer of some kind. This weekend I’m making sure my asset pipeline makes sense. My stack:
- My fledgling cljs gamelib “showoff”
My goal is to guide traffic from the Chrome web store through my game to my new iPhone application Go Time that will be available at the end of the month. I’m not sure how I’ll quantify success in the contest–but hopefully the cross promotion will do some good.