Thursday, December 12, 2013

Ludum Dare #28; "I'm in!"

I've posted about LD48 on other forums, but I want to write a quick note about it here on the blog, as well. Maybe it will help catch a bit more attention, too. Every little bit helps! ;)

Ludum Dare #28 is starting this weekend! I will be participating, and streaming my progress live on Twitch for the full 48-hour duration. Everyone is invited to join and get involved! I'll be accepting suggestions and ideas live. (I cannot accept any resources like graphics, code, music, or sound effects, as that is against the compo rules.)

I will be making an HTML5 game using melonJS, which I will be semi-frequently publishing to github. This means you will be able to load the game and give it a try as I'm making it. I'll get instant feedback and play testing, and you might get to see your suggestions added in minutes! That's pretty awesome.

You can catch the live stream on Twitch starting Friday evening at 6:00pm Pacific (GTM -0800). The link is:

Also, be sure to follow me on Twitter, so you can keep up-to-date on any project news and streaming announcements: @kodewerx

I have my streaming setup tested and ready to go! No telling what I will make yet. It will probably be something totally random, based on whatever theme is chosen. In any case, thanks to everyone who has said they will drop in! I'm really excited about this. It will be my first Ludum Dare, and first live stream event. I'm thinking it will be full of unintentional hilarity!

See you Friday!

Monday, December 2, 2013

A Walk in the Park Turbo: #1GAM November and #CharityGameJam II Turbo

A Walk in the Park Turbo

(Clicky for Make Big)

It's been a looooooong time since my last #1GAM entry. This time around, I started making a classic text adventure; a project I've been wanting to do for at least month. I was heavily inspired by a documentary called Get Lamp.

The game is called "A Walk in the Park Turbo", as it lovingly shares the moniker for #CharityGameJam II Turbo. The Charity Button (visible in the animation) points the player directly to the donation page for Child's Play Charity. Don't forget to make a contribution!

About the Game

"A Walk in the Park Turbo" follows in the footsteps of the earliest video games, which can be classified under the genre "interactive fiction". If you've ever read a "choose your own adventure" book, you know exactly how these games play; the player is thrown into a scenario, and left to her own devices to discover the correct actions to claim victory.

The classic text adventures are remarkably minimalistic, but can be surprisingly deep. AWITPT was made in just two days. And though there is not a whole lot to actually do, the biggest parts of the game were made near the end of that two-day sprint. Most of the development time went into building the core foundation. Which is a shockingly simple JSON data structure that the game dynamically modifies as you make your way through the puzzles.

How to Play

Text adventures are notorious for being difficult to get a grasp on. Especially for beginners. Because the user interface is all about typing commands, you'll find yourself stuck often until you can figure out which commands the programmer expects you to type ... and sometimes even in the proper order!

The general recommendation to get started is to try typing different words, and see what happens. In AWITPT, the commands are almost always verbs (but they can be shortened in some cases). There are movement commands, like "go" or "walk" which also expect a direction. Or you might be able to shorten it to just the direction. Another common command is "look" or "search" to look at your surroundings, and at items that may be available in your current location. You can also take items, and use items, check your bag (inventory), and inspect or use items in your bag. Items in your bag can also be used on some of the stuff you see in the area.


Text adventures are all about puzzles; How to find the right items, and use them correctly to unlock new paths. AWITPT is no different! To date, there are only 6 available areas, with most of them serving a purpose of gaining one or more items. Getting into two of those area requires using one of the items you can collect. ;)

Music and Sound Effects

I composed the music many years ago, originally as a soundtrack for a short film idea I had, called "Milksharks". The concept was a bit absurd and comedic; tiny sharks that swim around in your cereal bowl. The film never got started, but I was inspired enough to create a short music track for it. It's a calm tune that starts with an upbeat cello, and evolves over to other instruments.

The soundtrack is available on Soundcloud.

All of the sound effects (the punches and kicks on the logo) were sourced from CC0 (public domain) sounds made available on

The Future of A Walk in the Park Turbo

Like I mentioned at the beginning of the article, this genre is one I've really wanted to try my hand at. So I'm glad I've finally got the basis for it worked out. I'm sure I'll come back to this one to add more areas and stuff to do. I don't actually have any story elements planned for it. I want to just let it evolve naturally. In a very silly, almost dream-like game world. The best part about making a text adventure is that anything I can imagine can be put into the game. As realistic or as fantastic as I like. This game is truly a medium for artistic expression.

Apart from adding the more areas to explore, I also want to add some pretty visual effects. The game is written with a 2D canvas, so why not use it! Audio is another thing I want to highlight. Both of these enhancements will feel very much out of place in an old school text adventure. But that's really what I'm going for, here! Bringing a classic genre up to modern standards. The addition of the "Turbo" subtitle kind of sets that stage, both in name and in its very introduction on the title screen.

Make Games ...

Play online :
Source code :
#CharityGameJam :
#1GAM :
Twitter : @kodewerx

With that, I will leave you with my traditional closing statement;

Make Games, Support Charity!

Wednesday, May 1, 2013

1GAM April: Postmortem

Sprung Fever

(Clicky for Make Big)

The game is officially complete! I just added the last remaining bits (item sprites, courtesy Matwek!) and I also released the game earlier today on #1GAM.

And now it's postmortem time! YAY!

Development Process

