Martin Jonasson (http://grapefrukt.com/) & Petri Purho (Crayon Physics) gave a wonderful 15 minute presentation called Juice It or Lose It, where they show how to make games “come alive” with simple techniques.

They start with a dull Breakout clone and a confused audience. When it’s over, that audience is applauding and cheering, loudly!

This is relevant to Ludum Dare participants because they:

1. Take a simple game concept (like you’ll be creating)
2. Make it rock (like you want to do)
3. In a short amount of time (like you need to do)

It also has links to source code!

What are you waiting for? Juice It or Lose It!  =)

A wise man learns by the mistakes of others, a fool by his own.

-Latin Proverb

You’re all in for a treat, because I have been working on a HUGE post over the past few days just for you guys! It’s basically a postmortem of all my experiences in game jamming, as a relative amateur, and what I’ve learned from them. I wanted to make this post for two reasons: to focus on how to make my own jamming skills better (I’m the fool!), and, as a secondary goal, to help other people with their jamming (that makes you wise!).

Of course, I’ve done a lot of failing, so the post is a little long to put here! So, instead, I’ve put in on my blog to trick you into giving me more hits- I mean, keep my post from taking so much space. With my luck, this will be off the front page in a few days (CURSE YOU FOLIS), but oh well.

Here’s the link, and an excerpt from the summary near the end:

So, here’s a summary of all the lessons learned, or, as I like to call them, THE THIRTEEN COMMANDMENTS.

1. Plan ahead.
2. Do something you’re comfortable with.
3. Let’s admit it, there are stupid questions, you just shouldn’t feel stupid about asking them.
4. Make someone play through the game.
5. Have all core features done by midnight on Saturday.
6. Don’t use libraries if you find they need “minor modification” before doing what you want. Code it from scratch, or find a library that does exactly what you need.
7. Don’t make a game without first knowing what you need to know to program it.
8. If you’re sure you have absolutely no idea how to program it, don’t try.
9. Don’t overestimate yourself. Make sure your design is small and well-polished and does what it can well.
10. Have a very clear idea of how the game will turn out in the beginning. Especially when you’re working with a team.
11. Know exactly what tools everyone is using. Seems obvious enough, but trust me, make sure you know them.
12. Don’t immediately take someone else’s solution for your bugs. Try and solve it yourself until all else fails.
13. Motivate yourself every second, before, during and long after the competition.

Here are a few videos I put together showing progress of my game Vox…

http://www.facebook.com/VoxGame

This is a direct continuation of the voxel engine/game that I made for Ludum Dare #23.

Hope you like… feel free to ask me any questions or comments yo might have?

Alwaysgeeky

So I recently added water to my voxel engine and have been playing around with it…. one thing I have found out is that water is sooo much fun to code, it’s tricky to get a decent simulation and hard to get something that is stable and looks nice, but once you make something you are pleased with, you just wanna play around with it so much!

At this rate I might have a full voxel engine ready by the time the next LD competition drops… be able to spend the full 48 hours on actual gameplay and making a game to suit the theme…. that should be fun.

Here is the link to my article/guide/tutorial site for voxel engine resources:
https://sites.google.com/site/letsmakeavoxelengine/

AlwaysGeeky

Starting to add more and more functionality to my voxel engine and it is starting the slow evolution into a game, with fun elements. I’m still aiming for daily videos showing progress and hopefully each one showing a new feature or something cool.

My guide/tutorial site is taking shape, but I am still coding lots and lots and finding it hard to put a massive amount of time into writing articles. More will come with time though…
https://sites.google.com/site/letsmakeavoxelengine/

I have some questions for the community and gamers.

• What sort of creating tools would you like to see in a voxel sandbox game?
• Do you think it would be good to offer a library of common objects that the player can import/export to re-use as they are creating?
• What parts of a game would you like to customize (and share with others)? Your character model, weapons, items, NPCs, quests, particle effects, world regions?

Also anyone who has played Minecraft (or other sandbox games) can probably help me by answering a couple of questions below:

• During the creative parts of the game, i.e crafting, building, customizing… do you prefer to still be emersed in the game while in this mode or do you prefer a more abstract tool/interface? For example when crafting or building in minecraft you still have to walk around as the player, rather than having a fly around ‘god-mode’ when you can craft/build with a mouse pointer.
• Is there anything frustrating about collaborative creating, Do you wish you had more control over allowing others to modify what you create, tools for information exchange?
• How much do you think a sandbox game should be released with actual story content? i.e should the game already have a main quest, completion goal, or just be totally open?

Thanks
AlwaysGeeky

Been working away on my Voxel engine that I first created during the last Ludum Dare and just created an SSAO shader (As per requested by Vigrid) and I am so pleased with it, I wanted to show it off and also show my general progress…

I have put up some more videos on YouTube too:

Please checkout my channel.

Also people have been asking for guides and tutorials, I am in the process of making these and posting them here: https://sites.google.com/site/letsmakeavoxelengine/home so if anyone wants to learn about making a voxel engine, or even follow in my footsteps, I am documenting my steps there…

Enjoy

AlwaysGeeky

This was my first Ludum Dare and I thoroughly enjoyed it. Not only because I learned a lot in a short time, but also because I made (what I believe is) a pretty good first iteration of a game in just 48 hours. I have plenty of ideas for what I could do with the game, but I’d much rather find out what the players want and build that into my backlog. That is one of the great charms of Ludum Dare – building a prototype and getting guaranteed feedback from real players.

As of writing, my game has 34 comments. I could go through them one at a time and tick off each feature request, bug report, etc, but that would be long and stupid. So, here’s what I did instead:

1. Gather all feedback
I copied and pasted each comment from my entry page into Excel and cut out any that very clearly didn’t provide any useful feedback (e.g. “Awesome game!!!1″ or “I didn’t like it”)

2. Split feedback into negative and positive key points
The point of this step is to understand what each piece of feedback is actually telling you. I found it helped to make a list of negative and positive bullet points for each comment. Take this example:

“I like this, it has a lot of potential. Here are some of my random thoughts…

It’s rather slow paced. It feels less like action than “Line up with an enemy, start shooting, wait, dodge it, wait, wait, dodge it, aim at next enemy”. Also, because there are so few enemies in each stage, it feels empty.

It’s hard to keep track of where you are. It would be awesome if there were a minimap during the shooting bits.

I got frustrated with placing pieces, but then I figured out, you can’t place a piece if it doesn’t match up? That does make sense, but with a little work it could be better. How about if the game checks if there’s a valid path, and it won’t let you place a piece that makes the path invalid? Also, what happens if you run out of room? Perhaps you could place pieces over previously placed pieces to delete them.

I’ll be looking forward to later versions! ”

If we extract the key positives and negatives we get:

Positives:

• Good concept

Negatives:

• Slow-paced ship section
• Too few enemies in a room
• No in-game map
• Difficult to figure out level building (tile placement)
• Unintuitive level building (e.g. just place junk pieces elsewhere until right piece appears, potential to run out of room)
• Build stage lets you proceed to ship stage even if a path doesn’t exist from start to goal

3. Group feedback points and sum totals to rank them
At this stage, you’re still left with a long ‘to do’ list of overlapping or contradicting items. You should group similar points together and rank them according to the totals

You can see below the tally of my groupings:

My interpretation is that people really enjoyed being able to create the levels before flying through them, but the level building could be better implemented, explained and introduced. The other major feedback points were around the ship sections being slow-paced but occasionally too difficult (green rooms are too easy and red rooms are too hard), and enemy ships starting too close to the door when entering a room.

4. Take the top negative items and determine how you can resolve/improve them
You should now have a list of items, ranked by the number of people who commented on that aspect of your game (I took anything that 2 or more people commented on). The idea is to remove the pain points by taking the most commented negatives and working out how you can turn them into positives. So, another example:

“I don’t fully understand the level building section”

Improvements:

• First level goes straight into ship section, second introduces level building with short tutorial
• Prevent level start until route exists between start and finish
• Remove restriction on tile placement (can place anywhere)
• Replace random tile selection with ability to choose which tile to place next

Note that you may occasionally need to refer back to some of the comments if your items are too general.

You should now have a pretty full to do list of changes that will make the biggest positive impact to players, which you could merge with your previous list of new features/fixes to cater for the few things that players may not have thought of.

So I have been busy adding new features and playing around with voxels, in the aftermath since my Ludum Dare game, when I initially created the voxel engine for my entry.
(My Ludum Dare 23 Entry)

I have just added support for dynamically loading and unloading chunks and also a simple fog renderer so that load popping in the distance is somewhat hidden from the player. Started using noise functionality to generate a nice flowing landscape but I need to play around with noise a bit more and get used to terrain generation before I make anything look good. (Mountains & caves! )

I am thinking of doing a series on creating a voxel engine and maybe posting a step by step guide/tutorial about voxel techniques to the LD site so that others might be interested in also playing around with voxels and cube worlds.

Link to my game - (ratings and feeback very much appreciated!)

@BigDaveIsCheap’s LD23 video roundup featuring Tiny World War (at 3:40)

Timelapse of the creation of Tiny World War

Preparing For War

Having followed LD for yonks it was finally time to bite the bullet and jump in with both feet. I was so excited to spend the weekend entirely devoted to the hobby I love, I couldn’t wait to get started, so preparation was no problem whatsoever. The first thing I did was

Tip #1 – Buy McFunkypants “The Game Jam Survival Guide”

And from this flowed forth much insight and timesaving! So I decided on Flash and Fllixel since I was familiar with the tools and could easily share the game – and I got my toolchain all setup and ready with a HelloWorld app that built and ran. I won’t reiterate all the great tips in McFunkypants’ book, I recommend you buy it! However, as a happily married chappy one of the most important tips I will add here is

Tip #2 – Plan the weekend around your loved ones

I can’t overemphasise how important this was. With my lovely wife on board (and guaranteed a place in the credits ) I not only felt free to indulge gratuitously in my hobby, but I had a superbly supportive playtester, motivator, and carer on hand making sure I ate, drank and slept in appropriate proportions! Going out for dinner on Saturday night not only helped me chill out and come down from the intense day, I woke up after a great night sleep full of ideas for day 2! Speaking of ideas:

Tip #3 – Have some rough game outlines in the back of your mind, pre-jam

Controversial, perhaps, but I found great inspiration from a recent trip visiting World War 1 battlefields near Ypres in Belgium, and I knew I fancied making a WW1 themed game. I felt WW1 was under-represented in games, so I figured I’d have something niche. Fitting this with the Tiny World theme took some creative thinking, but hey that’s the whole point!

It’s War!

Tip #4 – Have a battle plan

Since this was my first LD I really had no idea how much I’d be able to achieve in the time available. I knew I’d have all day Saturday and all day Sunday and that would be it (EU timezone thing). So my plan was to have the game basically “finished”, and then spend all Sunday polishing it. This definitely paid off as I’m happy with the level of polish the game has. I’m not so happy with the very simple gameplay but it’s finished, and without the text boxes, menu screens, music and sounds it would not be a complete game. Of course ideas and features popped up in my mind throughout, but I had to discard loads of these and hopefully just keep the best ones, so

Tip #5 – Make bold decisions and stick with them

There’s no time to restart in a different direction. A highly polished turd still has artistic merit, that’s the risk you take. At least your experience will be a “something” rather than a mashup of nonsense. The same principle applies to tweaking and balancing. There’s no point making tiny adjustments to the game; it’s going to be rough but as long as all the parts are there you have something you can call a game at the end, so concretely:

Tip #6 – If you tweak a variable in-game, double or half it, don’t micro-adjust

