1.  Aim for completeness over detail

The games that I enjoyed the most are the ones that feel complete. By this I mean that your game feels like any other, but shorter. Definitely work hard to include audio, non-placeholder graphics, and whatever else your game needs. Think about it like you’re trying to sell your game: you can’t give out everything you have in mind, but you can demonstrate why each aspect of it is good.

2. Let the player lose

If your game is based on levels and you only have an hour to do them, you are probably going to need to cut down on your vision. A common mistake is to drop the latter half of the game, where the levels become more difficult. I am much more interested in the levels that will challenge me and that I will fail on than some hyper-detailed tutorial. Let the player struggle with the clever mechanics you had in mind. A great example of this is Increpare’s Puppy Shelter. Even if your game does not involve levels, the player is eventually going to get bored of constantly winning with ease.

3. Reward smart actions from the player

From the comments on my game, I found this lesson to be quite important: the actions that the player can perform must significantly and obviously affect their performance. It is incredibly rewarding, as a player, to, after trying your game for a few rounds (or whatever unit your game is measured in) to be getting better scores (or whatever unit success is measured in in your game). If your concept doesn’t do this, it needs to. Also, remember that just because you, the developer, can see the link between actions and responses doesn’t mean everyone else can.

4. Make the Connection to the Theme Obvious

While it’s entirely possible to go through the competition and just write some short blurb at the end that uses the theme in it once, much of the challenge in this competition is using the theme. The theme serves as a constraint that lets you explore ideas that you wouldn’t have otherwise done. You are likely to be more innovative if you set a goal of yourself to put the theme even in the game mechanic because it rules out what has been done before.

5. Ensure that the player can learn the game

This is another one of the problems that arise when you try something new for your game. Ideally, your game would be completely intuitively – people would just figure it out from clicking on stuff and pressing buttons on their keyboard and no instruction at all would be necessary. It’s unrealistic to think that every concept you think of fits that. If you need to explicitly state anything more than that your game is a platformer and that it uses WASD, you should include some sort in-game tutorial (textual doesn’t work very well. I’ve tried that twice; people need to see what is being talked about and to try it). If, for your game, players need to memorize a lot of keys to press or rules, you need to simplify your concept.

6. Be confident in your game

Please don’t belittle yourself in your description of the game. Try to make your game look good.

7. Have fun

Okay, this isn’t exactly related to the game concept, but it’s always good to remind people of the fact that their ultimate goal here is not to win, but to have fun and that all tips are there to be broken. This is a great opportunity to try out new concepts and to do cool things. You should let yourself do whatever you want. There’s no reason not to; regardless of what you do, this awesome community will give you awesome feedback on your awesome idea.

What You Should Avoid

• Texture-less, poorly lighted levels
• Ambient light being left at the default grey
• Poor usage of physics (ex: the player being the only physic object in the game)
• The default player movement setup (With the player having extreme jumping abilities and almost no gravity)
• Menu-less, single scene, test games
• Places to fall out of the world
• A default sky-box or default light blue background
• Lag
• 3D text with the default font
• Support for only 1 resolution

Little Things Some Games Have That Make ALL The Difference (AKA: What you should have)

• Lock Cursor and Pause capabilities
• Animations on items in hand
• Ragdoll physics or physics objects
• Sprinting
• Crouching
• Multiple Items to hold
• A menu
• Sound
• Options (Ex: mouse sensitivity, quality settings (to remove lag), fog distance, clipping distance, etc)
• In-game Instructions
• A good GUI (Displays health, ammo, instructions, etc) Not the default GUI skin
• Complete usage of Player Settings (Company name, logo, game name, app name, resolutions, config dialog banner, etc)

I could go on and on with this list, but you get the idea. Basically the main thing to worry about is Making it an actual game and not a “Test”. I recommend you don’t send in your “Test” to a Ludum Dare competition, unless you want to get this endless list again by play testers…

When I did LD22 I pretty much tried to focus on all the little things that made it look like a good game. Although while I’m being extremely critical about games, I have to say my entry Isolated Assault did not follow all these lists… but I got the important ones out of the way (Lock Cursor, pause, animations, physics, many resolutions support, menu, instructions………. just play the game. )

