Close

Asset loader

A project log for HTML5 Retro Game Engine(s)

A Side project where I try and build various scriptable retro game engines in the browser.

timescaleTimescale 04/30/2019 at 15:060 Comments

I got some graphics and I have some outline of what I want to do with it. The very first thing that I need is a way to get the graphics into memory in a way where I can use them in the render engine.

I'm using the HTML5 canvas element to display the game, but I'm also going to use it to load the graphics and because I want the main canvas to display a splash screen and loading status while loading the assets, I'll use a hidden canvas element to do this.

The first thing that happens after the page is loaded, is a call to the function that loads the XML file that essentially holds all the games data or at least the scene data. This means the assets, how they are to be stored, what they represent and how they relate to each other and ultimately the game logic, but we are a long way of from that. A basic asset looks something like this.

    <asset>
	<name>PittRivers</name>
	<mediaType>image</mediaType>
	<assetType>sprite</assetType>
	<file>./assets/characters/pitt/PittRivers1.png</file>
    </asset>

This is basic enough. From this data, the loader function can now build some indexes and arrays that hold the graphics and the data needed to handle them. This structure will most likely be added to later as it will contain various types of media and asset types.

After this data is properly stored, one by one the images will be loaded into the hidden canvas element and then copied to their location in a big chunky array where we can address every sub-pixel individually. This is important because I'm going to use this for storing various types of meta data with this.

An Image object contains a vast amount of data that, when not strictly being used as image data, can be used for a lot of things. When I made the cave graphic, I also made this image.


This is not the exact image because the grey and black parts are eventually going to be the alpha layer, but this does illustrate what this meta-data file is going to do. Imagine this file projected on the cave scene. Or lets not imagine it, lets take a look.

The red channel represents the places a character can walk and the grey/black areas are indicative of where this part of the image is in relation to the background. This concept isn't new and has been used in many (adventure) game engines. This exercise is about how I want to use these 4 channels to work with the game dynamics.

So with four channels to work with, R,G,B and A, each having 256 levels to assign meaning to, we have some options to consider. Of course the path channel and the mask channel are a given.

The mask channel will use 0 for always visible and 255 for always hidden with all the numbers in between being either depending on the players Y-coordinate in the scene.

For the path channel, we get 1 to 255 where 0 is not accessible but 1 to 255 are. Now what possible meaning could we assign to that channel apart from accessibility? At this point in time, I'm considering speed! (Change my mind!). Basically it will dictate how fast the character will be able to move through a specific area like flat road versus water. Now it is apparent that this does not work with slopes, so I'm not 100% committed in giving up this data channel for that specific reason.

But regardless, we have 2 channels left. Green and blue also have 255 values each in the same file that we can attribute a meaning to. So what is spatially dictated that I could want to control in this fashion?

Size perhaps? naturally the easiest way to control size is to control it by the Y position of the character just like the mask, but perhaps there are scenarios where the size on different locations of the scene have to be forced.

Y offset. In conjunction with mask, using a Y offset would make it possible to create effects like in Kings Quest (5 or 6), where the character walks off in the distance over dunes, bobbing up and down, disappearing behind the hills as he gets smaller and smaller.

As it stands I have nearly 3 channels of unused bandwidth in this scene and I would like to make use of it! Any recommendations are welcome!

With the basic loader nearly finished, there comes a crucial part of the games design. The main loop! In that main loop, the game state engine and the render engine will live. For now, the game state will be hard coded so the next log will be all about the main loop and the render engine.

Discussions