Close
0%
0%

HTML5 Retro Adventure Game Engine

A Side project where I try and build a scriptable retro adventure game engine in the browser.

Public Chat
Similar projects worth following
I have dabbled in interfaces for years for various projects, but for work, I have never really gotten into game development. Lately a project I'm working on started to incorporate more game like dynamics and attributes. This got me interested in the fundamentals of the machinery that underlay game logic.

In this project, I'll be describing my adventure to create adventures. I want to see how far I can get building a Sierra/Lucas SCUMM type of game engine completely in browser. Not an emulation of those two, but a completely new engine.

(A couple of the logs, I have writen in advance and only now have the time to upload them)

First off, Why? Well, because I think I can!

I really enjoyed (and still do) the 90's adventure game genre, especially the good old 320 by 200 pixel days. With retro being all the rage, why not jump on that bandwagon I thought. Last year I actually attempted building a game from scratch which really ended up nowhere. It was an exercise in using the <canvas> element to see how I could use that in various projects. It was a fun playground that quickly started to look like the beginnings of a game. I dubbed it Shovelization and thought about making it a strategy game about archaeology.

Shovelization basically was a isometric'ish tile based game where a player would get an assignment on a plot of land to dig up a site and find the answers to the questions associated with the level. I build the isometric engine, a couple of characters, the basic level system and some of the plumbing for a game like menuing systems and such. At many stages I felt I could really pull it off until reality hit me twice!

The first reality check was when I realized that the genre of real time strategy is about as hard to get right coding wise as anything. This is not scrolling platformer hard, this is properly difficult to get right. (How the 8-bit guy does it in 6502 assembly is remarkable!) The second was the fact that I completely got the fundamental design wrong. The relationship between game state, input and output was a mess. Building something on one size would break the other size. Fixing that would break something else. It resulted in unmanageable spaghetti code.

Realizing that implementing the gaming logic itself would be near impossible without a major rewrite of the core components, I laid that project to rest, perhaps to revisit it later. I did use what I learned in this experiment to build a small lightweight canvas based online image editor with some pretty advanced features.

But as my interest in gaming logic reappeared thanks to my current work, I had a choice. Retry Shovelization or perhaps try something else first.

script_manual.rtf

Version 1 for the game engine script language

Rich Text Format - 2.22 kB - 05/06/2019 at 16:41

