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 abundant-music.com 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!

THE LIST:

  • 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 http://www.abundant-music.com/ 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.

TODO:

  • 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

melonJS

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:

update()

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!