First off, you can see my game’s page here or you can skip to just playing the game here.

Hi there! Yes, I am already done with my entry, as I had plans that I knew would occupy nearly all my time Sunday, so I turned in my entry last night. If you’re not done yet… get back to coding! But please read this some other time.

You can read my pre-compo post here. Anyway, here’s how my game MESSNGNR ended up looking:

Concept

In the past week I had been messing with some chromatic aberration code for a non-gaming project. When I heard of the theme of Connected Worlds, I eventually came up with a game (late at night, right before falling asleep) where the red, green, and blue channels were individual worlds that were linked somehow. An object in the blue world might block your progress in the red world, maybe you could switch between worlds, and so on. I jotted down the idea, and while traveling out of town, managed to awkwardly code the basic rendering layer on a fold-out tray in a crowded airplane.

Audio

By far my favorite part of the final product is the audio. Weird, glitchy sounds are a personal favorite of mine, and I think I pulled them off pretty well. I used a variety of speech synthesis programs, mainly eSpeak to generate the voices. I then chopped them up and edited them in Audacity, which even has a built-in DTMF generator that game in handy. I also generated a bunch of noise using it, and varied the volume randomly with code.

Engine

The game is written in Haxe and uses the HaxeFlixel and OpenFL libraries. The core gameplay code is entirely HaxeFlixel, but instead of rendering directly to the screen, the FlxGame class, which is normally the foundation of the rendering code, is entirely invisible. Every frame, a RenderManager class grabs the FlxGame’s pixels and copies the red, green, and blue channels individually to its own displayed BitmapData, plus some error on the X and Y axis (if enabled). The code is a bit messy, but it works pretty well, and I’m happy with the visual style that I achieved.

Shortcomings

Yes, I missed the targeted game by a long shot. The final game never has obstacles in a single channel, never displays multiple channels separately, and is incredibly short with no real ending. For reference, I had planned the game to look something like this when you start:

With only one channel (in this case, blue) showing up. The messages (if you chose to read them, more on that later) would hint at another world that was causing issues in their own. Eventually, you would be able to see the other world, which would be another channel:

(These are just quick mock-ups by the way) So, in this example, the box only exists on the green channel, and it would block you in both channels. Eventually the channels would move, overlap, have conflicting information, be skewed funny, etc. I thought there might be some kind of item that lets you switch between channels as well.

Messages

The core gameplay that I did get to implement was the idea of being a messenger; carrying a message from a Sender to a Receiver. Optionally, you can choose to read the message, but as this is not what a messenger is supposed to do, there is a penalty. The scoring system is very rudimentary; you either get a random six-digit score, or zero, the latter if you read the message. There’s supposed to be some meta-commentary there about quantum mechanics and how reading an encoded message in a quantum computer would destroy it but… I’m not smart enough to elucidate on that without some heavy research.

Etcetera

I’m pretty happy with what I made in about five or six hours. I might revisit the concept at some point in the future, as I think it holds a lot of potential for further exploration. Until then, thanks for reading, and let me know what you think of the game!

Hi! My name’s Steve, and I’m a programmer at Dream Show Adventures. This Ludum Dare, we created Chacket Valleyparker: DRILL BUNNY, and I thought I’d share my thoughts on the experience.

Last time around, I did Ludum Dare with my kids, creating most of the content myself. However, I’ve since joined the team at Dream Show Adventures, and I wanted to get the group to contribute. Luckily, it wasn’t a tough sell!

Planning is 90% of Something

Last time around, I did almost no prep work at all, and it really bit me. This time, I resolved to have things set up well in advance. I knew I wanted to use Phaser, but I’m still learning the ins and outs of serious JavaScript development. I knew NodeJS and Grunt could help me automate, and I wanted to use Travis CI to build to a Github page automatically from our source repo. I also found a pretty good Phaser template to work from. It was a bit outdated, but that was fixed easily enough.

Initially, we had two programmers, two artists, and a musician on board. Unfortunately, one programmer couldn’t contribute, and one artist and the composer dropped out at the last minute. This left us with one artist (Andrew, who also serves as creative director) and one programmer, myself. This was unfortunate, but not unexpected. Still, it meant more work for the two of us.

Beginning of… the Beginning

When the theme was announced brainstorming began immediately. The bunny/drill concept came about pretty quickly, initially as a bit of an inverted shmup starring Chacket Valleyparker, a character that Andrew never got to use from an earlier project.

Getting started with Phaser was fairly easy, and we had a very very basic prototype quickly. However, I was dependent on Travis to build a working copy of the game, which meant that testing was painfully slow. Attempts to run the game locally failed, and I still don’t know why. Searching for solutions online made it very apparent that the current system wasn’t working, despite my attempts to plan ahead. That’s when I stumbled upon Jeremy Dowell’s fantastic Flappy Bird Phaser tutorial, but more importantly, his Phaser template building tool.

Unfortunately, this new template would require a lot of re-work. With a heavy heart, I implemented the new system, losing all of our progress in the process, with the hope that it would save time in the long run. I also stored my github credentials via winstore after another method to store username and password failed, and wrote a simple batch command to make updating the repo easier.

Gaining Traction

It wasn’t long before we had a playable prototype. Unfortunately, we had already lost about 24 hours in getting to this point, when ideally I prefer going to bed Friday night with something that works at least as a proof-of-concept.

With Andrew spriting rapid-fire, and new features going in all the time, there was great momentum until about noon Sunday. That’s when I decided to implement a procedural tilemap generator for the background dirt. Basically, each new dirt block would see what was above and to the left of it when created, and pick from a subset of dirt blocks that would look nice next to the others. Unfortunately, I couldn’t figure out how to implement this, and went through 3 complete systems (each taking several hours to code) before I found one that worked (and was severely scaled back from the original system). Early on I thought that I would have to simplify, but my hubris prevented me from accepting this early, when it would have saved the most time.

Sleep. I just want sleep.

The last day, I was very tired. However, we had some happy accidents. While our composer was still absent, Andrew had some great tunes he had made but never used, and we decided to put them in. Furthermore, my day-and-a-half of experience with Phaser, as well as digging through the docs extensively, made coding quick and painless. I was even able to add some localization (if your computer or browser’s language is set to Chinese, Spanish, French, German, Italian, or Japanese, the title screen should load in that language) to the title screen, and I fulfilled my promise to let my kids help somehow by putting some apples they drew on the title.

At the end of the day, it was down to the wire. I scrambled to get a decent ‘game over’ screen, as we hadn’t bothered with one prior. Including the company name was important, and almost got overlooked entirely! The boost mechanic was the last thing to go in, and was only fully functional about one minute before the deadline. Even now, boost speed doesn’t scale over the course of the game (unlike the normal speed or I made sure that the variables most likely to need tweaking (turn speed, damage from different objects) were simple to find, and Andrew tweaked as needed while I focused on code. We pulled together, and we’re proud of the final product.

Unfortunately, we couldn’t get to everything. Money was originally meant to be used to buy upgrades, with Chacket returning to the surface every time the drill overheated, visiting the store, and then trying again. Worms were meant to get in your way, and you would have to pay their medical bills if you touched them with your drill. Moles were also planned, but not drawn or implemented. I was also searching for a way to minimize the likelihood that rocks would overlap lava, but it’s quite common. Also, we were hoping to scale up the difficulty as you got deeper, but that never happened, and the game is fairly easy. There’s also no true win condition; originally, you were trying to get to the core.

What now?

Well, that’s where you come in. If we get a positive response, we’d love to develop DRILL BUNNY into our original vision, a sort of inverted shmup roguelike, where “death” (the destruction of your drill) forces you to upgrade and try again. Otherwise, it’s back to work on Pipeworks, a game that is near and dear to our hearts, and has been in development for quite a while.

So, please provide feedback — negative and positive — here and on the game’s page — so we can ensure that Chacket’s future lives up to everyone’s dreams. Thanks for playing, and keep digging!

Alright, so everyone seems to be posting about the stuff they’re using, so I may as well share. The IDE I’ll be using is FlashDevelop, writing in Haxe and using OpenFL and probably HaxePunk; I’ve been meaning to learn that for a while and total panicked immersion seems like a good way to go. I’ve used HaxeFlixel which is sorta similar, and FlashDevelop has great code completion, so I’m not too worried about being out of my depth.

All art assets will be created by my kids, as I mentioned previously. We’re not sure if they’ll be drawing on paper that I scan, or if I’ll just turn them loose on Paint.NET. They might use Android paint apps; the second piece below was done in Serious Paint.

And now, I turn it over to my kids, who have decided the team name, their handles, and some promotional art. First, my eight-year-old son:

Our name team name is SMILEY WORLD

MY NAME IS BURNING TIGER !!!!!!!!!!!!!!!! I HOPE ALL OUR GAMES ARE FUN AND THEY MAKE EVERY BODY PLAY THEM.

Now my younger son, who is four:

My name is BURNING WHEELS. I’m 4. I drew that guy.

That’s all he had to say. Good luck in the jam, folks!

My name is Steve and this is my first ever Ludum Dare. I’m doing it this year with my two kids, who will be designing the overall game concept and drawing the art, leaving me to scan drawings and code whatever they come up with. I can’t wait!

A bit about me: much earlier this year I released GNOP! Flash, a Flash remake of Bungie‘s 1991 hit GNOP! which was a Pong clone made by one guy. More recently, I made Don’t Move, which was my first original game.

A bit about my kids: they love Minecraft, Cave Story, Treasure Adventure Game, and any Lego game. They are determined to put a bow & arrow, laser blaster, and sword in our game regardless of theme.

Okay, so that’s it for now. Good luck in the jam if you’re participating, and have fun playing the games either way!