Download

  • Just one more!

    voxnulla07/23/2019 at 17:53 0 comments

    I admit, I have bee indulging a bit with playing with my.. graphics functions... But just for fun, let me show you one more that perhaps shows a bit more potential when it comes to in game effects.

    This, seems to me, to be really handy for your typical bomber command clone!

  • Trying to think like a game dev.

    voxnulla07/22/2019 at 21:17 0 comments

    In the Last log where I posted a link to a live version of my adventure engine, I mentioned that I was experimenting with various ways to build up a screen to figure out what works and what not and what methods are efficient and usable. It occurred to me that various game types must have different approaches on how to render a screen that make sense for that specific type and I wasn't sure if my approach was the right one.

    So I forked my adventure engine code and retooled it to be a continues side scrolling tile based platformer. The reason for the continues scrolling was because the engine already tries to draw the entire screen 30 times a second. A non scrolling game is easier on the CPU, but more difficult to code as all moving parts will need their own background redraw buffer. I know there are other options in HTML5 Canvas to make assets act more like real sprites, but I would like this project to be as basic as possible controlling every sub-pixel.

    The quick proof of concept I whipped up did yield some interesting results. Instead of going down a list of object to draw as I do in the adventure engine, the platformer just scans the 320 by 200 pixels and using offsets and a tile map, figures out which pixel from which tile to draw. It looks a bit like this :

    The snowy background just is random noise. The draw function also does not clip edges. What this demo does is simply take this data :

    <mapData>
        3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
        6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,
        6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,
        3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,
        2,2,2,2,2,2,2,2,2,2,5,5,5,5,5,5,
        1,1,1,1,1,1,1,1,1,4,4,4,4,4,4,4,
        1,1,1,1,1,1,1,1,4,4,4,4,4,4,4,4,
        1,1,1,1,1,1,1,4,4,4,4,4,4,4,4,4
    </mapData>
    

    And per pixel uses this to determine where the image data should come from. Now here is where it gets interesting because when I first implemented this I used a tilemap, or simply an image that held all the tiles in order.

    Using only the first tile was fine. Well under one third of a second to draw 30 frames, but as soon as I put in the code that moves the coordinates in the drawing routine to get the data from the second, third to sixth tile, the render loop slowed down by a factor of 10.

    This code wasn't that much different from the function I use in the adventure engine for animating the assets, but I never saw any drastic reduction in performance. In this case I did!

    It turned out to be a single multiplication in the line where the X and Y coordinates were mapped to the image object. Apparently the impact of that one multiplication, per pixel, either gave an enormous overhead or completely nullified any clever predictive execution methods that I am not aware of to make the whole thing become unusable.

    The solution was simple and crude. Instead of an image map, all the tiles were simply loaded into their own containers. The asset loader is quite capable of that, so I just cut them up and did it this way. Just passing the ID of the image data cause no slowdown and the engine now is perfectly capable of drawing the entire screen 30 times a second with a myriad of tiles and tile sized in fractions of a second.

    I found this really interesting and it made me realize that this to is an area where it helps to have some intuition from experience. This frame shifting method is fine for a system where only a couple of assets are animated in this way, but not for others.

    This set me out to explore other methods to build up a screen. I already named a few, but there obviously are more. Now what I'm doing is in no means using ASM on a 8-bit micro, racing the beam, but the general methods hold true.

    This made me experiment with various effects and methods which resulted in a strange screensaver result that I would like to share with you now :

    What this is, is the platformer code forked and made to draw the assets more like the adventure game, but also use the scanline function to do some effects. This turned out to be a real cheap way to get...

    Read more »

  • Try it yourself!

    voxnulla07/19/2019 at 13:39 0 comments

    Having been busy with other (paid) projects, I did not have much time tinkering with the adventure engine for some time. I did experiment with the <canvas> some more and that yielded some interesting results.

    But in the meanwhile, I thought perhaps putting this out there is the right thing to do at this point in time. So here you have it !

    Adventure Engine Version 0.1b

    If you want to look at something, press the L key and to pick something up, press the P key. If you get stuck, you can move the character around with the arrow keys.

    There are some test functions available like the filter mode, fades and testing a part of the scripting functions.

    Nothing is obfuscated and you can download all the files with any extraction tool to have a go at it yourself. Apart from the "borrowed" graphic asset, all material/code is to be considered under the MIT license (version 2.0).

    If anybody wants a zip file, let me know.

  • Storyboard Script

    voxnulla05/06/2019 at 11:15 0 comments

    It's time for some game logic! From the very first outline of this project, I wanted to have an engine that used an interpreted scripted narrative to run the game. It is time to start work on that.

    The last piece of the puzzle was to implement a global game state. This does a couple of things, but the most important thing is, it stores changed values per scene per object and when a scene (re)-loads, those values are put back. This means if you pick up an item in one scene, go to the next and then return, the item will still be picked up. Having a global game state also makes it easier to implement saved games and do quick testing of various game scenarios.

    But now I want something to do in the game. I have not yet made the inventory system, but that is a bolt on accessory that I do not need for this. What I want is for each scene to have a storyboard with an easily readable script that is able to define actions and subsequent reactions all with some logic thrown in there. For this I took some inspiration from other game scripting languages and general scripting languages.

    I want the least amount of syntax and maximum readability. That is why I chose to use an indent type of logic that interprets something that kinda resembles the verb based system SCUMM used, but not quite! Here is a snippet.

    <storyboard>
    
        use stick on bolder
            case bolder.pushCounter = 3
            say "enough already!"
            break
        esac
        set bolder.pushCounter ++
        move bolder add 10 0
        play grind
        say "Uuurrggg...."
        case bolder.pushCounter = 3
            say "Well, that went better than expected!"
            hide bolder
            break    
        esac
        use bag1 on bolder
            say "That does not seem to work."
        break
                            
        lookAt bag1
            say "That's my bag!"
        break
    
        lookAt stick
            say "It's a stick! Made of wood."
        break
                                            
    </storyboard>
    

    The main part here of course is the "use stick on bolder" line. In this case, it is not a description of what can be done, but a label of what to do when this happens. The game engine itself will generate that set of words and will then search the script for this occurance. If it is there, the script level goes up and interprets every line on that level until it breaks or the level goes down again.

    Specialized function like say, hide and play are abstracted versions of their actual engine counterparts. It is still possible to directly change game state via the set command. In fact, most commands could be done with set, only it would take more commands to do the same thing like move that would need several in this case as it not only sets an object x and y position, it adds to it which means that you'd need to use set about 6 times making the script less readable.

    Another example would be the hide command which does 2 things. First obviously it hides the object but more importantly it sets the global. The alternative version isn't much longer, but it is longer none the less.

    case bolder.pushCounter = 3
            set bolder.hidden true
            global bolder.hidden
            break
    esac    

    For commands like say, it would be even more involved as it would mean setting various object attributes and figuring out what object to do it to. The say functions just does that for me.

    At this moment, the script does indeed run and most functions are implemented. There are a few things I need to clean up and test, but I think this is looking very promising.

  • Setting up scenes

    voxnulla05/05/2019 at 12:01 0 comments

    This weekend I got around to doing some work on the plumbing of the engine. A lot of the scene data was still hardcoded in the init function, but now nearly all data is loaded from the XML file. Asset information, object information and the scene data now make up the structure with which I want to drive the narrative.

    I realized that an engine is not so much a necessity as it is a luxury and therefor it should provide me with a level of comfort. It should make the minimum of demands on the data I feed into it and make the maximum amount of assumptions on data when I do not feed the data. Also, I want to be able to add/modify attributes at every point without having to dive into the code.

    So the minimum data required to get an item in a scene should be something like this.

    <scenes>
        <scene>
            <name>Intro</name>
            <character>PittRivers</character>
            <stage>scene</stage>
            <actors>
                <actor>
                    <objectName>PittRivers</objectName>
                    <x>35</x>
                    <y>165</y>
                </actor>
            </actors>
        </scene>
    </scenes>    
    

    This simply puts the character in the scene at those coordinates and defines it as the playable actor. All other attributes have either been set in the object definition of in code as defaults. At any stage can I add an attribute or overwrite one in the actor section. In fact, the object definition works just like this, only 1 step higher in the data structure hierarchy. This means that data like frame animations, anchor points or zoom types won't have to be set in every scene every time.

    There now is one layer that is missing and that is the global game state. This is where the game logic will exist in part. It is the bit that makes sure that when you picked up the stick and you re-enter this scene, the stick will remain hidden.

    Here is a demo video of the current state of the engine.

    Right now I'm selecting the options with the keyboard so L is "look at" and P is "pick up". This will later be selectable by clicking the main character.

    The text responses for the character are defined on the object level and the responses and action for items are right now defined on the stage level. There are also set distances at which certain actions can be done. These are also scene attributes.

    Another thing is audio. The asset loader now also loads and indexes ogg files that can be used for actions like picking up or using objects. This was a real simple addition. I'm still thinking on how to do background music. I love the idea of using MIDI for this and I am currently looking at existing in browser MIDI player options. If this does not work out, a simple looped ogg file will do just as well.

  • Frame animations and more

    voxnulla04/30/2019 at 21:49 0 comments

    Last entry, I was working on the frame animation system. By combing the re-sampler function with the frame selector, it made live a whole lot easier. Basically any object which can be tiled up in frames has this information in the XML file and that is handled by the loader. The asset data for the Pitt Rivers character looks like this.

    <asset>
        <name>PittRivers</name>
        <mediaType>image</mediaType>
        <assetType>sprite</assetType>
        <file>./assets/characters/pitt/pitt-standing.png</file>
        <frameCount>5</frameCount>
        <frames>
    	<frame id="0" x="1" y="0" w="28" h="47">Standing1</frame>
    	<frame id="1" x="29" y="0" w="28" h="47">Standing2</frame>
    	<frame id="2" x="57" y="0" w="28" h="47">Walk1</frame>
    	<frame id="3" x="85" y="0" w="28" h="47">Talk1</frame>
    	<frame id="4" x="113" y="0" w="28" h="47">talk2</frame>
    	<frame id="5" x="141" y="0" w="28" h="47">talk3</frame>
        </frames>
    </asset>
     

    The image is stored just like before, but assets that can be tiled have an extra array bolted onto their data structure that holds the frame data. I realize that this approach is not the most elegant as I could simply do without the frameCount tag and simply check for and count if any frames are defined. Also as of now, there is no support for sub-frames, where various smaller frames can be spliced on other frames. For talking normally you only need a couple of heads.

    On the other hand, this does mean that elaborate animations can be made like the ones in Flight of the Amazon Queen, where the characters are fully animated even while talking and doing small stuff.

    This is the current character file that I'm loading. I took the Indy sprite I "borrowed" and photoshopped a couple of stances. The first 2 are the breathing stances while 3 is a "walk" and the last 3 are talky head movements. To accommodate for the frame animation, the object data structure array did indeed receive more features.

    objectData[]['name'] = "PittRivers"
    objectData[]['asset'] = "pittStanding"
    objectData[]['type'] = "character"
    objectData[]['frame'] = 0;
    objectData[]['text'] = false
    // .... all the other attribs
    
    objectData[]['animationSequence'] = 'standing'; // current animation
    objectData[]['animationLoop'] = true;
    objectData[]['animationTick'] = 0;
    objectData[]['animationStep'] = 0;
    objectData[]['animations']['standing'] = "10,0,0,0,1,1"; // animation sequence time,frame,frame,frame...
    objectData[]['animations']['walking'] = "3,1,2,1,2,0";
    objectData[]['animations']['talking'] = "3,3,0,4,5,4,3,0,5,3,0,4";
    

     This is the set of attributes per object for frame animating. This object current has 3 animation sequences, standing, walking and talking. The starting sequence is the standing sequence which has a value of "10,0,0,0,1,1". The first number is the number of ticks (half Jiffies?) for the next frame to be set in ['frame']. Whatever frame number resides in that field, that is the frame the render engine will draw.

    The rest of the numbers are the frames themselves. When the animation is a loop, this animation runs until another sequence is selected. Here is the re-sample frame function.

    function resample(tileID,zoom,frame){
        // resample frame with simple nearest neighbour style resampling
        var frameCount = assetIndex[tileID]['frameCount']
        if(frameCount == 0){
            var frameX = 0,
                frameY = 0,
                width = sceneGraphics[tileID].width,
                height = sceneGraphics[tileID].height;
        } else {
            var curFrame = assetIndex[tileID]['frames'][frame],
    	    frameX...
    Read more »

  • It's starting to feel like a game.

    voxnulla04/30/2019 at 19:03 0 comments

    The little online adventure game engine that could has had some major improvements the last session I spend on her. I could list them all, but as I promised video (or it did not happen) last time, here is the current state of the project.

    In this short video, you can see me demo'ing the masking feature first. With the crude cursor input I can move around Pitt Rivers in front or behind features in the scene. I an happily navigate around the stone pillar and you can see the (oddly transparent) rock being masked as well.

    After that I use the cursor to demonstrate that this type of input does indeed move the object towards it target. This function checks the meta data file and if the red channel has a pixel at that point, it tries to navigate the object there. This function has room for improvement as the object can get kind of stuck at some angles and it now tries to go in a straight line, so when it encounters a zero in it's way, it stops. There is no a* path finding routine implemented (yet).

    The final demonstration is picking up the bag and clicking the strange rock which then disappears. These are the first bits of game logic that are surfacing. At this point these are not really important and the implementation is nothing like the final product should work, but at one point it is nice to actually see something happening.

    A major upgrade to the render engine also has been made. The obvious one is the ability to vertically mirror the graphic. So when I steer left, the figure looks left. A bit less noticeable is the re-sampling of the image. As this is 8-bit style, it is a simple near-neighbour algorithm. It isn't the prettiest, but it is period specific. Especially Sierra scaled their onscreen assets similarly like this for ages.

    I would like to share this function now, but unfortunately it is a bit of a mess at the moment, but that is not a bad thing! Before doing the re-sampling, I was trying to implement basic frame animations. I decided that I do not want separate files for frames, so frames for an object exist in the same PNG, delimiting the boundaries either in the data structure or later via abusing the alpha channel.

    The problem was that with opacity, masking, mirroring and scene offset build into the main pixel-wrangler, this function was becoming.. crowded? It started to look like the onset of spaghetti and I was trying to avoid that.

    What I needed was a nice in-between function that would handle the frames and neatly deliver it to the drawing function. It struck me that I could roll the frame select function and the re-sample function into one, creating a single image for the main function to draw. So I started with the re-sample function that can be seen in the video and am now in the process of implementing the frame select code.

    As you can imagine, the object data structure has grown a bit since its initial inception

    objectData[objectData.length - 1]['name'] = "PittRivers"
    objectData[objectData.length - 1]['asset'] = "PittRivers1"
    objectData[objectData.length - 1]['type'] = "character"
    objectData[objectData.length - 1]['frame'] = 0; // which animation frame to draw
    objectData[objectData.length - 1]['hidden'] = false;
    objectData[objectData.length - 1]['alphaMask'] = true; // use scene mask
    objectData[objectData.length - 1]['opacity'] = 1;
    objectData[objectData.length - 1]['drawClean'] = false; // subject to filters or not
    objectData[objectData.length - 1]['x'] = 35;
    objectData[objectData.length - 1]['y'] = 165;
    objectData[objectData.length - 1]['Direction'] = -1;
    objectData[objectData.length - 1]['zoom'] = 'map'; // map = use Y position
    objectData[objectData.length - 1]['curZoom'];
    objectData[objectData.length - 1]['action'] = 'none'; // For example "move"
    objectData[objectData.length - 1]['targetX'] = 0;    // Move target
    objectData[objectData.length - 1]['targetY'] = 0;
    objectData[objectData.length - 1]['anchorX'] = 15;
    objectData[objectData.length - 1]['anchorY'] = 45;
    objectData[objectData.length...
    Read more »

  • Mouse and Mask

    voxnulla04/30/2019 at 18:17 0 comments

    After a relatively easy code clean up, it was time for some user input. This is relatively strain forward event based Javascript, so going into detail isn't necessary. For testing purposes, I use the arrow keys to move around the main character all over the screen. This is quite simple to do as the position of the character in the scene is an attribute of said object. As the render engine chooches along, the screen get updated instantaneously.

    This of course has little to do with animating the objects, but that is a subject for another blog. Point is that I can now kick around my main antagonist on screen to test the alpha masking. I'm not sure if the way I implemented the meta image file is the most elegant and perhaps I'll change this in the future as I suspect it is not necessary and a bit convoluted.

    <asset>
        <name>scene</name>
        <mediaType>image</mediaType>
        <assetType>scene</assetType>
        <file>./assets/scenes/cave1.png</file>
        <metaFile>./assets/scenes/cave1alpha.png</metaFile>
    </asset> 

    Essentially, the meta-data file is just another graphic, so perhaps loading it as a separate asset would have been cleaner and easier as it would not have needed the loader to handle this. On the scene data side it really does not matter much as all that is needed for the render engine to use this data is to have the pointer to the graphic.

    Each object now has a mask attribute that, when set true, checks every pixel position of the object against the mask data and the Y position of the object in the scene. This works a bit like this.
    The object neatly disappears behind the rocky ledge. It can now also walk in "circles" around the pillar. At this point objects are drawn in the order in which they are loaded, so between objects there is no adapting draw depth, but this isn't the hardest thing to implement later on.

    I also implemented mouse events for extra clicky-ness which helps with the whole effort! The mouse cursor is just another object just like the sticks and figure with some extra attributes and options. One option is that the graphic for the cursor can be changes at any time.

    For example, here the cursor uses the bag icon. This means that I can use the actual graphics in the game when the player wants to use it. If you pick up the stick, you carry it and click the bolder. This is a simple visual dynamic that feels quite natural.

    Some smaller features I make this session were the scrolling scene which just proportionately sets an offset based off of the characters position on screen. This was trivial to implement and because I redraw everything 30 times a second, this scrolling is very smooth. I have yet to see any flickering or shearing as I will demonstrate in a demo video as soon as the next set of functions have been build.

    These functions will be the pointy clicky interface to move the character, the path system and a way to animate the movement.

  • Basic render engine

    voxnulla04/30/2019 at 17:13 0 comments

    Last time, I finished the asset loader and the main loop. Now I want to take the stuff I loaded and so something with it, preferably displaying it inside the canvas element. So I'll be starting the game state data structure and a render engine that will take this state and display it graphically.

    The game state basically is a scene and a bunch of objects. For the scene we hardcode the following. Eventually the final data structure will be loaded from the XML file.

    sceneData['stage'] = 'scene'; // the graphic asset
    sceneData['character'] = 'PittRivers'; // controllable character
    sceneData['offsetX'] = 0; // scroll X
    sceneData['offsetY'] = 0; // scroll Y

     This array will probably not be so small in the future. meta files, layers and all sorts of mischief could go into here.

    objectData.push(new Array());
    objectData[objectData.length - 1]['name'] = "PittRivers" // in game name
    objectData[objectData.length - 1]['asset'] = "pittStanding" // graphic asset
    objectData[objectData.length - 1]['type'] = "character"
    objectData[objectData.length - 1]['hidden'] = false;
    objectData[objectData.length - 1]['x'] = 35;
    objectData[objectData.length - 1]['y'] = 165;
    objectData[objectData.length - 1]['anchorX'] = 15; // Where is his middle
    objectData[objectData.length - 1]['anchorY'] = 45; // Where are his feet!
    objectData[objectData.length - 1]['fixed'] = false;
    

    This is the basic object. it also has a lookup table for, but this is basically all that is needed to render a scene with the objects in it. That looks something like this!

    Here you can see the scene with 3 elements, Pitt Rivers, The stick in the middle and the bag which is a fixed object. You might think that I left out a few steps, but in reality I did manage to re-purpose some code from the earlier attempt as well as my online image editor to quickly implement the drawing function which looks a bit like this.

    function draw(x,y,tileName){
        var tileID = assetPointer[tileName];
        // Draw graphic at position in the scene
        for(tileX = 0; tileX < sceneGraphics[tileID].width; tileX++){
            if (tileX + x < 320 && tileX + x >= 0){
                for(tileY = 0; tileY < sceneGraphics[tileID].height; tileY++){
    	        var curPixel = (tileY *  sceneGraphics[tileID].width + tileX) * 4,
    		    curScreenPixel = ((tileY + y) * 320 + (tileX + x)) * 4;
    		if (sceneGraphics[tileID].data[curPixel + 3] > 16){
    		    imgdata.data[curScreenPixel + 0] = sceneGraphics[tileID].data[curPixel + 0]; 
    		    imgdata.data[curScreenPixel + 1] = sceneGraphics[tileID].data[curPixel + 1];
    		    imgdata.data[curScreenPixel + 2] = sceneGraphics[tileID].data[curPixel + 2]; 
                    }
    	    }	
            }
        }
    }
    

    This is the basic function I use to write the graphics onto the scene. Of course this will not stay this short (and readable), but really this is all that is needed to draw the scene, characters and objects. It uses the alpha channel to "cut out" the objects. I could use the alpha channel more granularly, giving the object opacity, but I think opacity should be an attribute in the data structure. Of course for things like car windows, selective alpha would be nice and that will probably be included in this function at one point with the general (controllable) opacity attribute.

    Note in the screenshot the numbers in the upper left corner. The last number is the total of the 33th of a second. The first number however is the time that the render engine takes to draw a frame in that 33th of a second. This means that we have cycles to burn for more rendering and of course the state engine which actually...

    Read more »

  • The main loop and the render engine

    voxnulla04/30/2019 at 15:55 0 comments

    Right, I make some executive decisions on this pet project of mine concerning timing and the render engine. From my failed Shovelization project I learned that modern day browsers on modest hardware are able to push an amazing amount of data with blooming Javascript! Writing image data to a buffer and plonking it on a canvas takes fractions of a second, it really is amazing how optimized it is compared to the mid naughties.

    In my previous attempt to build a game, I wrote it such that only when absolutely needed, a screen redraw was requested. This makes for all sorts of problems that are a pain to force code away, requiring some elements to buffer the background.... but not after a redraw and all other sorts of shenanigans. Secondly, this approach took away some options that I would have liked like filter effects and it made animating "sprites" a royal pain. Who would have guessed! I'm not a game coder...

    But I do learn and I have come to the following conclusions. My render engine will simply (try to) render 33 frames per second regardless of state. Sure, a bit overkill in most scenes I think, but it's 2019, I'm not racing the beam on an Atari 2600! In a 240 by 300 pixel canvas, this is peanuts on a moderate desktop. This will also be my "tick". I know the clock for SCUMM games were measured in Jiffies, being a 60th of a second, but I do not think I need that resolution. Every frame being 1 tick means roughly 30 frames is a second which is easy to work with and will support everything from animation to timers.

    Two of the more controversial choices I have make are that A. I'm not going to use requestAnimationFrame() but rather use a timeout and B. As a product of the 80's and 90's, I'm not going to use classes at all. My data struct is going to be the maximum of OOP in my game and that is that!

    The reason my I'm not going to use requestAnimationFrame() is because I believe it fixes nothing for me but would cause useless overhead. Sure, flickering and shearing are awful, but I do not think my brute force approach will have any issues with this. I will be controlling every sub-pixel and only after the buffer is completed, it will be dumped to the canvas so shearing is impossible. As for flicker, we'll just have to see. It can always be implemented if needs be. (famous last words). As for the main loop :

    	function main(){
    	    var sTime = performance.now();
    	    ++counter;
    			
    	    // main code starts here.
                gameStateTic(); // do game'y stuff
    	    renderer(); // render the gamestate
    	    // main code ends here.
    	    
                // timing to match a precise FPS number.	
    	    var xTime = Math.round(performance.now() - sTime),
    	        waitTime = setRate - xTime,
    	        processTime = waitTime;
            
    		if (waitTime < 0){
    		    // process took longer than the fixed rate.
    		    waitTime = 0;
    		}
    			
    		if (fps){
    		    rateMonitor(xTime, waitTime);
    		}		
    
    		if (loop){
    		    setTimeout(function(){ main(); }, waitTime);		
    		} else {
    		    alert("end program")
    		}
    	}
    	

    That is the main loop and seeing as user input will be handled via events which will be set up before the main loop starts, I do not think the function will be much different in the future. As you can imagine, this loop is chooching along nicely with nothing to do, so I'll have to give it something to chew on!

    Next time I'll be setting up a basic hard coded data structure and building the rudimentary render engine and then we'll see how much cycles we are left with to actually build this thing!

View all 13 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates