Here’s an HTML5 experiment in progress…
HTML5’s canvas element is pretty powerful and easy to use. Rendering images, shapes, and text typically does not require a lot of code. So I decided it would be fun to build a simple javascript gaming engine to see what I could do with the canvas element in a few hours. The type of game being assembled is an aerial view sprite based game. Similar to what you would see in many early RPGs.
This is just an experiment, the code was not optimized for performance, and I do not recommend using it for any projects, however I will post a working engine sometime in the near future.
I ended up doing this all in just under an hour, and I have to say it was pretty easy getting everything to work together. I have not included graphics yet, so for now everything being displayed on the screen is text. I mostly focused on collision detection and sprite movement. Via key presses the sprite will move either horizontally or vertically around the canvas. The sprite will also bump into the edges of the defined map using via the collision detection I wrote. Finally the sprite has been configured to handle parameters such as which direction it is facing, if it is standing still or moving, etc. I might expand these parameters down the road to support things like health or special behaviors.
The explanation of code is broken down into 4 main chunks: the environment, keyboard detection, sprites, and movement. Each code section has unique attributes and functions, and the environment section controls what is displayed on the canvas as well as refreshing and redrawing the canvas.
Environment.
This example uses an aerial view environment; we’re looking down at the sprites. As mentioned earlier, your view of the environment is commonly found in many early RPG games. The environment object contains a list of each sprite that is currently active within the canvas, and runs the functionality to draw the sprites to the canvas. There’s also a function outside the environment object called refreshLoop which first clears the canvas then draws the current state into the canvas. I will eventually include the refreshLoop within the Environment class, however for experimentation I found it easiest to include within the page itself.
Keyboard detection.
This area checks for keyboard activity. keyUp acts as a reset function for the speed and current key variables. The reason I have a function resetting these variables is for things like sprite acceleration or rapid-fire. In scenarios when the key is held for a long duration, the sprites speed can be accelerated to simulate running, flying, or any accelerated movement. It would be good to define these movements in another class for calculation as many javascript libraries already do.
keyPress triggers whenever a key is pressed or held. It triggers the default sprite’s movement functionality. If you remove the comment in front of CurrentSpeed this will provide some basic acceleration – hold the key, and the sprite will “run”.
Sprite Object
This example uses a character sprite, no graphics yet!
Though were only displaying a few characters to represent our sprite, I actually dove in rather deep with this section and developed a “state” setting for the sprite that indicates which direction it’s looking, a default state (centered), and an interval to return the sprite to its default state after it stops moving. This can later be expanded to display different sprites, perhaps showing how much damage a character has taken (weakened states) or if a character has acquired a different outfit or weapon.
For now, state switching will be used to animate the sprite walking around, so it’s actually a great way of visualizing what’s to come when I add graphics into this project. I currently have the sprite displaying brackets for left and right movement, a plus sign for the centered/rest state, and I chose a caret and underscore for upward and downward movement. Though it is only displayed as text, it proved to be a quick and dirty way of implementing state switching before working with graphics.
The sprite object also contains variables for positioning, and state along with the pos function which allows the environment, or keyboard input to relocate the sprite. The pos function should be used in conjunction with the movement section to provide collision and acceleration calculating. The draw function is called by the environment when then refreshes the canvas, and displays the sprite at its given location and state. The direction function updates which direction the sprite’s state is set to. Finally I also included a debug function that allows you to trouble shoot the sprite object.
Movement, Collision Detection, & Acceleration
Though the keyboard provides a mechanic for acceleration of the defaultSprite (the player), the actual calculations for any sprites acceleration are handled in the movement section. I also began some basic clipping functionality here (collision detection), and all of this is handled within the moveSprite function.
For this example, the movement function requires the sprite’s current coordinates, the direction it intends to move, and the speed at which it’s heading. The function then calculates to where on the ‘map’ the sprite would be placed (tile size + direction + speed), and verifies if it can move there (no collision). Further expansion of this code will require determining if objects are in the way of a sprite that want’s to move multiple positions per-refresh (a really fast moving sprite), and stopping the sprite at the point of collision.
Code and Example
You can view an example of this experiment here. As always this is open source so feel free to take a look and modify the code as you see fit. Just remember that this is a very basic example!