melonJS 0.9.7 is a real pleasure to work with! This game ships with a build that is about as close to final 0.9.7 release as possible (there may be a patch or two that gets committed between now and release, but it's effectively the same). The new features that I made extensive use of this time were:

  • TexturePacker support
  • JSON TMX map support
  • me.Renderable
  • me.sys.isMobile
  • me.Viewport.shake
  • TMX settings JSON parsing
During development, plenty of bugs were discovered and fixed, which is nice for the melonJS community! I'm super pleased with how melonJS 0.9.7 has turned out!

What Went Right

Wow! What can I say? Both artists did great on the assets they were able to deliver, and it all works together as a cohesive whole! Great job and a huge thanks to both Matwek and Burcag!

On the coding side, everything went rather smooth... There's lots of fancy stuff happening behind the scenes and on screen, so keep a look out for it! The fullscreen overlays worked really well, and they were incredibly easy to build. Girl AI is basic, but it gets the job done. The particle emitters are flawless. Mobile control works well (if a bit lacking in tactile response). And the sound effects make me really happy.

My favorite of all sound effects is the heartbeat. But it's so bassy, you can only hear it with good headphones or a subwoofer. That's actually a plus, as well, since playing the game with a good sound system is PHENOMENAL. And even though the music is completely auto-generated (with some tweaks) it's still catchy enough to get stuck in my head.

The gameplay also turned out to be incredibly fun. A coworker asked if she could play it last week, so she became the first play tester in the office. Her reaction was priceless. That's when I really knew it was a good game. It's definitely the most fun of all my projects so far.

What Went Wrong

Even though I have been working with two artists this time, I still feel like getting art assets has been troublesome. The girl in the blue dress was never animated for up/down movement, and the environments feel a bit repetitive/on a grid. (If you've played Neverwell Moor, you'll see what I'm talking about; that game hides the grid quite well, and it's all thanks to the art assets!)

Music was VERY difficult. I spent a lot of time just screwing around until I had something that I liked. If I had more patience with it, I would teach myself to make chiptune-sounding music in GarageBand. Or else I get music that sounds pretty nice, but doesn't fit the old-school theme. :(

This project sounds pretty simple on paper, but in reality it was a lot of work! There are just so many variables, like player control, collectable items, game stats (HUD), enemy AI, etc. But the biggest time consumer for me was probably mapping. Definitely not my favorite thing in the world... And it's frustrating to be working on a map and realize half way into it that you're missing a rather vital tile. You might notice some funny looking shadows on the left and right side of the grocery map! Well, that's because there isn't a tile for left and right walls that also don't have the shadow. Just a single example of many...

And finally, I started this project later than I should have, giving us only 3 weeks to work on it.

What To Do Next Time

Too many cooks in the kitchen! I'll have to work with just a single artist on my next project. I ended up doing about 1/4 of the graphics myself. I would like to get to the point where I do 0% of the graphics. Just like the artist would expect to do 0% of the coding. It just makes sense...

And I still need a musician. :)

1GAM April: Day 23 (Finale)

As of tonight, I am done with the 1GAM April project, Sprung Fever. Regretfully, it is identical to last night's build. I got caught up with other things tonight, and the artists working on the project were unable to complete the last remaining assets for the last day of the month.

However, this is only the end of the initial development cycle! And as new assets come in, and new ideas come up, they may very well find their way into Sprung Fever.

I'll have a full postmortem for the project in the coming days. In the meantime, enjoy the game! And I'll be starting a new project within the week. As well, I'll pick up where I left off with the new collision detection system for melonJS. That should be completed for 0.9.8 in about two months! And 0.9.7 is coming literally any day now... Things are really looking great so far!

That's it for now! See you in a few days!!

Monday, April 29, 2013

1GAM April: Day 22

Sprung Fever

(Clicky for Make Big)

Library is finished! And this is a very difficult one. I haven't been able to complete it yet. ;) But there's an ending screen if you manage to make it through!

So that gives us two stages. It's awfully short, but a lot of fun to play.

I've also added some new sound effects to the game, which adds to the overall experience. There sounds for are 8-bit foot steps, sweat drops, and a crash for picking up bad items. Speaking of the bad items, they also have a negative effect now, and will instantly drain half of your attention! D'oh!

The only things that's *really* missing for a complete game is the item images. Although having an intro and real ending would be nice, as well. :) With just one day left in April, maybe I will come up with something! See you tomorrow!

Sunday, April 28, 2013

1GAM April: Day 21

Nothing new to report on 1GAM today, either! Spent some time with melonJS documentation again, watched some videos, had a nice nap, and planning for my next projects... That's all!

Tomorrow I'll be back on April's 1GAM entry to finish up the Library. And if there's time, add an end sequence! Anything else left in the month will just go to bonus additions. :) See you tomorrow!

1GAM April: Day 20

Skipped a day to work on other stuff!

  • melonJS documentation overhaul
  • Planning and design on Ludum Dare entry (still unsure if I will enter)
Will be back on Sprung Fever tomorrow!

Saturday, April 27, 2013

1GAM April: Day 19

Sprung Fever

(Clicky for Make Big)

Library! Tonight I have started the Library! There are no girls, and the maze is only half complete. But it's a start. The three errands are all too easy, but that will be solved when the girls come in...

I'm also considering doing a new Ludum Dare project tomorrow! If I do, it will be a ridiculously small game (cramming a game into only about half of the available time... could be quite tricky!) But I think it will also help relieve some of the stagnation I'm starting to feel with Sprung Fever. (I love this game! But like all projects, this one is wearing on me.)

