Welcome back, dear Internet traveller. I hope you’re sitting comfortably, because we’re going to cover a lot of ground in this part.
The general aim of our ‘game engine’ is to find a small set of common object onto which the rest of the game is built. It provides us with some reusable components which simply help us keep a clean and maintainable codebase and provide some naming conventions down the line.
The game engine is the game’s framework. There are plenty already out there. For traditional games, there are the engines, the Unreal Engine, CryEngine and Unity (some of which can compile to JavaScript). Web-specifically, there are the likes of Phaser, Impact, or the more RPG focused, RPG Maker MV. If you just want to get started building games, then I strongly advise giving one of those a go.
In building my own, what I want to avoid is overly-generic code. I don’t want too many abstractions getting in the way of readability. Digging down through includes of includes, functions within objects within objects gets weary. A simple, but manageable codebase which is fairly resilient to change down the line.
I have reached a point with the level editor where I am ready to move on now. It’s all gotten a bit wood-for-the-trees. I’ve spent far longer on it than I meant to, but I needed to make sure that it could handle (inevitable) future changes without needing to wipe the data and start the maps all over again. But I just want to get it out and get using it to find the issues.
Now that we have a sense of how our game engine will run, we want to be able to put together maps/levels in as quick and easy way as possible. Obviously, editing the map data by hand is about as painful as a rusty saw to the gut, so having a way to visually compile maps with the added convenience of mouse interactions is going to help immeasurably.
A level editor’s prime focus is to provide ease of editing as game’s database. Much like a CMS front-end to a database back-end. They are often ugly, menu driven monstrosities. The more complex the game engine, the uglier, is the general rule. For example, here’s the Unreal Engine level editor:
In the last part I talked about structuring the data of a tile-based game along with managing collision detection between the player and a tile. Now, we connect that up with spritesheets and map-loading logic and get this looking and working like a real game.
From all my research into how Zelda: A Link to the Past rendered its tiles and how it handled collision detection, I’ve seen a fair amount of conflicting information. In addition to that, it seems that the ‘ripped’ sprites found on Spriters resource really are just pulled from screenshots from the game, rather than from the game data, leaving the game as a bit of a black box, functionally. I’ve seen internet folk say that the game’s tiles are actually 16x16 while collision detection is handled at the 8x8 level (sub-tile collision). However, there are many objects which are 8x8 as seen in an image from the previous link:
This area of game development has given me the most grief of all. And it’s mostly been me making mountains out of molehills. So let’s just start small and work our way up. See where we get.
Levels are your game’s database. They hold the geometry, enemy positions, entity positions, events and triggers and also tie the background to the image assets.
The isometric RPG style of game, like Zelda, comes under the banner of ‘tile-based’. They are top down and so the background of each screen is essentially the floor, whereas, in a side-scrolling game, the background would often be the scenery in the far distance. In a tile-based game the screen is split up into a grid of cells which are used to draw the backgrounds and provide the basis for collisions and entity positions. Zelda:LttP used cells of 8px by 8px.
I’m not going to go into the theories of animation and all its forms. There are Wikipedia articles for that. What we’re interested in is how we go about creating animations programmatically.
In computer games, there are two methods of animation:
Computer generated animation - Where an object on-screen is either given an easing algorithm or a series of keyframes, and the computer calculates the frames between them.
Sprite animation - Much like the hand-drawn animated films, each keyframe is drawn out, and the game displays each frame sequentially.
As you will have seen in earlier posts (I hope) we’re initially rendering the game at the SNES’s native resolution of 256x244. It works well for now, while we sort out the basics of the game engine, as all the sprites were drawn for this resolution with each sprite ‘cell’ being 8x8 pixels wide.
On an older generation console, the output is upscaled by the player’s television which, being CRT, handled it pretty well, so the images were large enough and retained all that (albeit mostly blurry) hand-drawn sprite detail.
In the last post, we looked at the Game Loop and how to run our game at the sweet spot of 60fps. Now, let’s see some results, shall we? Time to make some pretty shapes.
By using canvas, we’re moving beyond the world of basic JavaScript, and using a set of functions available only to the canvas ‘context’. By its very nature, the canvas element is a platform for pixel manipulation. Once we’ve set up a context, we can access and edit any pixel in it. If we want to draw a line we could, should we want to, loop through a line of pixels and set them to a colour of our choosing. But doing that is very inefficient in JavaScript and, instead, the context provides us with a number of functions to speed those operations up, such as lineTo(). You can see a full list of those functions available to us over on this handy cheat sheet.
Welcome back, intrepid adventurer. Previously, we learnt about drawing to the screen with canvas’s drawing functions. But a game is not a game unless you can interact with it. So now we see how to handle user input.
Running a game inside the browser is both a blessing and a curse. A typical PC/Console game runs on top of everything else (with a few exceptions), so clicking the mouse or tapping a key will do nothing unless you program in a reaction to this event. In the browser, we’re already in the OS and the browser, so both of these get first say in what those events do until you overwrite these defaults. And we’re limited to what we can control.
If you’ve learnt JavaScript through making Websites, you may be forgiven for expecting a game to be written in a kind of event driven fashion. The browser world consists mostly of event handlers and callbacks. The user clicks a thing or presses a key and then stuff happens. Reactionary, if you like. Simpler games like Letterpress, Wordfeud, Words for Friends, Sudoku, etc… can work on this mechanic. The GTAs and CODs of the world, however, do not. As soon as you want more advanced elements like animation, physics and artificial intelligence, then you’re going to need a better system. That system is the “game loop”.
In a previous version of this post, I outlined two potential routes for this project to go in. Crowdsource a new game, while also hopefully covering all aspects of game development, or recreate a classic: NES’s The Legend of Zelda but with SNES’s Zelda: A Link to the Past’s graphics. As expected from people on the Internet, frankly, no one gave a shit. So re-creating The Legend of Zelda but with SNES graphics, is a go!