Weekend Updates - Indexing and Graphics

A hodge-podge of generally undirected game updates took place over the weekend which I wanted to write about.  Now that the in-game menu functionality is working I'm getting close to having nothing but a handful of random details to cleanup before the engine and game are actually playable entities.

Indexing

One thing I found that I overlooked in my originally programming of the engine was the fact that, since the player is movable, the player may at some points be in front of an object while at other points might be behind an object.  The problem came in when I realized I was not re-ordering the array of on screen objects, so when a player walked behind an object, the entire player sprite was still drawn on top of the sprite for the object which they were supposed to be behind.

On the surface this isn't a major problem and I was able to write up a sorting function to pass to Array.sort which ... sorted things out.  Writing up the function however brought a larger issue to light.  In order to get objects which were literally on top of other objects (ie, a coffee cup on top of a table), I had to introduce a gameHeight property to each game object.  This property I used to indicate how far off the ground something was assumed to be and my sorting function could take this into account when calculating an objects relative position.

This may end up being sufficient for this game, but I feel like the engine in the end needs to more robustly handle the fact that I'm essentially working in a 3d environment but drawing in a 2d context.  For instance, I may end up reworking the object positioning mechanisms so that their position is defined in 3d space and the engine does the work of calculating where to map those objects to in 2d space for presentation purposes.

Graphic Work

I've been putting off drawing more sprites, largely, because I got so sick of it after making all the sprites for the room itself.  This weekend however I decided to hunker down and start work on the panda walk cycles again.  It was as much of a pain as I expected it to be, but I got the forward walk cycle done and am now moving onto the left walk cycle (which will be repeated as the right walk cycle).

All of this graphic work has led me to the conclusion that, for my next game, I need to just pay someone to do this for me.

I still have some cleaning to do, but here's the general idea of what the final walk cycle will look like

So, what is left to be done?  I'll try to get a list together for a future post, if for no other reason than to provide myself with a checklist of sorts.

DnL8Tar

Game Play Decisions - In Game Menu

I've spent time over the last couple months deliberating on (and soliciting opinions concerning) alternatives to the Panda-Town engines current game play scheme.  Right now, when a player clicks on an object in the game, the engine assumes that the player wants to interact with the object.  The engine looks up the appropriate interaction based on the objects current state and then executes that interaction.

While simple, this scheme has a couple drawbacks which have become quite obtrusive in my game design.  First, it limits me to defining one interaction per object per state.  This means, for example, that if I want an object such as a coffee cup to be something the player can pickup, I can not also have it be something the player is able to look at since I can only define one interaction.  A second drawback is that a player clicking on an object may not be in fact attempting to interact with it, they may simply be trying to walk towards it.

I've decided that the play scheme needs to be updated to allow for multiple types of interactions and to force a player to indicate that they are actually attempting to interact with an object.  The direction I am going to take in implementing the first component of the change is to cause a small in game menu to open when a user chooses to interact with an object which exposes more than one type of interaction.  For instance, if a player can either "look" at or "pick up" an object, when the player indicates that they want to interact with the object, they will see a menu with these two choices.

The general idea

Deciding on the best scheme for the second component of the change has proved to be somewhat more cumbersome.  This is due in large part to a restriction I have placed on myself, limiting input to left mouse clicks.  I have placed this restriction on myself in order to allow games made with the engine to be played on devices such as an iPad.  Currently I'm planning on having a player indicate that they wish to interact with an object by double clicking on the object, but I have not settled on that yet.

Side Note: An interesting consequence of the first component of the change being made is that it makes it easier to code interactions from a distance (ie, allowing a player to look at an object from across a room without having to walk up to it).

Side Note 2: I'm readily accepting feedback from anyone who is a point and click game enthusiast (or who has at least played one in their life) concerning the control scheme I've indicated

Caelis Bell Sample Gameplay Video