But I never said you have to follow the list exactly, just keep it in mind!

Stay critical, and I hope all of you (Just a general statement. I noticed a few Unity games stood out that actually had these) actually keep in mind the little things next time around!

I found out about this competition last year when Notch(The maker of Minecraft) entered Prelude of the Chambered, I immediately said to myself,  ”I will do this next year.” So now I did it, I entered in my first, but not last, Ludum Dare.

I was watching tv one night when something popped into my mind, the Ludum Dare. I checked the website to see when it was, two hours. I ran to my computer and started memorizing my basic -5 file- library inside and out, after an hour I was able to repeat most of it from memory and the rest, thankfully, wasn’t needed. So I waited the longest hour of my life hoping the theme would be kittens.

Once the competition finally started I cursed everyone who voted anti-kitten, opened up handy dandy Visual Studio, and got to work. I typed out what I remembered of my library only two classes, but I was able to make a bunch of edits to one to make a new class. I had lots of trouble starting and coming up with ideas for what to do, but I did the basic things, like changing the screen size and creating the controls for moving.

After an hour of sitting and thinking I had an idea, a game that is more based on story than game play, but still has game play. I sat down and started, I added in textures, added a way to shoot, and realized just how inexperienced I am when it comes to game making.

Coding was crazy, I had tons of road blocks; bugs, bugs, and more bugs. I had to go into untraveled land to create the game, and I also spent plenty of time in well worn territory. Overall my game was very fun and frustrating to make, but it was well worth it.

Now a list of what was good and what wasn’t:

Good Things:

• It was fun
• I learned a lot
• I coded in XNA which I am very comfortable in
• Everybody was very supportive of my first game
• I am happy with my work
• My coding works
• Others enjoyed my game
• The ultra great graphics game “Real Life” didn’t distract me that much

Participants of Ludum Dare 22 were asked to fill out a survey on their experience. A whopping 747 people filled out the survey.

Thanks for taking the time to fill it out!

I love this enthusiastic and supportive community.

Here are the results (click to zoom).

Survey Results: click to zoom in.

An in-depth analysis of the data will appear in the upcoming book, the Game Jam Survival Guide. Briefly, people had a lot of fun. The majority were either first-timers or not experienced game jammers. Most are happy with their games, of which about half work in a web browser. In order to finish on time many people had to cut features and simplify their designs. Not everyone was as familiar with their tools or basecode as they should have been, but only a few tried to learn a brand new engine.

Most games did not run on mobile devices, but many were cross-platform. On average most people did not spend time watching TV or movies, going outside, visiting with friends or playing other games.

Contrary to expectations, almost nobody drank coffee, energy drinks or alcohol. Virtually nobody used version control (such as SVN) or time-management techniques (such as pomodoro). Surprisingly, not many reported having difficulty with packaging, installers or submitting.

This infographic would be complemented by additional stats work. For example sorting the results by the most common response, or by questions with the most “no, not at all” answers would show some interesting trends that aren’t hinted at in this chart. Overall, however, even this cursory examination of the 747 survey results sheds some light on how Ludum Dare game jammers spend their weekends.

This weekend, your quest is to put a KITTEN somewhere in your game as an “easter egg”.

This “kitten challange” will be like a meta game in which everyone tries to find the kittens in each game they play. You know you want to.

Do it – for the love of kittens. For the love of meta. For the love of all things LD48.

Edit: Dock was cool enough to make an icon that you should put in your game title screen or game thumbnail screenshots so we know to look for your kitten:

http://www.ludumdare.com/compo/2011/12/16/1-kitten-badge/

Finally, be sure to post to the blog using the “kitten-challenge” and “easter-egg” tags.

Here are the tragic results of theme voting. Where’s the kitten love?