Perhaps also for my 1GAM May, I will limit myself to a much shorter development cycle. I have some other work that can be done, anyway. Mostly melonJS 0.9.8 stuff. :) We already have a pretty good collection of tickets lined up for it after the 0.9.7 release.

Final note; one of my artists is away on holiday for the last week of the month, so I will likely have to fill in the gaps for the final stretch. If I can come up with a third scenario that will be easy to draw, then I'll just do that. And then again, maybe the other artist can do some tiles and finish up whatever is left. That would be especially helpful!

Good night! See you tomorrow!

Thursday, April 25, 2013

1GAM April: Day 18

Sprung Fever 

Springy flowers! These are pretty cool actually :) The flowers are on "springs" drawn with a bunch of bezier curves that are animated with lots of trial-and-error. With a little variance on the cycle for animating the X/Y position, it gives a "springy" look. The flower rotates a bit as well which helps with the effect. No physics! Just a ton of "shortcut" maths for this one...

I also removed the yellow flowers from the background. They looked too distracting and ugly.

Finally, I also fixed the blurry errands note on iOS. I just upscaled the image by 1600%, because scaling down on iOS isn't nearly as ugly with the forced bilinear filtering.

Tomorrow I plan to work on the library (I need more tiles for this) and probably add some more girl variations. Mostly the new girls will just be palette swaps. :\ But I can give them each different AI, so different strategies will help while playing. It will be fun! See you tomorrow!

Wednesday, April 24, 2013

1GAM April: Day 17

Sprung Fever

Things are starting to slow down. :\ I guess it's just that time! It really is difficult to keep a fast pace for more than a few weeks.

Anyway, I added entity pooling as an optimization (may be noticeable on mobile?) And updated the title screen with some flowers... Not sure I like it as much as the plain grassy field.

I started on the flowers for the logo, too. But ran out of time for tonight. They will be animated and quite "springy" when complete! But until then... See you tomorrow!

Tuesday, April 23, 2013

1GAM April: Day 16

Play online

For today, I've fixed the mobile UI controls! It took a while to figure out exactly what was wrong with it, because it's not very intuitive. Basically, I have to keep track of every touch event by id that ever occurs, and iterate through that list, not the list provided by the event. That's because melonJS provides only the `changedTouches` list, and ignores the complete list of touches.

This sounds like a feature request here; include the `touches` list and `changedTouches` list like the spec! That would mean I won't have to track touches myself, just check `me.input.touches` in my `touchstart` handler, and `me.input.changedTouches` in my `touchend` handler. Done!

I also discovered in testing that mobile Safari is terribly slow on my iPhone because the game object count rapidly increases until the browser crashes. I haven't seen that on Chrome though, and I haven't verified it with CocoonJS yet. So that's going to need some investigation.

That's it for now! See you tomorrow!

Update: Fixed the object count problem. :) Actually, it's just a workaround within melonJS, but it's really helpful for this game (uses lots of Tweens!)

Monday, April 22, 2013

1GAM April: Day 15

Sprung Fever

(Clicky for Make Big)

Super quick update for tonight! I added a first iteration for mobile UI/touch controls. It has some bugs, but it gets the idea across! (The UI is only enabled for mobile devices.) I actually spent about an hour in Gimp making the buttons. They turned out acceptably.

I also discovered with this new feature that the game runs very poorly on iPhone 4S in Safari, but runs great on the same phone in CocoonJS! Way to go Ludei! Again. ;)

Final note: I also fixed a minor bug where the sweat particles would collide with the environment. Oops! Hehe!

Sunday, April 21, 2013

1GAM April: Day 14

Sprung Fever

(Clicky for Make Big)

Aw yeah! Day 14! Two weeks down! Just one more to go. (I really need to break that habit of starting late...)

Finally I've added a title screen, which you can see above. It could be way better with some artistic talent (or a lot of time) but I already spent hours on it (because I have no idea what I'm doing). So that's the end result! Hooray!!

I actually do want to make the title screen a bit more juicy. For starters, I want to add some flowers (being "spring" and all) and I'll probably stylize one or two and make the stems bouncy springs. That should be fun! But I've had enough title screen madness for one day...

Anyway, there are a lot of new goodies in this update that you'll find after the title screen! I continued working on things late into the night after yesterday's update to get all of this crammed in. So here's what's new:

  • Brand new HUD (semitransparent background, new meters based on Burcag's design, and a heart rate indicator)
  • Added the "redness" overlay nervous effect.
  • Added "sweat" particle effects as a nervous effect.
  • Tweaked all of the sound levels.
  • Added a "heartbeat" nervous effect.

The heartbeat nervous effect is probably my favorite thing in tonight's update! Play with headphones or a really good subwoofer. ;) The heartbeat sound effect is very bassy, so you won't hear anything with standard laptop speakers. But really, it's the entire ensemble of nervous effects that make it entertaining to avoid the girls while collecting items. I've fallen prey to panic on multiple occasions while testing this game. It's certainly the most fun to play of all my projects. (But more on that later!)

Ah, finally it's starting to look like a real game! This is the point of the Cousins Graph where the curve is starting to break away from "shit". And one of my favorite parts of the development cycle. :D

Saturday, April 20, 2013

1GAM April: Day 13

Play online

For Day 13 I've started on the second stage; The Library! I used again to create the music, but didn't spend as much time on it. As a result, I think it's not nearly as catchy. (But hey! I'm not a musician!)

The other changes for today are; level change/restart transitions, and new door tiles by Matwek.

I also spent some time doing some behind-the-scenes work, like a very minor bug fix for melonJS (and pulling in other updates for it) and moving the errands list animation into the correct module. These changes don't affect gameplay at all, but it's worth mentioning how my time is spent on this project. (That's one of the goals of this blog, after all!)

I didn't get to the title screen work yet. I'll start on that shortly. And if I finish by tomorrow, it will even be the screenshot for Day 14! See you then!

Friday, April 19, 2013

1GAM April: Day 12

Play online

Tonight's update is all about minor tweaks! The first thing you might notice is that I adjusted the errands list so the text is rotated with the paper. It just looks more natural. The text still stays the same size when the note is scaled into the corner.

The second thing you might notice is the new door animations! They currently only open for you (the girls will just walk through while the doors are closed). But it's a much needed effect!

Another minor tweak makes the shaking less violent (and the delay before it starts is longer).

The final change that you may or may not notice is that errands are completely functional! If you collect all of the items, walk to the edge of the map to complete the stage. Currently the stage will be restarted, because there is only one map.

Tomorrow I plan to start working on a title screen, and maybe adding some more juiciness. I have another animation that I need to add for the "losing attention" effects, and I want to get some more sound effects in there as well. The other attention effect that I should consider is adding some redness to the edges of the screen. Probably just another static overlay image made with a grunge brush! Dynamically changing its opacity will complete the look.

Hooray! See you tomorrow!

Thursday, April 18, 2013

1GAM April: Day 11

Sprung Fever

(Clicky for Make Big)

On day 11, I finally added the errands UI! It's kind of ugly (I drew the "piece of paper" as a placeholder) but I made it juicy with some Tweens on startup. So there! :)

The items are marked red until you pick them up. You'll also be rewarded with a sound effect when collecting items, so that's nice. You'll notice I haven't listed the junk food items. I want to make those like a "power down" negative collectable.

Oh, and the scaling effect was made possible by melonJS now disabling the "image smoothing" algorithm by default. Without that, it would look extremely horrible. Hooray for pixel-preservation!

That's it for now. Tomorrow I'll try to finish the errands integration. (Collect them all and leave the map to win! Collect too many negative items to fail!)

See you tomorrow!

Wednesday, April 17, 2013

1GAM April: Day 10

Play online

Super small update tonight! First I fixed a bug in melonJS' TexturePacker support that was discovered yesterday. Unfortunately by the time I noticed the bug last night, it was already really late so I had to get to sleep.

With that one solved, I quickly added a basic particle effect for floating hearts that will be emitted from the kid when his attention is on the girls. The hearts also get emitted faster when you are low on attention. It's quite amazing what can be done with just a little maths. :)

And! That's it! Tomorrow I'll focus on HUD and Errands UI, and probably some basic sound effects. See you then!

1GAM April: Day 9

Play online

Tonight I spent too much time in Tiled trying to update the map with a new tileset layout (that hurt!) and splitting the new girl animations into individual images (also hurt!) So that's all there is for the update! A few new graphics. :)

I'll try to sort out the preprocessing troubles. It would save a lot of time if I had readily-usable animations and don't have to completely rebuild the map with a new tileset.

There is a lot more I was hoping to get done. Especially in the UI and sound effects. Otherwise, progress as usual!

See you tomorrow!

Tuesday, April 16, 2013

1GAM April: Day 8

Sprung Fever

(Clicky for make big)

Tonight we've got a new map for you! You'll start at a supermarket, surrounded by some pretty ponds. There are tons of girls shopping today! :S ... Collect the items, but don't get too nervous around the girls! Or you'll have to start over.

This update does not have as much as I wanted to add for the night. It took a long time to build the map, and I still don't have enough tiles to add a great deal of variance for an entire shop. I also put some super basic items in (with placeholder text, until I get sprites). The items can be collected, but there's no UI for it yet.

The last thing I added was a simple but effective "scanline" and "halo" effect, which works well with the scaled pixel art.

And now it's really starting to feel like a game! :D It can get ridiculously frantic trying to collect the items, but it's not impossibly hard. I might need to do some more tweaking on things that affect the level of difficulty. Any comments or suggestions would be appreciated at this point!

Last bit of info to note! I also have some new art assets that I didn't get a chance to add tonight. There's a new girl, and some animated effects for the "nervousness". Also the status meters on the HUD will be redone sometime soon, since I also have a new design for those!


  • Errands. (WIP)
  • Better AI.
  • Sound effects. (WIP)
  • More music.
  • More girl sprites with different AoE radii. (WIP)
  • More varied backgrounds and a better starting map. (WIP)
  • More maps. (WIP)
  • Title screen.
  • Game Over screen.
  • Ending.
  • Transition screens (explaining the objective for the map).
  • Anything else we want, if there is enough time...

I've added "WIP" (Work In Progress) to the items that are already started. You'll notice the "sound effects" item has been started, but none appear in game; I have located some sound effects that I would like to use, but need to sort out licensing, and probably do some post-processing work. (Volume normalization at the minimum. Probably some clipping and mixing work, as well!)

See you tomorrow!

Sunday, April 14, 2013

1GAM April: Day 7

Play online

Tonight, the biggest notable change is the addition of the first music track! It's a pretty happy 8-bit-esque tune, made by not very simple means, but entirely as procedural content. I played with some random seeds for about an hour on until I had a tune that was upbeat and felt nice on my timpanum. After another few hours of tweaking, I decided to call it final. The name of the track is "Grocery", as it's intended to use in a grocery shopping scene, where the objective is to purchase a handful of items (all while avoiding the girls, of course!)

The other thing you might notice is a new set of "nervousness" effects. I'm not happy with it, yet. But you'll see the screen shake as you run out of attention, and the shaking gets more violent as you get nearer to the threshold of failure! The character controls will also reverse on you, making it even more disorienting. With these effects in place, I think the attention meter actually drains too fast, now. That just means more tweaking for later!

I'm still waiting on additional artwork, but there is still a lot I can do in the meantime:

  • Errands.
  • Better AI.
  • Sound effects.
  • More music.
  • More girl sprites with different AoE radii.
  • More varied backgrounds and a better starting map.
  • More maps.
  • Title screen.
  • Game Over screen.
  • Ending.
  • Transition screens (explaining the objective for the map).
  • Anything else we want, if there is enough time...

I put errands at the top as a means to remind myself that it's going to be my highest priority for tomorrow's update. I believe it won't be much trouble to include the errands list in a map property, which just references objects by name. For example, the grocery store map will have errands to collect milk, bread, vegetables, etc. And there will also be a collectable item named "milk", and another named "bread", etc.

The errands UI could get fancy. I'm planning to draw a sheet of notebook paper that will be Tweened onto the screen at the start of the stage, listing all of the items for the errand. Then the paper will be Tweened into a corner, but the font will remain original size (so it's directly readable). Depending on difficulty level, it could also disappear completely after you've seen it once.

Another idea is to have the kid start out with limited monies, and allow the player to purchase items that are not on the list (oops!) Then it becomes a game of skill, balancing your attention level, errands list, and available resources! But it's just an idea ... I don't want to start breaking scope. ;)

See you tomorrow!

1GAM April: Day 6

Play online

Tonight's update includes sprinting (hold Shift) and regeneration of attention. Behind the scenes, I changed the attention meter class into a more generic HUD meter class, which works very well. I also killed the HTML meta viewport tag, since that was breaking the display on iOS. (WTF?)

The TODO list is still quite long:

  • More girl sprites with different AoE radii.
  • Better AI.
  • More varied backgrounds and a better starting map.
  • More maps.
  • Objectives/errands.
  • Title screen.
  • Sound effects.
  • Music.
  • Game Over screen.
  • Ending.
  • Transition screens (explaining the objective for the map).
  • Anything else we want, if there is enough time...

I've made some explicit requests to the artists for tilesets and sprites that I'll need to finish the objectives and map for the first stage. I'm hoping to get something from that end by tomorrow so I can build an actual map that will be used in the final game (no more test map!)

Saturday, April 13, 2013

1GAM April: Day 5

In a race to hit the deadline for the melonJS 0.9.7 release later this month, I decided to spend my free time tonight working on the new collision detection again. I was able to make to another 25% faster (!) but at the cost of losing sub-pixel velocities. :( The good news is it should be possible to work around the issue and support sub-pixel velocities again while retaining the nice optimization that made it faster.

It all has to do with how often objects are checked for collisions. If the object is not moving, don't run collision checks on it! Sounds simple enough! But what happens when the object is moving by less than one pixel per frame? It's not going to generate any new collisions every frame at such a low velocity, so the collision checks also should not run each frame.

There's some trouble predicting when a slow-moving object might generate a collision, though. First, because the object's position is only updated after collision detection has run, and a collision response has been calculated. The collision response is what gets added to the object's position, not the "requested" velocity. So if the collision detection isn't run because the object is moving too slow, and its position isn't updated because collision detection didn't run, how do we know when it's time to actually update the position?

I suppose an illustration would be helpful, but please bear with me for a moment. Let's say an object has a velocity along the X-axis set to 0.2. That means, every frame, the object will move 1/5 of a pixel to the right. In other words, it will move exactly one pixel right after every 5 frames. So it only makes sense to check collision detection on this slow moving object every 5 frames, after it has had a chance to move one full pixel. That's where the chicken-and-egg problem comes in; collision detection has to run in order to update the position. And the position must be updated in order to do collision detection!

I'm currently experimenting with a way to record a sum of all "requested" velocities over time when the absolute velocities are less than 1. Ideally I would then use the velocity sum to decide whether the object has gained enough momentum to move at least one pixel, and therefore has moved enough to consider performing collision detection. It isn't working yet, but that's the idea!

One caveat for doing this is that sub-pixel velocities are treated as "zero" within the collision detection system, so they also need to be treated the same outside of it. melonJS games currently assume that objects are not moving only when the velocity is zero, but this won't be the case for long ... IN THE NAME OF SPEED!

A lot of the optimizations I've done with collision detection have been little attempts like this to "bail early" before getting to the heavy operations involving iterations. And there are a few more that I am aware of which should make it a bit faster still! These speed improvements are great, but the accuracy of the new code still leaves a lot to be desired. (There are silly bugs like jumping against a wall applying an incorrect response vector.) All in due time...

Tomorrow, I'll get back to the game, and I'll probably spend nearly the entire day on it. So we'll see where that takes us! See you then!

Thursday, April 11, 2013

1GAM April: Day 4

Sprung Fever

Tonight I started adding the girls! I only have art assets for a single girl sprite, and only walking-right animations. I horizontally flipped each frame for the left animation. Works well enough!

The AI is incredibly basic; girls will randomly decide when to start walking, and pick a random direction. They also choose a random time to stop walking. That's it! I might do something more interesting, like having one type of girl that will actively chase after the kid (extra challenge for later levels) or girls that slap you away when you get close (less challenge for early levels).

Also new! A simple HUD which shows the kid's current attention span. When it hits zero, the level restarts (indicating failure -- this will change). I even made it kind of pretty with a simple linear interpolation so it fades from green to red. The attention "deficit" is additive, meaning that when you are crowded by three girls, it drops 3x as fast! Nice unintentional side effect that I decided to keep.


  • More girl sprites with different AoE radii.
  • Refill attention slowly when it is not being drained.
  • Better AI.
  • Sprint.
  • More varied backgrounds and a better starting map.
  • More maps.
  • Objectives/errands.
  • Title screen.
  • Sound effects.
  • Music.
  • Game Over screen.
  • Ending.
  • Transition screens (explaining the objective for the map).
  • Anything else we want, if there is enough time...
Wow! That's a lot left to be done. Welp, I'm looking forward to every bit of it! See you tomorrow!

Wednesday, April 10, 2013

1GAM April: Day 3

Sprung Fever

In day 3, we've added new animations for the kid (Burcag), a start to an outdoors background tileset (Matwek), and changed movement to 4-way only, to simulate the play control of Bomberman or Pacman (me). There's also a lot of melonJS 0.9.7 happening under the hood:

  • The map is JSON format.
  • The sprite animation is stored in a packed texture, thanks to the new TexturePacker support.
On the TODO list for tomorrow:
  • Add girls
  • Add area-of-effect (AoE)
  • Add HUD
  • Add "attention" level + HUD item
  • Add "stamina" level + HUD
  • Add sprinting when there is enough stamina
  • More mapping
  • More spriting
The "attention" level is how focused the kid is on his current errand. As he comes into range of a girl's AoE, his attention will begin to drop, and it becomes more difficult to control him. After leaving the girl's AoE, he will slowly begin to recover attention. If his attention level reaches zero, it's game over!

The "stamina" level will allow the kid to sprint. While sprinting, the stamina level decreases quickly. When the kid stops sprinting, his stamina will slowly recover. If his stamina hits zero, he will be given a penalty, and be unable to sprint until his stamina fully recovers.

Sprinting while inside a girl's AoE could have some unintended consequences, since the kid will be harder to control; he may not respond in time, or may change direction on you, depending on how much attention he has left. This will add some valuable frantic gameplay to the game, especially in later stages with supermodels that have a very large AoE. ;)

1GAM April: Day 2

I got the first sprite today, and threw this quick foundation together in a few hours. Essentially, everything is a placeholder. (Except the intro, but that's been completed for a long time!)

Useful links:

Tuesday, April 9, 2013

1GAM April: Day 1

And we're off!

I spent the night fixing the horribly broken experimental collision detection system in melonJS. It now works fairly well (with a few minor bugs). There are still parts that haven't been implemented (collision tile types like slopes and platforms). But it works well and it's really fast! As a bonus, objects that collide together also have collision responses by default, so they can bump into one another and pile/stack. It's like a poor-man's physics engine! YAY!

With this nagging project mostly out of the way, I will be focusing on the game for this month.

We decided to incorporate the optional "spring" theme word as in you play as a poor guy who is completely sprung, falling in love with every girl he sees. Running even the simplest errands like heading to the shops for some milk is dangerous, as cute girls will attract the guy's attention, making the character more and more difficult to control. Avoid the pretty girls until exams are over, or you'll fail your classes!

This should be quite fun and silly! I'm looking forward to it!

Monday, April 8, 2013

1GAM April!

Starting on a new 1GAM project again this month! It's another late start, but I think that will be fine. This time around, I am working with two artists, so there should be no excuse for lack of help in the art department!

The artists are:

  • Matwek - Backgrounds, tilesets, maps
  • Burcag - Sprites, animations, backgrounds
For an initial game, we're going to do some thing small and simple, but hopefully it will be a lot of fun! I'm starting on programming tonight, and will have my first daily blog post for the project before sleep. Hooray!

Wednesday, April 3, 2013

melonJS: Anatomy of a Game Object


I started working with melonJS last year, after evaluating half a dozen HTML5/canvas game engines. My first choice was actually Akihabara. But not wanting to use the then-stable version, because it was quite out-of-date, I attempted to build it from source and start developing a game on it. I spent a full day with this game engine before giving up (so I did put some effort into it!) The problem was just an unfortunate state of development at the time. I don't know if things have changed much over there, but Akihabara isn't a game engine I hear of much any more these days. It's all about Impact, Lime, Cocos2d-html5, etc.

But I'm here to evangelize melonJS. It's a game engine very similar to Lime, but with its own philosophy and design patterns. This article is meant to illustrate that point, and provide a few examples of useful (and not very obvious) patterns you can employ to do some interesting things in your games.

Like most open source projects, melonJS was started by a single developer as a means to build something that interested him; a game. Over time, that game turned into another game, and another. Soon, it was clear that the common pieces of code could be useful as a general framework for writing games that make use of the HTML5 canvas. melonJs 0.9.0 (the initial public release) was made available in July 2011. The latest stable version is 0.9.6, released on February 26, 2013. The next version is currently scheduled for release at the end of this month.

Game Objects

In this article, I'm going to talk a lot about game objects. There is no shortage of terminology used to describe these things, including entities, actors, components, ... In any case, a game object is an instantiation of some base class which provides some common functionality for the game engine. In melonJS there are two methods which every game object must implement:


This is the method called by the game engine when it is time for the object to update its internal state. This is usually the time for handling things like player input processing, movement, collision detection, animation, etc. Invisible objects (either explicitly made invisible or objects outside of the viewport) are never updated. This method should return boolean true to signal to the game engine that the object is requesting a redraw. Which leads us to the second required method;

draw(context, rect)

This method accepts two arguments; a CanvasContext2d, and a rectangle indicating the area of the context to be redrawn. The rect is only important if you are doing incremental updates, i.e. you have me.sys.dirtyRegion enabled. Since this feature is not fully implemented, it is not recommended to use, so ignore the rect argument for now. :) [Update 2013-08-29: dirtyRegion has been removed entirely from melonJS as of version 0.9.9.)

The context is where you can do all kinds of magic directly on the canvas using its APIs. Rotate the context, set drawing opacity, set line width, create complex paths, stroke and fill, draw images; everything that the HTML5 canvas API supports can be done at this point. And it will all nicely occur at the proper Z-level, because game objects are sorted.

The Base Classes

Any object (including an empty one) can be used as a base class for game objects. melonJS provides a few different classes that you can use directly or even extend with more functionality. The most popular of these is the me.ObjectEntity class. This class implements methods and properties that are quite useful for platformers, such as doJump() and canBreakTile. These are less useful for other game genres like puzzles and shooters.

The next base classes to consider are me.GUI_Object and the similar (but strangely very different) me.HUD_Object. What's very special about these classes is that they both enable a special flag to inform the engine of how to interpret the position of the object when drawing (or when interacting with the object through the mouse/touch interface). The property is called floating, and it is a boolean that determines whether the position should be treated in world coordinates (false) or screen coordinates (true). (See the section below on world coordinates vs screen coordinates.)

All of these base classes, for reasons of convenience, inherit from me.Rect; the rectangle class. This is the same class passed to the draw() method in the rect argument. It handles the object's position (using a position vector; which is an object instantiated from the me.Vector2d class), width, and height. It also has a lot of useful geometry methods for comparing and moving rectangles in 2D space.

World Coordinates vs. Screen Coordinates

"World coordinates" defines the space consumed by a full map in your game. Often, your maps will be far too large to fit entirely inside the viewport (AKA the "screen"). "Screen coordinates" defines the space that is actually visible within the viewport. The distinction becomes apparent when you consider two different types of game object that you might add to the game: An NPC object is probably going to live within world coordinate space, because it can move around within the world, and scrolls with the world as the viewport moves. And a score counter, which is probably going to be anchored to one corner of the screen, and will not scroll around with the map.

So an object using world coordinates will have its position vector interpreted as being relative to the upper left corner of the map (the "world"). And an object using screen coordinates will have its position vector interpreted as being relative to the upper left corner of the screen.

The blue arrows indicate a HUD item (lives counter) that is using screen coordinates, and the red arrows indicate the player object (Master Higgins) that is using world coordinates. The pink outline represents the viewport (the "screen") and the darkened areas are typically not viewable.

The floating property manages all of the complexity for us; we just set it to true or false, and the engine does the rest.

Writing Your Own Game Objects

As I mentioned earlier, it is possible to use any base class to create a game object. It is sometimes desirable to extend a more heavyweight object like me.ObjectEntity, and sometimes you would rather have more control over what the object is capable of.

One particularly good example is used in the last game demo I built, Mini Sim Hotel. When you touch the screen to scroll the viewport, I have a simple indicator dot that appears where you are touching. This was really awesome for the presentation I gave, where the video was projected, and viewers could see exactly what I was interacting with.

The touch indicator was built with me.ObjectEntity, but I could have just as easily used a lower level object, like the new me.Renderable class. The update method returns true when there is a touch in progress, and the draw method draws a circle using the canvas API. That's it!

Some less obvious patterns you can use game objects for includes synchronizing melonJS with other libraries, like physics engines. I did this originally with Chipmunk-js, but this use of game objects has mostly been supplanted with the plugin API (which deserves its very own blog post!) These kinds of objects only need to implement the update method, and always return false (nothing to draw).

Another example is the me.Tween module. This module creates private game objects to keep tweened animations synchronized with the engine. This practice could be extended to keyframe animations, cool-down timers, and a load of other nifty utilities.

Next Steps

melonJS is still fairly young, and actively developed. But the simplicity (only two methods required for game objects) is here to stay; one of the goals of the engine is to remain very lightweight. If a feature requires additional states for a game object apart from update phase and draw phase, that feature will be scaled down or entirely redesigned until it fits neatly inside the melonJS paradigm.

In fact, I have been working on rewriting the collision detection, and struggled with a way to implement a fast multiple-phase collision detection algorithm when I literally have only one phase to work with; the update phase! It's a practice of patience, but in the end, melonJS will benefit from remaining small and nimble.

Hopefully you now have a better understanding of what game objects are and how to use them to create awesome things that may not even be visible!

Thursday, March 28, 2013

Radisson Hackathon: Postmortem

Mini Sim Hotel (click to play demo)

First, I must say this was a much better project that I thought it would be. I'm very happy with how it all turned out! For more general information about the demo, visit my projects page. This post will discuss the development process, what went right, and what went wrong.

Development Process

The dev process on this project went very smoothly. I started initially on the graphics, spending the most amount of my time in that area. Only two days were given to the programming, and I think the demo turned out really well considering.

This was my first project using melonJS 0.9.7 (currently in beta) and CocoonJS. For the record, I wasn't too interested in CocoonJS at first. It seemed like Safari should be able to do everything CocoonJS was capable of, and more! In reality, both have strengths and weaknesses. For one thing, audio support in Safari SUCKS! Even on iOS 6.1, where it was supposedly improved (and support for Web Audio API was added). In CocoonJS, audio just plain works. No complaints there. CocoonJS also allows locking screen orientation, which can be imperative to game design.

On the negative side, CocoonJS has incomplete support for the HTML5 canvas context API (I discovered that it does not support the createImageData method, and also reverse winding on paths does not work correctly). The current release (on iOS store) does not support XML parsing.

New features in melonJS were quite important to this project, too! First, the new support for JSON-format maps is the only way to get the game working in CocoonJS; the older map format is XML. The second useful feature is a new me.Renderable class, which I made extensive use of. This class supersedes me.Rect as a base class for any object that needs to draw.

Finally, touch event support in melonJS is excellent, and it multiplexes with mouse events, so you can use the same code on desktop and touch devices! This made me so happy to get working well during development on desktop, and then I never had to worry if it would stop woking on touch devices. (Literally cuts testing time in half because when it works on desktop, you know it also works on touch devices!)

The simple collision detection in melonJS also saved the day. I wanted to have the people do something, so they don't look so static, like part of the background. My first iteration was a one-liner that made them move left-and-right using a sine wave function. But it looks really poor.

Then I remembered I had added a collision layer "just in case", and quickly threw together a function to set their velocities to random numbers for a random duration. The effect is quite nice, for being so simple!

The very last thing I did was adding mock information window when tapping on people. Currently only two sprites will do this. There's also a "financials" info window when you tap the money counter in the corner. These were made for the presentation, explaining how you might manage the staff and guests in the hotel.

What Went Right

  • I'm super happy with the art. It's tedious work, so it's always nice to see decent results. Especially for a coder (I am NOT an artist). The colors clash, some details could be drawn far better, but it's good for what it is.
  • The intro screen is my favorite thing about this project! I built it originally during the Github Game-Off. So that was pretty much copy-paste and I had an intro! This time I decided to add sound effects to it, which was my original intention anyway. The sounds add the perfect punch that was lacking. It feels nice and old school now!
  • I'm also pleased with the simple subtle effects that I added, and how they increased the impact of the presentation.
  • The first effect is seen in the title screen; the Radisson logo slowly bobs around as if it's floating in water. And the background also slowly scrolls by. This was all done in just about 5 lines of code total; 2 lines for the scrolling background, and a few more for adjusting the logo position and rotation with a couple of sine waves.
  • The other effect is the "ratio" applied to the background image on each of the four hotel floors. This gives a bit of a sense of depth as you scroll around the map. This was done entirely by adding a property to the layer in Tiled. Awesome!
  • Surprisingly, I did accomplish every goal I set for this project. However ...

What Went Wrong

  • I had a "nice to have" goal to demonstrate the construction phase of the game. I just didn't have time for it. That would have been the golden ticket to winning the grand prize for sure!
  • I spent way too much time on art. Unfortunately I didn't have an artist working with me, so it was either do my own art, or snatch some from a website. Not wanting to risk disqualification at this hackathon, I decided to just do my own art. It took a week-and-a-half out of my build time, leaving me with only two days for programming and sound work.
  • The music is forgettable. It was generated by Auto-Tracker Bottom Up, which I HIGHLY recommend for placeholder music, but not so much for demos and presentations!

What To Do Next Time

  • Need a dedicated artist.
  • Need a dedicated sound designer/musician.

Friday, March 22, 2013

First 1GAM + Presentation @ GDC

I'm attending GDC again this year (third in a row!) but this time I will be more involved. I registered for a hack-a-thon sponsored by Radisson Hotels: and will be giving a 3-minute presentation for my project in "late afternoon" next Tuesday.

Due to contest rules, I cannot release the demo prior to the presentation. And in the interest of not getting disqualified, I won't be posting nightly progress updates as I have with past projects. Instead, I'll release the "final" concept after the contest concludes. This will also serve as my first 1GAM, as mentioned in the last post.

That said, I can tell you that I've been focused solely on art for this one. I'm using a "super pixelated"/micro-game style that is popular in indy games right now. I think it's so popular because it's relatively fast to make decent looking sprites when they are artificially limited by size and color. It makes the viewer use their imagination a bit (eg. my characters have no eyes, nose, or mouth) which is a tactic championed by Dwarf Fortress.

So expect a low-definition hotel sim prototype sometime next week!

Sunday, March 3, 2013


This post signifies my intention to develop One Game A Month (1GAM) starting today! I have an idea for a first game. Now I need to get over the motivation speed bump!

Wish me luck.