This tip, from Jesse Schell’s excellent “The Art of Game Design – A book of lenses” saved me so much time and helped to pin down things like: player move speed, enemy firing rate, map size, the interval between random explosions, the number of enemies… the list is endless, pretty much every tuneable parameter in the game got to where it is by doubling and halving until it felt right. It’s a binary search logarithmic complexity thing (I guess). It relates to a general principle:

Tip #7 – Get into “the zone” and get over “the wall”

That flow state where you are deploying your skills to their fullest and the challenge is worthy of your ability. In a jam you set your own level of challenge, so know yourself and know your limits. Know what you need to keep you flowing (quiet, breaks, food, sunshine, IRC, feedback, whatever). The “Wall” was an interesting one. I genuinely didn’t expect to hit it because I really do love this hobby so much - wrong! After spending an hour on player controls I felt my love for the game waning. Time to stop that path. I pushed on and finished that nasty section, then did something fun and “easy” – generated a ton of sound effects in BFXR! What a juicy tool, that was great. I finished day 1 with a game that looked and sounded more or less the finished product. For keeping motivation high, nothing beats

Tip #8 – Go directly to final art

Programmer art being what it is, front-loading the art creation task seems sensible. The art is hard, the code is easy (relatively). Now I may have to revise this because I think the main problem with my game is that it is too simplistic, and the only thing harder than art is that holy grail:

Tip #9 – But don’t forget the fun

A sad fact is that in a competition with 1400 entries, no-one is going to play anywhere near all of them. You have to stand out and your main channel for this is graphical screenshots. A pretty game *will* get more plays, initially. However as time passes and word of mouth comes to dominate ratings, a fun game will eventually outshine a boring pretty one. A game that is well balanced, full of game-y pleasures and surprises will always win the day, just not initially. However if a game jam is the nursery from which games grow, the real world is where games that stand the test of time will flourish. Tiny World War is fun, but not for as long as I’d have liked. I’d like to know what you think in that regard… Which brings me onto the final point

Tip #10 – Share the joy

It’s perhaps obvious, almost too obvious, but the point of this competition as far as I see it is not to make money or have glory (for most), it is quite simply the opportunity to dive right into an enormous bubbling conversation about the fantastic experience of satisfying the highest of creative urges under extraordinary conditions with hundreds, indeed, thousands of like-minded individuals. It’s a celebration of gaming, creativity, humour and perseverance. If you create your game in a bunker, release it on the quiet, tell no one, post nothing on the blog, ignore irc and don’t bother to play anyone else’s games, wow that is some crazy behaviour. Community and feedback is what this is about. I just wish I’d spent time on IRC as I feel I really missed out there. I’m trying to make up for it now by leaving the most useful ratings I can and keeping the conversation going.

The Aftermath

In a nutshell, that was one of the most intense 48 hours periods of my life. It was an emotional rollercoaster, and at the end of it I have a game I’m proud of, despite its problems. There are highs and lows in an escapade like this, but wow, what an unforgettable experience! I can’t wait to do it all again for LD24 ;D

This always ends up happening to me the further into development I get and the more gamey that my creations become. I usually find that I end up just playing around with what I have made and experimenting with stuff in-game much more than writing more code. lol

Does anyone else notice this with themselves or have a similar problem when making games or writing code?

Also, I find that the more sandboxey or open world or experimental the thing I am creating is, the more I tend to play around with it. The second I implement any kind of 3D physics into whatever I am creating I turn into a 12 year old boy and just spend hours and hours messing around with what I have created and being fascinated with what you can do with physics…

I made a 3D physics engine for my final dissertation during my masters course and I swear I could have coded about double what I finally ended up with, if I hadn’t spent so *many*, *many* long hours into the early morning just playing around with different physics properties and making fun stuff happen in my engine…

I guess that’s one of the problems with coding stuff/games that you truly want to, you end up making the thing you want to play so much, that you just end up playing it half the time!

It’s been a couple of weeks now since Ludum Dare 23 and I wonder what everyone has been up to… I know a lot of people have been updating and improving their games that they entered into LD23 and that is great! It’s super awesome to see people actively keeping up the interest in their game development.

I thought long and hard about what I should do with my entry, post-LD, and finally came to the conclusion that I wouldn’t directly be making modifications to my game or adding stuff/making it better. Since I didn’t really have a grand design plan for my game as I was creating it and most of the gameplay ideas came about quite abruptly during the 2nd day, I decided to let it stand as it is and move onto other things.

So…. I have been spending the time since the competition making my voxel engine even better!!

I have been doing a lot of the core voxel engine related programming that I didn’t get a chance to do while I rushed to get something playable during LD:

• Octree support
• Culling
• Rendering optimizations
• Player movement
• *Proper* collision detection
• Loading/unloading scenes
• Editor ^_^
• Terrain generation
• Etc..

I am going to be keeping a dev vlog diary of progress I make and uploading a daily video of features to my YouTube channel:

https://www.youtube.com/playlist?list=PL3899B2CEE4CD4687&feature=plcp

If anyone wants to keep track of my progress, or see my videos on general game development, and if you like my YouTube channel then feel free to subscribe, I have lots of cool gamedev stuff planned and could really do with more subscribers.

I’ve also been thinking also that I might make a public release of my voxel engine (with all the improvements), if anyone would be interested in that…? I am probably going to be using it to make something for the next LD competition, but I haven’t fully committed to that yet, we shall see how things go.

Anyway, it’s so nice to see all the activity from the Ludum Dare community still going.

Cheers.
AlwaysGeeky

So now that Ludum Dare #23 has finished and the dust has settled, I guess its time to write a post about the post mortem and give some insight into my experiences with making a game in 48 hours…

Here is a diary of the major milestones of my 48 hours highlighting interesting points of my development:

Hour 1

I rushed head first into creating my voxel engine, I was pleased with the announcement of the ‘Tiny World’ theme, it seemed as if this theme was perfect for what I was creating… My mood was great!

Hours 2-6

Still driving ahead with the voxel engine, encountered a few problems with how the triangles and meshes are rendered, so had to go back and improve my rendering engine. Spent a good portion of these hours optimizing how triangles are pushed to the renderer and adding support and features for mesh rendering with display lists and vertex buffers.

Hours 7-9

Started playing around with different configurations for meshes/chunks/regions… came up with some interesting implementations of how a voxel world could look (sphere worlds, cube worlds, trees). I made sure to leave all configuration/ideas in the code so that I could easily come back to anything which worked.

Added support for cubes/voxels with different textures. Using a texture atlas to store the different textures. i.e. (grass, stone, wood, magma, etc) This would be important since I wanted to make a world that could be modified by using different cube types.

Towards the end of day 1

Hit a wall with regards to what my final outcome was going to be… I did have some original ideas relating to a flat, cubed world with tress and houses that you walk around and do stuff as a player, but nothing really inspired me in that respect without completely ripping off minecraft functionality (which I did NOT want to do).

So I went to sleep and hoped to come up with some neat ideas in the morning.

Day 2

I woke up with renewed vigor and some thoughts about a different direction that my game could take. I decided to make it more abstract and not have a player in the world or have any direct user control, instead focus on world destruction and voxel effects.

Day 2 general

The bulk of day 2 was taken up coding effects and voxel related gameplay. I created asteroids and a layering system for my planet, exploding blocks and effects of asteroids crashing into the planet. The vaporize and terraform effect was actually something which came about accidentally, but I liked how it looked so decided to keep it in and make a gameplay mechanic for it.

Hours 35-40

This period was pretty crucial for me, I was rushing and coding gameplay elements really fast, I had a feature idea and once I got it working I moved onto the next thing on my mind. Asteroids, world vaporize (terraform), exploding chunks of the world, world rebuilding. I needed to make a full game cycle so I decided to add a timer that would ultimately drive the gameplay (destroy the world within the time limit).

Hours 40-45

I had finished the gameplay that I wanted. Next came the hard part of making it usable and playable. Having a lot of functions that are bound to keyboard keys is no good when you want other people to play your game and enjoy it.
I started to code the game flow:

Start menu –> enter game –> game timer –> score screen –> restart.

Added basic HUD and menu. i.e “Press SPACE to start/restart” and a scoring system.
My plan for the scoring system was going to be more complex with multipliers and additions for which super moves you used, but I didn’t have the time to make this work, so stuck with a simple score and time multiple.

Hours 45-47

The HUD and user interface needed work, I added these features faily easily but they were basic and static. So I started working on timings and polishing the interface. Flashing “Press SPACE to start/restart”, score screen with accumulating score. Timings and delays on the game flow to add additional polish. For example when you destroy the world, the score screen doesnt instantly popup, it has a time delay, or when you press to restart the game, the game waits until the world is rebuilt before allowing player control and starting the time. etc. This polish and attention to the small details is what makes your game stand out and feel like a proper experience, rather than a load of features cobbled together.

Final hour

This last hour was mostly taken up with preparing a release package, zipping up the projects and source and testing to make sure a download of the source and executable would build and run, etc… Faily boring stuff but it does take time. I noticed a problem with absolute paths in my Visual Studio project, so had to rebuild a whole new project solution to fix this… luckily my project solution didnt contain too many header and cpp files.

I tested my package, uploaded it and then created an entry on the Ludum Dare website… then sat back and had a rest.

My entry can be seen here:
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=11531

WHAT WENT RIGHT:

• Had great momentum from the start – I was able to put off the design and gameplay decisions till much later, since I had a lot to code from the start, having decided on a specific rendering engine.
• Used my own personal engine – Since I was using my own 3D/OpenGL engine, I knew exactly what I could do and how to do it.
• Voxels and cube art is great for programmers (and anyone who isn’t an artist) -   Art was always going to be a problem for me, but creating stuff in 3D mitigates that problem slightly and creating stuff purely with voxels actually looks great with NO art whatsoever (See minecraft )
• Got lucky with the theme – Seriously, I couldn’t have chosen a better theme for a voxel based game if I tried. if the theme had been something like ‘Evolution’ or ‘Discovery’ or some other abstract concept then I don’t think my game would have turned out half as good as it did!
• Got involved with the LD community – I really enjoyed looking at the other users entries on the LD website and also posting my own progress and hearing feedback and comments from the community. Nothing is more rewarding that seeing other people’s efforts and encouragements from the community.
• Self documentation – I think I did a pretty good job on documenting my progress, taking screenshots and uploading videos to youtube.  I even enjoy looking back myself now and seeing the progress that I made during the 48 hours.

WHAT WENT WRONG:

• Gameplay – I left most gameplay decisions until the 2nd day. After I was happy with my rendering and voxel engine I actually spent a good hour or so scratching my head as to what to do next.
• Focusing too much on the rendering/engine – I was torn between wanting to make a really optimized re-usable voxel engine, and adding in gameplay features. At one point I had to physically stop myself adding voxel engine features and rendering optimizations to force myself to think about gameplay and mechanics. I could have quite easily spent the whole 48 hours making a voxel engine…
• Trying to do too much – I had far too many ideas that I wanted to try out and not really having a clear design goal or making any gameplay decisions at the start meant that I was fragmented when I wanted to start making something that would be playable.
• Memory leak! - I found a major bug (memory leak) in my voxel particle renderer about 8 hours before the compo was due to end. I was leaking memory quite badly when creating and destroying particle effects that I HAD to fix. This took up about 2-3 hours of valuable time towards the end of the 48 hours.
• Basic user interaction - It is really hard polishing a user experience, so I ended up just putting a couple of buttons in for the special moves, not the most elegant way of coding gameplay features

Advice:

• Sleep! - Don’t even bothering thinking that you can work solid for 48 hours, it is just not possible. It’s counter productive to lose ANY sleep and even just trying to do one all nighter is going to be detrimental to your progress. Yes you are going to probably stay up later than usual and once you are in the zone its hard to leave things to go to sleep, but if you are staying up into the early hours of the morning and going to sleep before it gets light outside, I would say you are doing something wrong.
• Prototype FAST - 48 hours goes really fast, if you are spending a lot of time on a feature or idea that just doesn’t seem to be working, move onto something else. Don’t waste time flogging a dead horse.
• Know your tools/code/engine – Since you are going to be creating something SUPER fast and with no time to spare, you really need to know what you are using. It helps if you know exactly what your engine is doing, right down to the individual function calls and rendering details. You will spend far less time fixing bugs, debugging code and trying to figure out what is going wrong if you know your engine/code inside out.
• Make decisions before the competition starts - I think I can attribute a lot of my success to this point. Since I was prepared before the theme announcement and was ready to start programming the instant the 48 hours started, this helped me a *lot*. I could have took this EVEN further by making some gameplay decisions first as well as deciding on the style of my game.
• Make the theme work for you. – (This is related to the previous point) Already have an idea of the sort of game you are going to make and then just adapt it to suit the theme… It is no good having no idea about what you are going to make and just trying to come up with a game that perfectly suits the theme. You will waste valuable time thinking and designing when you could be coding!
• Polish what you have – Personally I think that a well polished, smaller scope game that does a few features really well, is much better than some attempt at a game that has lots of features but doesn’t implement any of them particularly well. LD is a time to create something small that shows off something cool in a neat little package, not create the next big blockbuster.

Final Thoughts:

Overall I had a blast making a game in 48 hours and taking part in my first Ludum Dare. I am pleased with my final outcome and even surprised myself with what I made. I now have a 3d voxel engine that I didnt have before I started the LD48 and don’t doubt that I will be using and improving it from now to create even better voxel games.

Thanks for all the support guys and see you next time.
AlwaysGeeky

So you posted on someone’s else blog. How do you know if they replied to your post or not?

Very simple: use the search feature! In the control panel, go to “comments” and type your own username in the search box, and it will list all the comments that you made, plus comments from other people mentioning you. Then you can quickly go to posts that you’ve commented to check for replies.

This may be obvious for some people, but I didn’t know about it the first time around on LD22, and could never really keep track of replies to my comments in other people’s blogs.

As an extra, if you search for your username on the “posts” section, you can find out if people are talking about you/reviewing your game. Try it out too!

My entry tr-3012 is primarily a musical instrument, a drum machine with five independent looping triggers identified by robots.

This time around I did a lot better at removing code that wasn’t necessary and dropping ideas I wouldn’t have time for. I had all of these digitized robot voices recorded that my five year old loved but which didn’t really make the game any better.

One thing I regret not having time to implement was an introductory zoom from outer space into the playing grid, to make it look like the robots were isolated and adrift in space. That would have helped fit the theme better.

The tools I used:

Processing
Piccolo2D
Piccolo2D library for Processing
Beads library for Processing
Garage Band
Animoog
Audacity
TAL-Dub-2 audio unit plugin
GIMP

I plan to add a few new features to tr-3012 later, to make it more useful as a musical instrument

– allow user-provided samples
– external MIDI sync, or at least set a tempo in BPM internally
– send MIDI and OSC events in place of/in addition to playing samples

Well, this may be a bit early to do reflecting on the actual game, given that I haven’t gotten much player feedback. Although there were no major snags in my process this time, there is still quite a lot to take away from the experience.

Stuff to Remember for Next Time