1. Alone+227
2. Randomly generated+206
3. Evolution+41
4. Parallel dimension+14
5. Forgotten places-29
6. Falling-77
7. Moon-105
8. Tunnels-108
9. Consequences-113
10. Decay-116
11. Dreams-118
12. Underground-125
13. Time-travel-133
14. Teleportation-148
15. Self-replication-170
16. Territory-284
17. Mechanisms-291
18. Antihero-325
19. Reflection-417
20. Shape-shifting-477
21. Kittens-481

I played them all.

And after witnessing the same “setup-choices” over and over again I decided to write this assortment of DOs and DON’Ts, which will hopefully make your game more appealing to other players and judges.

These things are important. The games who are easy to start and play get more votes, plays, word-of mouth and ultimately publicity. If a game is a puzzle in itself to start, we will have to move on, so that we at least may sample more of the (probably) 600+ games available.

//Edit – Sos created a nice complementary list with more details about engine/framework-builds. Give it a look

DO make a webbuild. If that isn’t possible, a windows-standalone is fine. Mac + Linux-versions are a nice bonus, but shouldn’t be the only versions available. While mobile-versions (iOS, android, windows-phone) are nice too, installing them is (compared to the others) a hassle and only few people have the devices and/or know how to install custom apps.

DON’T require extensive framework-tools to start your game. XNA is acceptable, as many people already have it and many games are made with it. I guess JAVA is too. The same goes for “only in browser X”-games, which require me to download/install/start an unknown program. Many people will also pass over your game if it requires and installer, or a registry-update.

DO call the executable of your game something other than “LD22.exe” or “the_theme.exe”. After a while I have 20 of these on my desktop, which makes it difficult to locate a file, should I want to play again, or give a better rating. “kitten_simulator_2″ will do.

DON’T hide the executable of your standalone in the_game/the_game_unzipped/binaries/system/system64/exe/1182772/localized/the_game.exe. The longer it takes to slog through your files, the higher the chance of me rage-quitting gets.

DO use an easy-to-access download-service. Dropbox is fine. Please no “wait 60 seconds, then enter undecifferable captcha, then close 3 pop-ups with forced audio”-hosting-sites.

DON’T keep me from playing the game once I started it. Hampering the start-up with more than one tutorial-screens or lengthy videos/credits is tiresome (you’re making a /game/, not a movie or a book).

DO actually end the executable when quitting. I have encountered several games which don’t “unplug” after quitting them, and still show up in the task-manager where they slow down my system.

DON’T require players to read instructions or a manual outside the game to understand it. Put vital instructions right inside it.  NOBODY reads readme-files, unless of course they’re called something like “WHY WOULD YOU READ THIS ANYWAY”, which might peak my interest.

DO have international-keyboard-layouts in mind. German and French keyboards have different key-locations, and when the keys don’t react people have to find find the replacement-key, and distort their fingers. Or alternatively mess around with keyboard-layouts.

