General Category > General Game and Application Development

Javascript Game Engine (2d)

(1/2) > >>

Hello people.

I've uploaded a zip of my game engine that I've written to my webspace (and attached here too).

It is a javascript game engine for web browsers.

The engine is the basis for the source code of my four games developed so far this year including:

A Knight's War
Star Scavengers
The Young Prince

Each of those games in turn had new features added which were incorporated into the engine.

This morning before work I made a copy to use as a template for future games for myself and commented heavily all the source includes, as well as removed all the components specific to individual games leaving just the sufficient code that is needed to run the engine and make a game.

In a game you or I might develop with this the main modules that get coded into at development time are:

init.js - loading of images and sounds
gamedataonline.js - all game specific stuff depending on the nature of your game.

For those of us from a blitz background it should be fairly straightforward since we are used to coding games rather than clicking games together.

The link to the engine is here (zip shown on page)

The attachment is also included here (below)

If you find it of value then I hope you can make some good games with it.

I will be updating it and adding features as I progress on making more games.

I appreciate putting the sources up for everyone - here some short comments about it:


--- Code: Javascript ---function updateaudio(){        //Called once per frame to handle audio transitions and the like        if(audioloadstate!=100)        {                return;        }        if((ismobile==true && mobileaudioenabled==true) || (ismobile==false))        {                if(audioon)                {                               //      audios[0].snd.loop = true;                        //      audios[0].snd.volume = MUSICVOLUME;                        //      audios[0];                                        }                else                {                        //      audios[0].snd.pause();                }        }} So it is actually doing ... nothing ?

--- Code: Javascript ---function basemenus(){        if(gamestate==CAT_GAMESTATE_MENU)        {                menuframe++;                firstframes++;                var dieroll = Rand(0,1000);//randomisation method....                if(menuframe>60*25)                {                }                if(firsttime)                {                        firsttime = false;                }                if(firstframes>10)// && firstframes<=300)                {                        consoletext = new Array();                        consoletext[consoletext.length] = "Art, Design, Development, Programming";                        consoletext[consoletext.length] = "            "+AUTHOR+" "+YEAR+"      ";                        //consoletext[consoletext.length] = "Music by Eric Matyas,";                        drawtext(400,20+420 + 3 * 30,consoletext[0],'#EEEEEE',"20px Arial",true);                        drawtext(400,20+420 + 4 * 30,consoletext[1],'#EEEEEE',"20px Arial",true);                        //drawtext(400,20+420 + 5 * 30,consoletext[2],'#EEEEEE',"20px Arial",true);                }                if(firstframes<300)                {                        drawrect(0,0,800,600,'#000000',1.0-firstframes/300.0);                }                if(audioon)                {                }                else                {                }                if((mouse.oclicked!=mouse.clicked && mouse.clicked==false && CREDITS==false) || firstframes>=300)                {                        gamestate = CAT_GAMESTATE_NEWCONTINUE;                        consoletext = new Array();                        return;                } Again some stubs ... and all in all it seems pretty ... "non-oop". I mean these "frame checks". it reads as if many things need to be done in a hard-coded way instead of something like a "credits class" handling all the fading, timing ... for you. Convenience classes ;-)

@ code
You seem to prefer an "alllowercasenames" approach (which is hard to read). I understand that Java-Script is case-sensitive and this allows for a less error prone way of coding but I think it is hmmm still not easy to read. UpperCamelCase for functions and lowerCamelCase for variables is what I prefer (which can differ to other favors).

Of a gameframework I assumed there are some simple classes to extend from - eg. "TScreen" -> "TStartScreen", "TGameScreen" ... and that the framework handles all the go-back, transition-to, ...
So without really having looked through the code I assume it is a bit "raw around the edges" for now?

The more games you write with your framework, the more stuff you will code within the framework. Your individual game code should never have to register for key-events on its own. give a "ListenToKey(keycode, [onKeyPressFunc, onKeyUpFunc, onKeyDownFunc, onKey...])" or "ListenToKeyPress(keycode, callBackFunc)" to your framework and it should handle it. The more you "automate", the more you "centralize", the better. You could still code your own key-event-listener, but as you won't need special behaviour in most cases, do a "do it once" approach.

Same for sounds, data handling, multiplayer-synchronization, ...


It's deliberately procedural....definitely non-oop....(most of the languages we use at work are non-oop, completely procedural) - and for
procedural is a lot simpler to understand for most people from a blitzbackground than oop anyway.

Re:stubs - yep exactly - the gamedataonline.js function is for the user to fill in as required...basically all my games get this module rewritten each time with all the other modules remaining unchanged or having features added....

Anything and everything inside the gamedataonline.js module is up for grabs in terms of changing it is what I said in the comments at the's a 'user function' that contains whatever you wish to do - the actual engine code is mainly in the other functions (renderer, init, functions, codedgui and so on)

But it's definitely procedural and fairly non-oop deliberately.

Re:all lower case - yep - that's how our convention is at work that we use for Pronto programming - all lower case with capitals for constants only.

Just to clarify....

It's definitely mostly not OOP.

Think of it more like blitzplus or blitzbasic with drawimage commands and so on, and a game loop already set up and the initialisation procedures already available (init.js, renderer.js and functions.js) and the main area that needs to be filled in is gamedataonline.js with all your own javascript how you choose -

So it's more a working game loop, with helper functions that allows you inside the main function (gamedataonline.js) to determine how your game flows and plays -hence all the stubs in that procedure.

Everything else outside of that procedure is a helper function for that.

As it stands, the index.html when run runs the loop, loads a handful of resources, and then does nothing - because the user has to populate the main function.

But even inside the main function, there is a structure - like a skeleton that can be filled in.

The various hardcoded frame values are leftovers from previous games but also give an indication of how things can be performed.

For those from a blitz background it's probably quite simple - for those who come from something like Unity or Godot or any of those type of systems - a bit low level.

Steve Elliott:
Congratulations on producing a game engine. That does explain how you can produce your competition games so quickly and not have to fight with a system that doesn't suit your way of coding.

And thanks for sharing.


[0] Message Index

[#] Next page

Go to full version