About jacobalbano (twitter: @jacobalbano)
Ludum Dare 23
For the last few months, the FlashPunk website has been down, along with the forums, documentation and tutorials. If you’ve been anxiously waiting for it to come back, you’re in luck! The new domain is useflashpunk.net, and we’re working hard to restore as much lost content as possible.
Come on over to the forums and say hi! <3
I participated in my first Ludum Dare almost a year ago, for #23 “Tiny World” and made Humphrey’s Tiny Adventure. It was my first game jam and I had a great time, but the game I made had a long ways to go — despite being technically “complete” it didn’t have any audio and a lot of things were unclear due to the fact that I hadn’t done any testing for feedback before I released.
So…yeah. That’s all I’ve got to say. Go play it!
First of all, I’m in! I’ll be using Flashpunk and AS3 for code, Inkscape for graphics, and maybe Pixitracker and SFXR for music and sound, if I have time.
I thought this might be a good time to introduce some of my helper libraries that I use for Flash stuff. I’ve used them in a number of projects and they’ve been very helpful for speeding up iteration time. Collectively they’re called FLAKit, but I wanted to go into detail about the most interesting parts.
Live asset reloading
FLAKit comes with a program that builds an XML file containing the filenames of all the images, sounds and XML files in the lib folder of your project. When you launch your game, all those files are loaded into memory, and you can access them from anywhere in the code. Here’s how it looks:
var img:Bitmap = Library.getImage("myfolder.myimage.png"); var mp3:Sound = Library.getSound("myfolder.mysong.mp3"); var doc:XML = Library.getXML("myfolder.mydocument.xml");
Since all the assets are loaded at runtime, live-reloading is possible. It’s extremely easy; just press F5 and all the files will be loaded again. You can even set a callback that will run when loading is complete; on my last project I had it set up so that the scene I was working on would be restarted when the assets were reloaded, which decreased the time I spent iterating on level design by a huge amount.
You can also switch over to embedded assets (necessary for release mode) without having to modify your loading code at all with the Embedded library builder program.
FLAKit also comes with an in-game console that uses my (extremely experimental!) AS3 scripting language Slang. At the moment it’s not very useful for anything more than simple commands, but I’ve found it very useful for things like toggling debug mode, switching between scenes, and adding health to the player.
FLAKit has been open-source from the beginning, so technically I don’t need to declare it, but it’s been very useful to me and I thought some of you folks might want to play around with it in the days leading up to LD.
…but it looks like my participation is a bit up in the air. I’ve got a friend staying the week and I’ll be compelled to be hospitable. In any case I won’t be able to have any development time on Sunday due to previous commitments.
I’m really hoping to be able to join in, since I had a blast the last time (which was also my first time). If I end up finding the time, I’ll be using:
- Haxe for my language
- NME (or a library built on it) for my framework
- Flashdevelop for my IDE
- Inkscape for my graphics
- My Casio keyboard for music, if I manage to find the time and talent to produce something that doesn’t cause bleeding from the ears
- Probably also the Casio for sound effects
Best of luck to everyone else who’s joining in!
I’ve known about Ludum Dare for a few years now, but every time it came around I would end up having too much to do in real life to participate. This time I was finally able to get involved, and it was one of the best things I’ve done in a long time, resulting in Humphrey’s Tiny Adventure, a point-and-click adventure game. Here are a few lessons I learned along the way.
Do as little brainstorming as possible
I knew from the beginning that I wanted to make an adventure game. At 9:00 PM the first day, the theme was revealed and we were able to get started. I spent 15 minutes sketching out some basic ideas and then got right to work. Not everything I wrote down made it into the final game, but it allowed me to get started quickly and add details as I went along, instead of trying to develop a complete design doc or storyline.
Get all your tools and libraries ready to go beforehand
This is a bit of a no-brainer, but I thought it was worth mentioning For this project I used FlashDevelop for my IDE, Inkscape for graphics and Chronolapse for screencasting. Since all three of those are necessary to get started, it wouldn’t do to have some programs downloading after the compo officially started.
Pick an art style that you can produce quickly
I’m mainly a programmer, and while I am capable of creating some reasonably impressive vector art, I certainly can’t pump out high-quality assets fast enough to make it a viable option for a game jam. I decided on an art style that consisted only of colored rectangles, which allowed me to keep my art simple, uncomplicated, and abstract enough that realism wasn’t a concern.
Use release-quality art early on
Chances are if I started out using placeholder art I would just continue using it until I ran out of time. Creating final art assets in the beginning helped me have a feel for how much work it would be to bring the project to completion.
Use version control
If you aren’t using version control already, start now. The first thing I do when I start a new project is create a new local Mercurial repository, and it’s saved me many times in the past. Using version control can save you if you mess up your project too badly, or retrieve old versions of your files if you decide that the first iteration of your player class is the better one.
Record a screencast
Keeping a video running of my work helped to keep me from getting distracted. If I wanted to update my progress on twitter, I had to open up Chronolapse and pause the capture, and even that small amount of required action was enough to keep me from constantly tabbing over to check my email.
Take breaks and get enough sleep
Whenever I came across a tough problem or design decision, I got in the habit of getting up from the computer and making myself a hot cup of tea. As much as it might seem like it’s necessary to spend the entire 48 hours in your computer, the best thing you can do for yourself is to take it easy. If you overwork your brain you won’t be able to think clearly and therefore won’t be as productive as you could be.
I think that’s about it! I had a blast participating, and I’m definitely planning on doing it again.
24 hours down, 24 more to go! I’m feeling pretty optimistic about finishing this on time.
Here’s a playable build of my game, Humphrey’s Tiny Adventure (just open it in your browser). Source code and such is all available too. Beware of ye bugs and such, obviously.
This is my first LD and it’s going extremely well so far. I decided to use Flashpunk instead of my own framework, and it was definitely the right decision.
I’m making an adventure game called “Humphrey’s Tiny Adventure”. It’s about a boy who has to find his penguin after he runs away from home because he feels neglected.
And here are the characters:
Two levels down and three to go. Most of the art is already done as well.
So this is my first Ludum Dare. I’ve been wanting to participate ever since I first heard of it, but never actually hunkered down and joined in. High time that changed.
The main reason I’m writing this is because we’re supposed to declare any personal codebase that we’ll be making use of. My current plan is to use my experimental Haxe library Astral, which I wrote from scratch to learn the language.
So…that’s about it. Let’s do this thing.