Following keys are taboo (on qwerty-layout): Y Q Z. These are the major swapped ones internationally and the most used ones in games. EVERY symbol (% & * + – > | § # ?) has a different international location. Stay away from them. Games which have their controls on Y+X  <- bad.  Move them one key to the right on X+C however, and you just made your players from two major language-zones happy.

DON’T use the caps-lock-key in your game. Refrain from using the shift-key, as hammering it will cause a popup in windows. Everything around the landmine that is the windows-key should also be approached carefully.

DO play other games and give a vote. And don’t restrict yourself to the popular ones.

DON’T make the kitty sad.

I hope this helps

-Matthew

For the book I am writing (Game Jam Survival Guide) I did an in-depth analysis of posts tagged as post-mortem reports on the Ludum Dare website. This is just a rough copy and I’m hoping to incorporate your postmortems from this time around for the book so that the sample size is bigger – so remember to write a short, concise post-mortem after you submit your game next week with “what went right” and “what went wrong” sections, preferably in point form to make data collection simpler.

Some of these statistics really surprised me, while others merely confirmed my gut instinct. To draw some conclusions from the data, everyone should be familiar with their tools and frameworks prior to the jam. Most people loved coming up with a plan based on the theme, but many forgot to set aside enough time for art and level design.

Get people other than yourself to playtest it so it isn’t too hard, doesn’t have lousy controls and lame enemies, and is easy to figure out what to do. Don’t bother with physics unless absolutely necessary. Prepare to deal with time-management issues, cut features and focus on what’s most important. Keep your plan simple. Finally, and surprisingly, if you include music and sounds effects you will be much happier with the final product.

Good luck during next week’s LD22 compo. Remember, if you need more time, can’t share your sourcecode, used any clipart, prefabs or samples, or want to work in a team, you can join the JAM and enjoy an extra day to work on your game without worrying about the rules.

Have fun! I can’t wait to check out all your awesome games.

Kind regards,

Christer Kaitila
aka McFunkypants

Blog: www.mcfunkypants.com
Twitter: @McFunkypants
Google+:  mcfunkypants.com/+

Slimes! Just look at 'em all, slimin' around!

This was my first Ludum Dare, and in fact, my first coding jam of any sort. It was grueling, painful, and ultimately quite satisfying. I learned a lot, and hopefully I can share some of that knowledge for anyone attempting to do this sort of thing in the future.

Oh, and before I go any further, I would love it if you played a little bit of my game. I’m quite proud of it, and I’d love to hear your feedback

What was Awesome

Having a (rough) plan!

I went into this with a very broad idea I was excited about (controlling multiple tiny creatures at once). Armed with this constraint, I went into my image editor, created a blank 8×8 texture, and noodled around until I came up with the basic slime sprite. This then spawned further ideas about what to do with these tiny creatures, because after all, why do slimes exist other than to split up into smaller slimes? A half hour later I had two different sizes of slimes with a couple frames of animation for both. This leads to my next point…

Prototyping with real art

I love these little guys.

Having good, familiar tools

Ludum Dare is NOT the time to dive into a language you’ve never written in before, to use a shiny new unfamiliar library or piece of middleware, or to implement a cutting edge rendering algorithm you read about in a siggraph paper. I do believe it can be done, I’ve seen a few good submissions by people trying out a language for the first time, but you will run into stumbling blocks frequently. These will sap your time and your sanity, as you waste hours googling vague error messages and posting frantically to messageboards at 3 in the morning. I stuck to a toolsuite I knew well, and even still ran into issues and bugs that took far longer to resolve than I’d have liked.

SFXR!

Working with discrete units

As many systems as possible in my game use integer based units. Everything runs at a fixed timestep (there is no deltatime passed into the Tick() functions, and really no concept of elapsed time used anywhere outside of the physics system), actor locations are stored as integer vectors, etc. I found that this kept complexity to a minimum, and made tweaking animation timings, actor placing, and other things a lot easier. This strategy won’t work for most games, but for an 8-bitty 2D game, it’s a real timesaver.

Having awesome friends…

… and making myself accountable to them. I told a bunch of people about my Ludum Dare intentions, to the point where I couldn’t really back down without disappointing people that I respect. While I was in the thick of the competition, I set up a livestream, and a few of them were always watching. It was an awesome feeling to be cheered on while I was working, I honestly don’t think I could have done this without their encouragement.

“Just get it done” mentality

What Sucked

“Just get it done” mentality

Yeah. What was awesome at the start of the project grew into a monolithic block of gnarly, twisted code. Iterating went from a quick line change here and there, to a long slog through pages of code, searching for functions I’d forgotten the names of, and classes that may or may not even exist anymore. The worst example of this backfiring was my “actor factory” code, which of course started as a simple switch() statement, and ended up as a series of gigantic switch() statements full of redundant and copy-pasted code. This is where using an old library of code would have been very handy, as this is something I’ve done “correctly” before, but couldn’t be arsed to do in the short time allotted for the competition.

One of many awful switch statements. It goes on and on like this.

Adding content

I vastly underestimated the importance of having good tools for getting new content into my game. My levels were stored as huge grids of text in one of my classes, and I did my editing within Visual Studio’s text editor. Painful, and not great for iteration. Adding a new entity was a multistep process involving creating a new class, editing three different switch statements (ugh), dragging its frames of animation into the project, adding those frames to a giant list of textures, remembering what index in the list those frames were at (UGH), and other minutiae that quickly added up. By the end of the second day, I had fewer levels and entity types than I had planned on, and just didn’t have the energy to add any more. If I were to do this all over again, I would have allotted a bit of time at the start of the second day to cleaning up this mess and streamlining the whole process.

State of the art level editor. Thinking about licensing the tech to Epic for UDK4.

Using a physics solver for character control

Don’t get me wrong. Box2d / Farseer is fantastic for what it is meant for. But what it is meant for is NOT making a character smoothly and reliably run across your level, with finely tuned jump heights and air control, and keyed translation amounts tied to your animations. I spent probably five hours trying to get it to feel decent. I could not even tell you what I did to get it to where it is now. It’s STILL not where I’d like it to be. Plus, the damn slimes have a tendency to get stuck on geometry, to fall through the world, and generally misbehave. Unfortunately I just don’t have experience in writing anything like this, and having a big ole’ pile of slimes naturally fall all over each other was something I didn’t think I could get without a pretty good physics sim running it. I definitely need to find a better way to do character control if I’m going to keep working on this game.

My (awful hack of a) debug physics visualizer

Phew!

I don’t know if or when I’ll do this again. All told I spent about 30 hours working, wrote a little over 4200 lines of code, created 54 sprites and 11 sound effects, and shipped 7 levels of gameplay. It was incredibly draining, and I still feel like I’m recovering from it. That said, I came out of this with a renewed vigor for game development, and a great amount of appreciation for everyone who undertakes this challenge.

If you like my project or just want to chat, shoot me an email at jvsola@gmail.com. I’d love to hear your thoughts!

I’M IN MOTIVATION: http://www.youtube.com/watch?v=aYuOrCnokCQ

PURE WIN AMAZINGNESS: http://www.youtube.com/watch?v=eaIvk1cSyG8

Clare Luce

“The greatest escape I ever made was when I left Appleton, Wisconsin.”

Harry Houdini

“The horse may run quickly, but it can’t escape its own tail”

Russian Proverb

“It is better that ten guilty persons escape than that one innocent suffer.”

William Blackstone

“This is a place where I can escape to fantasyland.”

Elaine Vogel

“If you think you’re free, there’s no escape possible.”

Ram Dass

“Anyone can escape into sleep, we are all geniuses when we dream, the butcher’s the poet’s equal there.”

Emile M. Cioran

“Creating a character on or off the stage is an escape.”

Roger Moore

“Death, after all, is the common expectation from birth. Neither heroes nor cowards can escape it.”

Ellis Peters

“It is a pity that we cannot escape from life when we are young.”

Mark Twain

“Comedy is an escape, not from truth but from despair; a narrow escape into faith.”

Christopher Fry

“Every man builds his world in his own image. He has the power to choose, but no power to escape the necessity of choice.”

Ayn Rand

“A finely tempered nature longs to escape from the personal life into the world of objective perception and thought.”

Albert Einstein

“Faces that have charmed us the most escape us the soonest.”

Walter Scott

 http://www.microsoft.com/web/websitespark/

Good luck chaps

Did you know you can fix this? Well you’re about to.

XNA has two profiles. Each profile has different minimum requirements, and as a result different capabilities. If you were developing a retail game you might stop me here and say “But FireSlash, I need shader model 3.0!”. However, in almost all Ludum Dare cases you’re never going to break outside of the XNA Reach profile’s limitations. These limitations are effectively the limits of DirectX 9, which are fairly generous for most games.

The best part of this is that using Reach is very easy; especially if you’re using the XNA content pipeline. Simply right click on your project

Now click properties. You’ll get defaulted to the XNA studio tab (probably, if not it’s a mere click away!) where you can change your profile to Reach. Do this early in your project as it saves you possible issues later with recompiling textures.

Also note that if you use any kind of engine or supporting libraries, you’ll need to adjust the profile there as well. If your engine has compiled textures in HiDef you’ll need to remove these and recompile them for Reach. I suggest doing this before you start as it saves time and rage later.

Worry not, my gimmicky friend! The community has made available many tools for the painless production of said development video. The birth of your interactive offspring will forever be registered with the assistance of those timelapse tools:

 Windows and Linux

Linux

Other options:

• For Mac OS X, this tutorial will get you started in no time: Take Timed Lapsed Screen Shots From Terminal
• Another option for Windows is Fiona’s PyCatcher
• Kvisle wrote a very useful post to guide for Linux users: Creating a timelapse in Linux

Get übermotivated

Making a game in 48 hours is hard. There will be times when you feel discouraged by your lack of progress, skills or inspiration. If you’re going to finish a game this weekend, you need to make that your #1 priority. Don’t start the LD without knowing that no matter what, you’ll make a game this weekend. Maybe a very shitty game if things don’t go your way, maybe an awesome game, but a game no matter what. Don’t have any doubt about it and it won’t be a problem.

The excitement here and on IRC before the compo is a great way to build up that motivation, but be careful that once the compo is started it can work against you when others seem to be advancing their game more quickly.

Be prepared

There won’t be that much time for installing new software and learning how to use it. Do that now and be prepared.

Make sure to test all your tools before the compo. At the very least verify that you can run your software. Do you know where you put that dongle or original CD? Did you make any hardware change that could cause a problem with software activation (that happened to me with ZBrush once, their customer support fixed the problem… the next Monday).

If possible make a mini test game. At the very least, test your pipeline. Can you get those sprites to load? Can you export your 3D character and load it in the engine?

If you’re making a game from scratch without an existing engine, I suggest writing a conversion tool or plugin that will convert files to an extremely simple format that can be loaded directly. No need to waste precious LD time writing an .obj loader or whatever.

Get the ball rolling

So you may expect that once the theme is announced you’ll sit in silent meditation for a while and get the most amazing idea. Well, if that happens good for you. But for me it has never been that easy.

So just get started anyway. What? Without an idea? That’s right. The longer you wait, the harder it is to come up with an idea that you will like.

Have a few generic ideas ready before the compo and get started on one. Or just create a sphere, apply physics to it and literally get the ball rolling Once you’re working on something it’s a lot easier to have ideas than if you just sit staring at a blank page. And if after a few hours you think of something different and have to restart again, that’s ok. It’s a lot better than doing nothing and still not have an idea. You can probably reuse a lot of the code and assets anyway.

Your final idea can also come much later. For LD #5 I started making a dungeon crawler type of game. 28 hours into the compo, I accidentally used a glRotate instead of a glTranslate. I thought the result looked cool and ended up making a racing game on a ring shaped track. I would never have had that idea without that happy accident.

LD #5 first prototype and final game

Get rid of the placeholder graphics

Nothing kills motivation like a game about rectangles colliding with triangles. Placeholders have their use but for the magic to happen, to feel like you’re really making a game you need graphics sooner than later.

Sometimes I like to start with a bunch of generic graphics that I will be able to use no matter what my game ends up being. You don’t need perfectly polished graphics, avoid that at all cost. You just get diminished returns quickly but you need enough for it to feel like a game. Then if you have extra time at the end (that won’t happen) you can go back and improve them. The main character, if that concept applies to your game, is vital. If you have it, everything else can be placeholders. At least, you’ll have some life on the screen.

Don’t sleep all day

Yes, you need sleep. The competition is 48 hours long so don’t even think about not sleeping. But be careful about turning off the alarm clock. It’s easy to sleep too much which not only wastes productive time that you will regret not having near the end of the 48 hours, but it can also make you sleepy and unproductive. Personally I think sleeping about 6-7 hours a night is best during the LD but you may be fine with less or need more.

Just don’t be lazy. You’re going to regret any time you waste on other things. For the weekend, make your game your absolute priority. You can watch your favorite tv series the next week but you’ll regret a long time not being able to add that one thing that would have made your game so much better.

Have fun!

In the end, win or lose, it’s just a game! The important thing is to enjoy the Ludum Dare and doing something you wouldn’t do normally: create a whole game in a weekend!

Kyle Gabler give a number of great tips.  His 2nd Theorum of Destruction is likely very true for a lot of people.  I know for myself, the less I care the better my results become.