• Processing is a good tool. While I can think of plenty things I’d like improved in it, and while I couldn’t successfully export an applet from it, it saved me from having to set up a project file as I would in C++. I didn’t have any trouble with adding graphics or audio.
• Fake the physics. Last April, my greatest challenge was the physics engine. This time, I wrote another physics engine. It only worked with circles and the hardest math it used was computing a component of a vector. Also, most the math was created through the process of, “this seems to work,” rather than through any deductive reasoning. Overall, it’s not very realistic, but it passes for a game.
• Get a prototype out early. In this Dare, I had a prototype ready 18 hours in. I found that it was really boring. At that point, planets crashed into each other and stopped when they did, creating a big clump. This was not at all challenging to avoid. I ended up writing a basic physics engine and changing the goal of the game entirely to make it better. These tasks were fairly significant in scope and took a good amount of time. I also made a lot of tweaks to the movement mechanic based on some comments of, “Your game nauseates me.”
• Add variety to the game. Late in the development of the game, I decided to add difficulty levels (which are based on the score). This led to the advent of huge planets and fast planets, which make the game more interesting. I also found this in the game I made last April, when I added falling platforms, moving the game away from a pure puzzle (since it wasn’t a very good puzzle).
• Google can help you make assets (indirectly). While it’s obviously cheating to use premade assets, it is useful to look for resources on how to make assets. For instance, for my astronaut, I wanted a really easy walk cycle, so I looked up, “pixel art walk cycle” and found some useful tips.
• Details matter. The game feels quite a bit more professional now that it has fades between all the screens. The Earth graphic looks just plain weird without clouds. The tiny jump sound makes the game feel different than if there were nothing.

Sleep 1
I wore my Fitbit to bed last night. Here’s is it analysis:

I expected to sleep longer, but I didn’t feel like I was dragging out of bed. I’m worried I’ll need to take a nap later.  We’ll see.

Breakfast 1

Standard bacon, eggs, and tomatoes breakfast.

Brainstorming
Now, to figure out how to best improve the game:

• Scoring mechanism
• Different types of seeds
• Mobility
• Change the way your seed bullets work
• Improve graphics
• Title Screen
• Icon
• Music
• Sound Effects
• Pop-up tips

Pro Tip
Use imgur.com (free) to host you food photos and screen-shots. It reduces the load on the Ludum Dare site and it is super easy to use.  Just drag and drop to the “Upload” section or if you register and activate you email address, simply email photos from your smart phone directly. Then uses the “From URL” tab on the Insert Media screen. I’ve also found that if you remove the width and height attribute from html the “Insert Media” screen creates the pictures re-size themselves perfectly.

Please provide a standalone Windows version of your games, so that people using Linux can test them using Wine !

Of course, a native client playable through Chrome would be better (ie. closer to native), but reports from Sophie Houlden are making it seem like a lot of trouble. So pretty please, for the sake of having your game played by more people, release a standalone Windows version !

There wasn’t a whole lot of information about it around but I managed to piece together a quick script to do live streaming from a linux desktop.  It’s simple and for speed reasons I’m not broadcasting sound myself. (I get unrealiable levels of upload lag so if i add sound it’s kinda distorted…I really wish their streams allowed speex codec :/)

if you do want sound, you can change it to this for alsa

or for OSS

Update, April 15: Awesome! I just scored a 40% off discount code for Ludum Dare participants (it won’t last forever!): “gjttsgeb” at http://link.packtpub.com/31Eodu

Update, April 12: Apple just approved the book for the iTunes iBookstore! http://itunes.apple.com/us/book/the-game-jam-survival-guide/id516248330

WOO HOO! I’m excited to announce that my new book, The Game Jam Survival Guide has just been published! This book is essentially a love letter to the Ludum Dare community.

It includes interviews and advice from LD48 superstars such as PoV (Mike Kasprzak), Fydo (Chris Hopp), Phil Hassey, Pekuja (Pekka Kujansuu), and Chevy Ray Johnston (two time winner of LD48), as well as other game jam experts such as the people who run the Global Game Jam. (more…)

Now that the voting’s over, I have some tips on how to make a good concept for the game that I learned from observation and feedback.

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.