For the past few months, since approximately January 1, 2011, I have been developing a game in my spare time. This game is named "Caelis Bell." It is a 2D action/adventure game for the PC. I have just finished a sample gameplay video which can be seen below (it's a little cleaner if you watch it at 480p):



This game is written in Java, and will probably be released as a Java-Web-Start game or a downloadable application. It is still far from completion, however.

The story of Caelis Bell begins when three monsters start causing havoc to a kingdom. You play as a young knight named Xavier who is fighting to protect the land. As the plot progresses, you need to find the four pieces of the Caelis Bell, a magical artifact that was broken. Once the four pieces are put together, the bell can be used to defeat the evil sorcerer responsible for the appearance of the monsters.

Even though I have not revealed everything, this plot is still in an early stage of development and subject to change. Character names and the game title are also subject to change.

In case anyone is interested, I also made a puzzle game in Java a few years ago that can be played online as an applet. It is called Ice World. Click the link to play it.

First Look at the Panda Facing Left

I took some time this afternoon to draw up the template image of the panda facing left ... or ... right I suppose from his perspective.  

Looking left

The black outline will serve as the frame of reference for the animation of the panda walking left (or right, I'm going to cheat and just flip the image, making any minor corrections for the rotation necessary.

First Animation Effort

I preface this post by saying that I am in no way an animator.  In fact, I can only say that I dabble in the art of drawing in general.  Being that I am the only person working on this game, I am forced to develop, among other things, the sprite animation for all elements of the game.

The most robust animation in this particular game is going to be the walk cycles, specifically the walk cycle for the main character (and for the maid (spoiler!!!)).  Drawing these animations is something I've been dreading due to the inherent tedium though I'm at the point now that I'm getting annoyed by testing with a static image.  Said annoyance has escalated to the point necessary to raise my motivation to the level necessary to delve into the walk cycle. So here we go:

First attempt at a walk cycle

This is the forward walk cycle.  It ended up being eight frames which seems excessive looking at old NES walk cycles, but it looks decent.  I will most likely get annoyed drawing eight frames per direction (8*4=32).  To draw the animation I'm working off a base image and tracing in vellum so I can see the frames progress as I draw along.  Looking at the animation now I seem to tend downward in my drawing, though that may just be a consequence of the paper folding and I can probably clean that during digital inking. 

Before making this final I am going to tinker with the prospect of a lower frame count, though eight may just end up being what I leave it at, which may be fine since there's only one thing I really need to animate to this extent. 

Panda Town - Hotel Room

I find that working on at least two projects at a time is a good practice, so long as time constraints are imposed on neither.  This way, when one project starts to wear on my soul, it can be temporarily dropped in favor of the other.  By the time the second project becomes a grind, the attractiveness of the first project has freshened.

Finding myself in this situation with Panda Town, after realizing that the art of drawing sprites was quite tedious and time consuming, I allowed the project to take a back seat for a month or two in favor of a Resource Container project which is a concept I've been tinkering with in one form or another for the past couple years. Over the last week I've found myself in a position with that project which is fostering a renewed interest in Panda Town, namely the position of being sick of thinking about the project.

So here we are, firing up Panda Town development again, and with a lot of the initial graphic work out of the way, I'm free to start focusing on the story line and puzzle aspects of the game.  While I haven't solidified things so much that I want to start talking about the concept of the game, I can say the format is going to be puzzle based insomuch as you are confronted with the puzzle of how to use various available items together in the proper sequence and time frame in order to achieve an end.  I'm sure this genre has a proper name but I do not know what it is nor do I have the patience right now to look it up.  Why I've chosen this genre is a subject of a potential future post, but not today's.

Current State of the Hotel Room

Where is the project at?  As I noted above most of the initial sprite work has been done and the general room layout is setup to my satisfaction.  There's more graphic work to be done, namely animation, which I feel is going to be even more draining than the initial development, but this level of completion gives me a test bed on which to develop the story and puzzles.  I've posted an image of the hotel room in which the game takes place and while I'll be cleaning up some of the graphics as time goes on, the image gives the general idea of how the game is going to look and feel.  Tonight I'm going to start really diving into puzzle design as this afternoon I came up with a better mechanism for laying out the story and puzzles than notes in a notebook which I found to be too static for my liking (probably the topic of a future post again, that's two, two future post topics in this post, ah ha hah).

Canvas 2d Context and Frame Swapping

While it may be a consequence of the programming languages of which I was reading, every game programming tutorial I have ever read introduces the concept of a buffer frame and frame swapping fairly early on.  The idea is conceptually simple:

You establish two frames, the first you are currently showing to the player, the second you are actively drawing on.  Once you are finished drawing the second frame, you swap the first frame with the second such that the second frame is now the one being shown to the user and the first is free to be used for the drawing of the next frame.

When I first started down the path of learning the 2d drawing context on the canvas,  I spent a good couple hours searching for the HTML5 canvas equivalent of frame swapping and buffering.  I came up empty handed.  That being the case, as is my way, I decided to just start coding, leaving the buffering problem as one to be solved later.  What I found out, much to my happy surprise, is that there is no need for this practice within the 2d context.  

As you draw to the canvas using the 2d drawing context, what you draw does not appear on the canvas immediately.  This is opposed to drawing in, let's say, Java.  Consider the following bit of pseudo code:

function drawStuff() {
  c = get Canvas;
  c.drawImage( something-great.png, 20, 250 );
  c.drawImage( something-else-amazing.png, 52, 17 );
  c.drawImage( a-so-so-image.png, 189, 442 );
}

If you were to code this in Java and watch it render, you would see something-great.png drawn to the screen first, followed by something-else-amazing.png, and then a-so-so-image.png.  There would be a delay between the appearance of each of these.  And even thought said delay might be barely perceptible, it would be there, and if you are drawing a hundred images to the screen each frame, you would start to notice it and it would become quite irritating.  This is why some form of frame swapping is needed in this case.  You don't want to show the user your frame until all the things you are going to place on it are rendered.

Contrast this to the 2d drawing context.  The way Javascript interacts with the 2d drawing context is such that nothings is actually visibly drawn to the canvas until the scrip doing the drawing has finished executing.  That is to say, looking at the example above, nothing new will be drawn to the canvas until the Javascript interpreter has reached the end of the function (assuming there are not other functions to run after that which are going to do more drawing).  You could argue that this in and of itself is an implementation of frame swapping however the implementation is baked into the browser itself so even if you are making a game engine you don't need to think about it. 

Additional Note of Potential Ignorance

I admit there may very well be a way to achieve the same result in Java without frame swapping.  I haven't done a lot of game programming in Java so I don't know all the magic secrets.  And certainly, many Java game engines hide this detail, however if you are MAKING the game engine you need to worry about it.