I will be participating in LD27!

I’ve gotten streaming to work for arch linux, and here’s my warmup;

And the streamcast (15 folks!);

If you’re interested, I’ll be broadcasting an hour before LD starts tonight.

http://www.twitch.tv/josefnpat

Dear Ludum Dare developers. For LD25, I will be working in a team, and have written up a message to all the developers on my team. I am posting this here in an effort to document my knowledge, get comments and suggestions on how to improve this document, and perhaps help a few folks out who are having troubles.

You can check out the article here, or follow this link to a much more legible version: http://50.116.63.25/public/ld25.html

My Dear Dev Team

LD25 is getting close, and I want to prepare you for the shit-storm that is about to happen.

Tips for success:

• Read the damn rules. It’s not hard to figure out. We’re doing a Jam compo, which pretty much means just about anything goes. To clear things up, I will post the game on the teams behalf. It’s also especially important to look at what aspects our game will be rated by.
• Be public. Join the luduim dare irc channel. Post screenshots to the site or IRC for feedback. Tweet with the LD hashtag. Post blog posts to ludumdare.com with your own account. Get people excited about our game, so we can get lots of ratings.
• K.I.S.S. Keep it simple stupid. You’ve only got 72 hours, so you need to make them count.
• Sleep well and eat well. If you are well rested and eat well, you will find yourself much more productive, and less prone to introducing crap into your game. If you are tired, either work on something else, or go get some sleep. Take breaks, don’t burn out. If you suck, your code will suck.
• Avoid stepping on toes. If you’re working on a ticket, make sure you’ve marked the ticket to yourself and tell everyone. Try and stay out of the global files, and modularize. The less merging you do, the better off and faster you’ll be.
• Trust your team to do it right. One person shouldn’t be writing all the code. If the code isn’t in your style, clench your teeth and keep going. If you find a bug, report it and make sure the owner of the ticket knows that it’s their responsibility. Always ask for permission to change someones code, and tell them why you want to change it.
• Chill out and have fun. Remember, this is supposed to be a fun learning experience!

Before you even show up:

• Reduce barriers of commutation whenever you’re working. When you’re working, you need to be on mumble unmuted. Since we can’t be in the same room, we need to communicate as much as possible.
• Prepare your toolset. Don’t waste time setting up during the competition. For example, I’m a programmer, artist and sound tech guy ( I wear all the hats ). Here’s my toolset;
  • MVP/GDD → Google Docs
  • Repo → git-core
  • Framework → love 0.8.0
  • Code → nano/gedit
  • Issue Queue → Bitbucket or Github.
  • Art → gedit
  • Sound effects → audacity, zoom R16 / SM58 , sfxr
  • Music → ZoomR16/SM58/Guitar/Effect Pedals, LSDJ, Audacity
• Know your toolset. Yes, this should be a part of “prepare”, but this is essential, otherwise you’re wasting time. If you plan on coding, you better know what you’re doing. If you haven’t even gone through a tutorial and attempt to commit, I’ll remove your write access. Also ensure you know what the formatting guidelines are. In this case, it’s two space, no tabs.
• Decide out who’s running the show. The jam will be so much easier if you have someone who has the final say. Since I am taking this roll, I will be the person who compromises most.
• Apologize to your friends, family and/or girlfriend. You’re in this for the long haul, and it’s a lot of work, but believe me, it’s worth it. Note: If you have no friends, family or girlfriend, please go pet your cat. If you do not have a cat, get one. Then pet it.

A quick note on the git repo;

• Use /dev for development assets and such that are resized or altered for the actual game. it adds overhead, but it’s nice to have the original assets available to everyone.
• Use /src for anything that actually goes into the game.
• Put any build scripts or dev scripts in the root of the repo.

The repository should be set up and ready for everyone to use!

During the jam:

Ok, so you’re ready to jam, #ludumdare has been muted, and ludumdare.com/compo has started crashing due to people raping the F5 button. Finally the /topic is changed, and twitter starts re-tweeting the theme.

First things first

1. Brainstorm ideas. Figure out an idea that everyone likes or at least will compromise to.
2. Once you have an idea that everyone can work with, brainstorm on the idea. I like to open up a Google Doc, and give everyone write access. Let everyone write what they want, and as much as they want.
3. Decide what ideas go into the game. Put them in your issue queue. Break them down as much as you can.
4. Decide what goes into the MVP. Decide what it takes to make this game a game, and leave everything else out. Mark those issues appropriately.
5. Make sure the team believes they can complete the MVP within the first half of the competition.

The first half

No one should be doing issues not marked for MVP until the MVP is done (unless they can’t do any other issues). Remember, once you have the MVP, you have a game. The first half of the competition ought to be used.

Concentrate on getting the MVP done!

The second half

At this point, what is left is transforming the game into a great game;

• Testing and Bugfixes → Get people to test it! IRC, your friends, your family, anyone! The more issues you can find, the more you can fix before the game gets released.
• Extra Features → Remember those extra features you wanted to put into the MVP, but couldn’t? Do them now.
• Polish → Something doesn’t look right, isn’t fast enough, or could look better? Fix it here.
• Content → Add more stuff. You only have 2 guns? Add 8 more! You only have 3 levels? Double it, triple it, whatever!
• Be sure your packaging system works, you have a good title and blurb, and of course fun screenshots! Thens submit the sucker!

After the jam:

You’ve finished the game and you’re beat, but you’re not done yet.

• Respond to folks who review your game, and review theirs back!
• Ensure the team reviews other games through the account that submitted the game, so the game can get more exposure.
• Tag the release version, and try and close the rest of the game breaking bugs. If you feel so inclined, add more stuff! Just because the jam is over, doesn’t mean the game is done.
• Package your game up and host it!

Finally…

I intend to be available as much as possible to help keep things in order, but if I’m not there, you guys need to communicate with each other as well. Whoever is there, use your best judgment. Not everyone will have the same schedule.

Tomorrow at midnight is when LD25 starts. If you’re there, you get to help out on the ground floor. The MVP. If you’re not there, you’re going to have to follow the GDD to the letter until we get to the second sprint.

– josefnpat

For more, check out the The Game Jam Survival Guide!

Pocket Strife Entry

What went right:

• Git helped me keep everything in order, and even supplied me with a gource! In a Jam, as opposed to compo, git would have been perfectly, but in retrospect, it’s a little superfluous for a compo. I would still do it, as it is really only a few extra minutes of my time, and gives me something to roll back on if need be.
• Being well rested makes a world of difference. I got three or four more times more done on Sunday when I was well rested than I did on Saturday in only double the time.
• Know your tech – using love (love2d.org) was pure awesome, as I knew the API and I knew Lua.
• Bring your own tech – I prepared for this LD by asking myself, what are libraries that one would normall find in games? These are the ones I used from the ones I brought with.
  • Build scripts for all OS’s (This was a blessing. When I was done, all I had to do was run two scripts, and I had the *.love, *.exe and *.app ready to rock and roll). Sure, mine only work on linux, but they output to everything!
  • Love Menu: There is nothing more wasteful than re-writing a god damn menu system. I wrote this one a long while back, and have used it multiple times. It looks good, and is fully scriptable. Build one giant view object, and let the library do the rest.
  • Bar lib – Again, another common element, this code ended up being a one-liner in my main.lua, but it saved so much time and looked so much better than just a random solid green bar.
• Timelapse yourself. It stops you from screwing around much
• Minimal scope is the best scope. Remember, you can always add more later, but you can’t release a game if it isn’t a game.
• Make sure the art you make can be made quickly, and with high quality – I have recently discovered that I can actually push a lot of awesome pixel art out, as long as I only use two bit graphics (4 colors) So I open up GIMP
• Don’t waste time generating! Making some crap from scratch when you don’t need to is probably a big waste of time! ALl you need is a few cases to make something seem random, why does it actually have to be random? I used this fractal world generator five times, http://donjon.bin.sh/world/ and used that as the map system.
• Forget performance, call it a feature, not a requirement. You won’t believe the shortcuts I took to make this happen, but in the end it goes back to knowing your tech. I wouldn’t have had any of these issues if I had know how to do isometric tiles correctly. Reducing the framerate should have come later.
• Stop bitching, and get working! Seriously, I saw so many people wasting time on IRC bitching about the theme. The themes LD gives are so vauge, you can do just about any thing you want. Oh, folks, stop naming your game “Tiny World” please.

What went wrong:

• Know your tech. Working with isometrics was a god damn horror, and caused 95% of my framerate and mouse issues. Use concepts you are used to. This is not a time to learn new tech, this is a time to produce a game you know how to make. In retrospect, I should have made this game in straight 2d tiles.
• Plan more! I should have planned for another hour or so. I found myself making the game up as I went along, and when I started noticing I was making assets and code that were out of scope, and then later removing them, I had to sit down with my notes again, and decide what the hell I was actually going to do
• Make your machine ready for you. Have your stuff built, make sure it’s up to date, and stable. I had about fifteen minutes to rebuild love 0.8.0 from tag on ubuntu 10.04 (and keep in mind, it doesn’t build if you are running 10.04, so you have to do some hackery)
• Kittens don’t let you code much. They seem to think everything in your monitor is real, and your keyboard is for sitting on.

Conclusion:

What this showed me is to participate even if you don’t have time! I did this entire game in 13.5 hours.

Pocket Strife Entry