Louis Stowasser

Generate Table of Contents from Heading Tags in JavaScript

craftyjs — Thu, 28 Feb 2013 08:53:00 +1000

I recently needed a way to generate a Table of Contents in some documentation. I wanted it to be automatic so I could freely write without having to worry about updating the table of contents. This turned out to be more difficult than I intended with very little available through Google. So I wrote my own function and making it available here for free!

Usage

Set the innerHTML of a DOM node to the string returned from generateTOC where you want the Table of Contents to appear. Pass the parent DOM node into the function and optionally a start tag number if you want to start the table of contents at <h2> instead of “

//save references to our DOM nodes
var navNode = document.getElementById("nav");
var parentNode = document.getElementById("content");

//generate the TOC and set the nav innerHTML to it
var generatedHTML = generateTOC(parentNode);
navNode.innerHTML = generatedHTML;

Feel free to direct all questions to the gist.

Advergaming - The feedback loop between advertisers and players

craftyjs — Sat, 23 Feb 2013 15:12:00 +1000

Advergaming: The feedback loop of players leading to advertisers which benefit and lead to more players. Rinse repeat.

As an incentive to play a game, you have the potential of earning benefits. I don’t mean simply gambling; I’m talking about participation in a game leading to real-world rewards from either other players or advertisers with a vested interest.

The more players a game has, the more valuable it would be for advertisers. The more advertisers are involved in the game, the more incentives there are to play the game thus spawning more players… and so on.

There are three ways to integrate this into a game that I can think of:

Sponsorship - a player is ‘sponsored’ by an advertiser to display an ad in-game or through an avatar.
Acquisition - in-game properties or items owned by a player can be bought by an advertiser to display ads or an external link.
Campaign - advertisers can offer prizes to winners in a game run by the advertiser complete with their branding.

Pixenomics is game modelled after Acquisition. Players own pixels on a large canvas which can be bought by advertisers seeking that space on the board for ads.

To kickstart the loop you need an amount of players that is large enough to get the interest of advertisers. To get players, especially organically, the game must be fun with or without other players (something Pixenomics is lacking).

As this is just a concept I have no real studies or real-world examples to show but I would be interested in seeing how an idea like this could be executed.

Custom Canvas Drawing in CraftyJS

craftyjs — Sat, 21 Apr 2012 14:31:00 +1000

A lot of people have asked about this and I thought it’s about time I write up a quick example for custom drawing on the canvas in a way that doesn’t break the redraw regions.

The first thing to ensure is that the entity’s width and height is large enough to encapsulate the entire drawing so the redraw region manager knows how much to clear.

The second thing to do is overwrite the draw method. In there we can do our custom 2D canvas drawing.

My example is a Circle drawer. It requires a radius and color:

As you can see I set the width and height to the size of the circle (radius * 2).

I also create a draw method which draws a circle at the entity’s x and y position with an offset of the the radius.

It’s as simple as that. We can have some fun with the custom renderer by adding the Tween component and decreasing the radius over 500 frames.

External Documentation Proposal for Exposed APIs

craftyjs — Thu, 19 Apr 2012 18:16:00 +1000

I have been playing around with various methods of documentation and for a while I thought the way to go was inline documentation where the documentation exists within the source code, but I’ve noticed a few flaws in this approach.

Who is the target reader?

Inline documentation doesn’t make sense if the end user has no knowledge or interest in the source. It should exist to teach the reader how and why the code works from the perspective of someone interested in the internals. For a developer who just wants to make use of the API, why include it with the source?

Forcing Object-Oriented-ness

JSDoc in particular generates documentation similar to JavaDoc; a strictly Object Oriented language. This doesn’t cross over well when you have things such as chaining, currying or other JavaScript oddities.

The solution

Damon Oehlman wrote about using a Domain Specific Language (DSL) in an external document for API documentation. In his example developers would use some specific representations of how to use the API using text.

I imagine a structure where the documentation mimics the source code file structure, but for every code file a documentation file exists in its place. These files will be a superset of Markdown with extra formatting to denote namespaces, signature overloading, types and internal links. A generator would then convert the structure into HTML pages.

I’ll start with an example:

#Core.Crafty()
>Crafty(selectors:string) => <Core.Entity>
>Crafty(entityID:number)  => <Entity>
Select a set of or single entities by components or an entity's ID.

Crafty uses syntax similar to jQuery by having a selector engine to 
select entities by their components. Selecting by multiple components
is done by seperating with a comma or a space. A comma is similar
to OR where the entities can match one or more of the components. 
A space is similar to AND where entities have to match all the 
components.

##Example
    Crafty("MyComponent")
    Crafty("Hello 2D Component")
    Crafty("Hello, 2D, Component")

The first selector will return all entities that has the component 
MyComponent. The second will return all entities that has Hello 
and 2D and Component whereas the last will return all entities that
has at least one of those components (or).

**See also: <Crafty.map.search>**

In Markdown, a line starting with a single # means Heading 1. This will also denote a unit of code to document; such as a function, namespace or variable. It will also be used as the path for any other references in the documentation.

Grouping can be done by creating a path with a dot . as the separator. This could be used for categorising units of code or specifying a namespace path or even both at the same time!

As per Damon’s example, the greater than symbol > denotes a method signature where you specify the arguments as name:type (name is optional). The return type is specified after =>.

In my example the return type is wrapped in <angled brackets>. This represents an internal link to another unit. You may either specify the full path (as specified after the #) or use a subset of the path (assuming no collision) and the generator will pick it up.

Special files could be used for an Introduction, License information and even tutorials.

#Tutorial.RPG Demo
My tutorial formatted in Markdown!

The output of this format would be a hierarchy of units where each unit has its own HTML page. Templates for headers and footers would allow stronger customisation.

I would be interested in hearing some ideas on the subject. I think external documentation can create a greater separation between how to use the code and how the code works. It avoids huge source code files and can let the developers document in the format that suits the project.

HashBBG.com Sneak Peek

craftyjs — Mon, 09 Apr 2012 17:59:00 +1000

I had a go playing around with Drupal for the new and improved #BBG community site. It was surprisingly easy to get started and build a dynamic site. The content type feature was very helpful for customizing the data that BBG members will be posting.

The current content types are:

Projects: This is if members have created a project and want to share it. You can specify the repo and homepage.
Links: Sharing relevant links for HTML5 game development.
Text Posts: Purely text for those who don’t want a full blog but feel like writing about what they are working on.
Screenshots: An image and short description of the latest preview for any work in progress projects.
Poll: A standard poll to get a general opinion from the community.

All these posts will be aggregated under the members page as well as categorised for newcomers. This entire site was very quick to put together thanks to some great Drupal modules, not to mention a handy skill to learn for any future dynamic sites.

I have included a screenshot and will upload the site in the next couple of days or so.

A new direction for #BBG

craftyjs — Mon, 02 Apr 2012 15:44:01 +1000

If you haven’t heard of #BBG, check it out now! It’s an IRC channel on freenode.net dedicated to browser based games (regardless of your chosen tech) and boasts a variety of industry professionals from authors to engine developers.

We have a site dedicated to the community at hashbbg.com but we think it’s time for a revamp.

Profile Page

Members should be able to post links to anything new they are working on or have recently created. This would be posted on their profile page as well as in a feed on the home page (and a tweet from @HashBBG).

Events

We will need to add sections for the various events such as the BBGMeetup and BBGChallenge. The BBGMeetup will be more frequent once we secure some members who want to participate regularly.

Ask an HTML5 Dev

Myself and Andrew J Baker started a series on HTML5Grind where the community would decide on a question to ask professional HTML5 developers and we would compile a list of responses from members. We intend to bring that back.

Essentially we want a place where BBG members can post the amazing stuff they’re working on and where newcomers can discover the great developers behind the work. The site will be a community effort so any help is appreciated.

Self promotion should be encouraged

craftyjs — Sat, 31 Mar 2012 10:19:00 +1000

The web seems to favour curation over creation. Self promotion is generally frowned upon and most will tell you sharing a mix of other’s links and your own is more acceptable; but why? This only encourages curation and stunts creation.

Content is king

Once upon a time this was the mantra of the web. Content above all else is most important. By this logic it doesn’t matter where the content came from, as long as it is good quality content.

Self promotion is not always spam

Some regard self promotion as a form of spam. Spam implies the content is unwanted which to me depends on the quality and frequency as opposed to whether the owner submited it for self gain.

Curation promotes reposts and stale content

We should be actively seeking new and quality content rather than sharing an already popular link otherwise known as reposts.

Good content goes to waste

It is very hard for content creators to get noticed. Think of how many blogs, tech articles, tutorials, videos, stories, games, music, tools, software, services or webcomics exist on the web. Some of them might be good, some might be great and not all of them will be discovered by curators.

Different monetization methods for HTML5 games and apps

craftyjs — Thu, 29 Mar 2012 20:38:00 +1000

Monetization is one of many challenges when creating a game or app in HTML5. After all the effort it would only be fair to recieve minor compensation to keep development alive. The problem is deciding how to earn money from your creation while not affecting it’s growth.

A standard method is to offer a freemium model (free with ads, pay for more content). Another is in-game purchases. I was thinking about various other ways it could be done where the player has more incentive to pay.

Raffle

Players would have to buy the game to enter (say for $1). The prize could be 10% of the proceeds or any other reward. Players can win by beating a level first or holding the highest score by a certain date.

It would encourage players to buy the game, play it and most of all share it with friends as it would increase the winnings.

In-game product placement

This is just another form of advertising but more subtle than an attention grabbing advertisment blocking half the screen. In-game items that advertise a brand name would be less obtrusive and most likely more effective. Finding sponsors wouldn’t be easy but there are other sources such as affiliate marketing (see Amazon Affiliate Program).

Sell unobfuscated and commented source code

With HTML5 games and apps the source code will always be there for all to see even if obfuscated. One may as well either publicly release it or offer the full commented and styled source code for a fee, should developers want to learn or expand on it.

Merchandise

Companies like CafePress offer the ability to customise T shirts, stickers, posters and various types of merchandise to sell to loyal fans or even as a prize for the aforementioned raffle.

There is definitely room for some creative forms of monetization that benefit the developer as well as the player. I would be interested in hearing other ideas.

Simulating a player

craftyjs — Wed, 21 Mar 2012 15:16:00 +1000

Automated tests are a great way to do a sanity check against any changes you feel might affect other areas. You can quickly run some tests and ensure components do as they’re expected. This doesn’t cross over well into game development because other factors come into play such as input, randomization, networking and other variables that affect the program.

What’s really needed is to be able to simulate a player and observing the outcome exactly as it was when it was logged. To do this, every single variable that affects the game state has to be logged with a timestamp so it can be played back at the exact same interval. This includes randomly generated numbers, click or keyboard events, network data, time etc etc.

Benchmarking

There are more use cases than just automated tests. You can use it for benchmarking so that every platform you test will involve the same gameplay and actions. Domsz has done this for his game engine, ImpactJS.

Validate High Scores

Blindly accepting any high score as valid can and probably will lead to people sending requests with an obviously fake score. Sending the data to the server and replaying it to see what the end result is can be used to determine whether they cheated or not.

Multiplayer

Simulating the input on the server can be used for multiplayer games to keep two or more players in sync and prevent players from cheating. There’s obviously more to it than that but it’s an idea.

Gameplay

It’s now a common gameplay component to allow players to replay part of the game or for a stylised effect such as killcam.

For games that are heavily randomly generated (which a lot are), there is the option to save the seed used so all that is needed is to use the same seed when replaying to generate the same random numbers. Not all random functions provide this feature (JavaScript doesn’t). Another way around this is to log the generated value so when you replay it, use the same number that was generated last time.

There is a great post about implementing such as thing known as Deterministic Games. Unfortunately it is mainly relevant to the LWJGL framework.

Performance framework proof-of-concept

craftyjs — Sun, 18 Mar 2012 18:32:00 +1000

Performance is a very important factor for JavaScript games. It becomes a crucial factor when you bring mobile devices into the mix.

Luckily we have some great tools for testing different methods of coding such as JSPerf. This lets developers test code snippets across multiple browsers to compare.

On the same vein, JSGameBench stress tests rendering methods including WebGL, Canvas and DOM.

At Game Closure we want to look deeper and more thorough so I’ve been thinking about different ways to design a framework that will allow us to run tests with an assortment of different methods and combinations. With JSPerf one has to write individual test cases for every combination. Here is my proposal:

Templates

Code to test should have some templates that form the basis of what we’re testing. It is similar to startup and teardown methods but finer grained. You may want to move some startup code outside of the template to avoid it being benchmarked unnecessarily.

Placeholders

This is the key component to the power of this testing framework. Add placeholders in the template code that will be replaced based on the combinations being tested. The placeholders are denoted by a comment followed by a colon and the name of the placeholder.

function renderDOM() {
    dom.style.left = /*:x*/;
    dom.style.top = /*:y*/;
}

function renderCanvas() {
    ctx.drawImage(
        /*:type*/,
        /*:x*/,
        /*:y*/
    );
}

This looks like gibberish now but starts to make sense when you create a list of different values for these placeholders in the form of an object where the key is the name of the placeholder and the value is an array of possible combinations to test:

{
    x: [
        "~~x", 
        "x", 
        "Math.floor(x)"
    ],

    y: [
        "~~y", 
        "y", 
        "Math.floor(y)"
    ], 

    type: [
        "cnv", 
        "img"
    ]
}

The test framework will use all the possible combinations of these values testing to see which performs the best. You can also specify which functions to test against. In our case the two functions are “renderDOM” and “renderCanvas”. This means it will generate 36 combinations of the placeholders and functions.

Test it!

Running a test requires the startup code, a template defined with relevant placeholders and then an object with the combinations of values. You can optionally specify an amount of iterations to run (it defaults to 1000).

The above test gives us this:

~~x, ~~y, cnv, renderDOM | 28ms
~~x, ~~y, cnv, renderCanvas | 1222ms
~~x, ~~y, img, renderDOM | 18ms
~~x, ~~y, img, renderCanvas | 8ms
~~x, y, cnv, renderDOM | 33ms
~~x, y, cnv, renderCanvas | 1234ms
~~x, y, img, renderDOM | 33ms
~~x, y, img, renderCanvas | 8ms
~~x, Math.floor(y), cnv, renderDOM | 18ms
~~x, Math.floor(y), cnv, renderCanvas | 1237ms
~~x, Math.floor(y), img, renderDOM | 18ms
~~x, Math.floor(y), img, renderCanvas | 8ms
x, ~~y, cnv, renderDOM | 25ms
x, ~~y, cnv, renderCanvas | 1305ms
x, ~~y, img, renderDOM | 24ms
x, ~~y, img, renderCanvas | 7ms
x, y, cnv, renderDOM | 54ms
x, y, cnv, renderCanvas | 1322ms
x, y, img, renderDOM | 55ms
x, y, img, renderCanvas | 7ms
x, Math.floor(y), cnv, renderDOM | 25ms
x, Math.floor(y), cnv, renderCanvas | 1301ms
x, Math.floor(y), img, renderDOM | 26ms
x, Math.floor(y), img, renderCanvas | 8ms
Math.floor(x), ~~y, cnv, renderDOM | 18ms
Math.floor(x), ~~y, cnv, renderCanvas | 1238ms
Math.floor(x), ~~y, img, renderDOM | 18ms
Math.floor(x), ~~y, img, renderCanvas | 8ms
Math.floor(x), y, cnv, renderDOM | 36ms
Math.floor(x), y, cnv, renderCanvas | 1235ms
Math.floor(x), y, img, renderDOM | 34ms
Math.floor(x), y, img, renderCanvas | 7ms
Math.floor(x), Math.floor(y), cnv, renderDOM | 18ms
Math.floor(x), Math.floor(y), cnv, renderCanvas | 1235ms
Math.floor(x), Math.floor(y), img, renderDOM | 18ms
Math.floor(x), Math.floor(y), img, renderCanvas | 7ms

A few things to note is my method of benchmarking is currently very naive as this is a proof-of-concept. I will be looking into more solid forms detailed in this great post. The other thing to note is some of these tests are essentially duplicates. The renderDOM method doesn’t use the type placeholder so it generates combinations that have already been run. This isn’t really a problem and is more to do with how you define your templates and placeholders.

Analysing the data

Once we have this data we need a way to understand it and derive facts. I imagine a big table with the placeholders, functions and result as the columns and the combinations as the rows. You will be able to filter by placeholder values and sort ascending or descending on the result column.

Browsers

Running these tests against different browsers can be useful to determine cross-browser optimization or things to avoid. It is therefore important to be able to view and compare all the results and how they performed on which browsers. To display this in a table, the execution time column would have to include the result from different browsers. This could be done by adding a column for each browser result and keeping the main result as an average.

These ideas are still very early stage and I have only recently managed to get code executing from placeholders and generating combinations. I will do more research to determine how it can be more useful for existing projects and how to best display the data. Maybe even a GUI along the lines of JSPerf could make it more helpful.

Entity Component Systems: Inheritance vs Composition

craftyjs — Wed, 14 Mar 2012 15:36:00 +1000

My methodology of choice for game development is something known as an Entity Component System. Entities are game objects, they have no functionality until you apply components. This avoids long chains of inheritance so is easier to maintain and reuse.

There are two ways to implement Entity Component Systems, through composition or inheritance.

Crafty uses an entity component system through inheritance. An entity starts its life as a simple object, when you add a component the entity inherits all the functionality. It is similar to one layer of multiple inheritance (without the diamond problem) or mixins.

This makes abstraction easier where components can reference any other components without needing to know which component it is so long as they both implement the same interface. Crafty does this for the DOM and Canvas components.

There is an obvious problem with the lack of namespacing: naming collisions. I personally haven’t come across this yet (probably because I know the names of the internals) but it seems others have. It’s also not very elegant as your entities end up as big blob objects.

Composition seems to be the preferred way of doing things. Through composition you would create an instance of the component and give the entity a reference to it. This may seem elegant but how do components talk to each other? The only way to go about component communication is by giving the component a reference back to the entity.

CompA = Class(Component, function() {
    this.method = function() {
        this.owner.getComponent("CompB").method();
    }
});

We can get a direct reference to another component through the entity (this.owner) and we have component communication. But there are a few problems with this solution. First of all it’s hideously verbose but worst of all it creates a tight coupling between CompA and CompB. What if we change the name or can’t be sure what the component will be (say if there were two components that implement the same interface)?

The solution to this is messages or events. Tell the entity the component wants to send a message to all other components that want to listen. Other components can register a callback to those messages and decide what to do.

CompA = Class(Component, function() {
    this.method = function() {
        this.owner.sendMessage("doSomething");
    }
});

CompB = Class(Component, function() {
    this.method = function() {
        this.owner.recieveMessage("doSomething", this.doSomethingHandler);
    }

    this.doSomethingHandler = function() {
        //no coupling! :)
    }
});

Now the components are completely seperate from each other and can be individually replaced without worrying about dependencies. I mentioned my distaste for verbose solutions but luckily in the land of JavaScript we can make nice short cuts.

CompB = Class(Component, function() {
    this.onDoSomething = function() {
        //no coupling! :)
    }
});

The message dispatcher will just see if any components have a function called “on” + the message name and execute it.

While this approach is very elegant and decoupled it’s not a perfect solution. What about a component that changes the position of the entity. Sending a message each time gets tedious especially if that component is never going to change or be replaced (such as a Position component). In these situations keeping a reference isn’t so bad:

CompB = Class(Component, function() {
    this.init = function() {
        this.Position = this.owner.getComponent("Position");
    }

    this.onDoSomething = function() {
        this.Position.x += 10;
    }
});

My personal preference is through composition and message passing. It seems to be more flexible and has no real drawbacks.

Pointer Lock for building an FPS

craftyjs — Tue, 13 Mar 2012 14:34:00 +1000

Now that Pointer Lock (formerly known as Mouse Lock) is semi-available in Chrome I decided to have a play with it.

My friend Andrew Baker has a very easy to use 2.5D renderer and a first person demo to go with it. I went about adding mouse support for the demo.

Firstly you need to enable Pointer Lock in about:flags. Put that in the address bar then scroll down to “Enable Pointer Lock” and relaunch Chrome.

While reading the Pointer Lock API on MDN I noticed that Chrome requires the page to be in the fullscreen state. This is simple enough (note that element is a DOMElement such as a canvas node):

element.webkitRequestFullScreen()

This revealed a problem. None of the keyboard events worked and the docs never mentioned this. After searching for a while I came across Brandon’s blog post on the subject. To allow the keyboard events to work in fullscreen mode, you have to pass in the ALLOW_KEYBOARD_INPUT constant:

element.webkitRequestFullScreen(element.ALLOW_KEYBOARD_INPUT)

To request a pointer lock on an element, you must use navigator.pointer.lock. In Chrome this is under the namespace navigator.webkitPointer. To normalise this you will want to add the following:

navigator.pointer = navigator.pointer || navigator.webkitPointer;

So after the request for fullscreen mode has been called we can request the pointer lock.

navigator.pointer.lock(element, 
    function() { 
        console.log("Request Succeeded") 
    }, 
    function() { 
        console.log("Request Failed") 
    }
);

In my version of Chrome (17.0.963.79 on Windows 7) I noticed that neither of these callbacks were called. The second thing I noticed was a. the cursor wasn’t hidden and b. the cursor wasn’t actually locked and it could move out of the bounds of the element. The only feature that actually worked were the mouse events (movementX/Y). To make use of this, just bind the element to the mousemove event and the movementX/Y values will be in the event object:

var sensitivity = 0.4; //the lower the less sensitive
element.addEventListener("mousemove", function(e) {
    var pos = {
        movementX: e.movementX || e.webkitMovementX,
        movementY: e.movementY || e.webkitMovementY,
    };

    if(pos.movementX < 0) {
        Mars.turnLeft((-pos.movementX) * sensitivity);
    } else {
        Mars.turnRight(pos.movementX * sensitivity);
    }
}, false);

If the movementX value was negative then the mouse was moved to the left. The values are actually the change in position since it was moved or the delta. By adding a sensitivity multiplier you can manipulate how much of an effect the movement values have on the view.

These new event values are great but isn’t useful if the mouse isn’t actually locked. I will have a play with non-stable versions of Chrome to see if it has been implemented but for now it’s not very helpful.

Checkout the latest demo from this article and tell me if it works on your browser or not.

Edit: I installed Chrome Beta (18.0.1025.56) and I can confirm it works perfectly :) The cursor is hidden and locked. Should be in the next release very soon! I look forward to the opportunities this creates for HTML5 games.

Fixing CSS through a UI library

craftyjs — Mon, 12 Mar 2012 09:58:27 +1000

I believe CSS is one of the best methods of building interfaces. If you’ve used Swing, Tkinter or the like you will probably agree with me. The ability to style rectangles through selectors really segregates the data from the view.

That being said there are many things I would change and have been doing so through a User Interface library (to be implemented in the Game Closure SDK).

1. Positions and Dimensions

With CSS you can set the position and dimensions in a few different units, the most useful being pixels (px) and percentages (%). There have been many occasions where I needed to use both in a calculation. For instance having a box with a height of 100% minus a few pixels. To do this in CSS you would need to either use JavaScript or change the structure of the HTML.

My UI lib will take a basic expression such as: 100% - 30px. I was even toying with the idea of allowing developers to pass a callback for even more control over how it is calculated.

CSS manages flow and automatically positions elements based on it’s surrounding elements. This is very helpful when building a website. But building a user interface… not so much. My UI lib treats every element as if it had position: absolute applied. This may sound painful but it is made easier by the fact you can position elements using percentages and calculations. For instance imagine a UI with two columns:

column1 = new Panel({
    left: 0,
    top: 0,
    width: "50%",
    height: "100%"
});

column2 = new Panel({
    left: "50%",
    top: 0,
    width: "50%",
    height: "100%"
});

Easy!

2. The Box Model

This has recently become more of a known issue. The W3C box model is plain silly and believe it or not IE got it right (in my opinion). The W3C box model states that the width of an element is the inner most content. The IE box model states the width includes it’s border, padding and inner content. Confusing? See the diagram below:

My UI lib takes the IE approach. This means you can set the width to a logical unit and change the border and padding to your hearts content without worrying about changing the width to match. You can actually use the IE box model in your CSS today by using box-sizing: border-box.

You can see a not so recent live demo here. The currently supported properties are: borderColor, borderSize, borderRadius, backgroundColor, headerColor, padding, margin, fontSize, fontFamily, fontColor, textBaseline, lineHeight, opacity, width, height, left and top with more to come!

Unobtrusive Game Engines

craftyjs — Sun, 11 Mar 2012 15:19:00 +1000

We’ve suddenly seen an uprising up HTML5 game engines over the last year. To me not many of them stand out and that’s a personal opinion. Maybe because the things I look for in an engine is not actually an engine but a library. The best engine is the one I can replace.

I don’t like the idea of being tightly coupled to a game engine. Too much of the code base becomes unknown and at risk of deprecation or API changes. I also don’t want to be forced to use a methodology (MVC, entity component). This is probably why we have so many engines. Every developer has their own style and if they can’t reflect that in an engine they get frustrated and make one that can.

Take the UNIX philosphy: Rule of Separation: Separate policy from mechanism; separate interfaces from engines. http://www.faqs.org/docs/artu/ch01s06.html ‘Basics of the Unix Philosophy’

Here’s my wishlist of the perfect game engine which from now on I shall call library.

1. Hook for tick and render

This is the most basic requirement for creating a game. An unobtrusive API might be:

Game.tick(function(dt, frameNumber) {
    //register a callback on tick
});

The render hook would be similar:

Game.render(function(ctx) {

});

The important thing here is that I still have control and I can easily replace the library with something else that implements the same basic API. Heck, I could write a basic wrapper should another engine not implement it.

2. Input

An abstract layer for inputs that can generalise touch and mouse events and even keyboard events.

Game.input(function(type, e) {
    //type = Click, Down, Up, Key
    //e = Event object includes position in form of Point
    //    or key code for keyboard events
});

Generally you want to know if an entity lies within the position from the event. Which leads us to our next feature.

3. Maths

Some basic algorithms commonly used in 2D games such as SAT collision, polygons, points, rects, spatial data structures but again no dependence on how the entities are stored.

//Point = {x: Number, y: Number}
Game.math.pointInRect(Point, Rect);

//Rect = {x: Number, y: Number, w: Number, h: Number}
Game.math.collision(Rect, Rect[]);

However you organise game objects it should be simple enough to export it to the Rect interface if it isn’t stored like that already.

For determining if the user clicked/touched our entity:

Game.input(function(type, e) {
    if(Game.math.pointInRect(e.point, entity.rect)) {
        //clicked/touched
    }
});

Even if this is too verbose it is simple enough for the developer to write another abstraction that suits them.

4. Mobile Support

Most mobile browsers are capable of rendering the Canvas element. The issues arrive with resolution, aspect ratio and sizing the stage.

We don’t want an implementation that will be obtrusive so this can’t be an automatic fix.

if(Game.isMobile) {
    Game.maintainRatio(DOMElement);
}

This would detect if the user is on a mobile device, make the specified element “fullscreen” by scaling it as big as possible while maintaining the aspect ratio and using a black background for a letterbox effect.

Again, the problem here is this doesn’t match all solutions and is the reason this can’t happen automatically. What if the game was meant to stretch?

Game.stretch(DOMElement);

This will make the specified element as big as the window (so it doesn’t matter if it’s on mobile or not).

To find out the size of the stage:

Game.width; //Number
Game.height; //Number

5. Modular

I see mobile support as more of a module or extension than part of the core. Therefore the game library should allow extensions.

Game.extend({
    maintainRation: function(el) {},
    stretch: function(el) {}
});

I haven’t actually written this library, it’s just my ideas for a game library that would be flexible enough so developers can add their own touch to it without being forced into a style or methodology they dislike. Would love to hear feedback about this concept.

Some initial code for proof of concept is up here: https://github.com/louisstow/Game

The Return of Adventure Games

craftyjs — Sat, 10 Mar 2012 18:46:00 +1000

Growing up I never really took a shine to adventure games. I was very impatient and didn’t like to be mentally bested by a game. Only recently am I starting to see the appeal. My girlfriend is creating an HTML5 adventure game for her thesis (using Crafty) so I was introduced to the greats such as Day of the Tentacle.

It would be a sin to not mention the massive success of Double Fine’s new adventure game project. This alone shows how nostalgic this genre is to many many gamers.

This led me to think about implementing the genre for mobile devices and browsers. The genre is almost perfect for casual gaming. You can solve small puzzles in pockets of spare time and none of the immersion is lost.

This then led me to think about a framework for building adventure games where various callbacks would help construct the puzzles and gameplay. Typically adventure games are built up of:

Scenes
Actors
Items
Dialogue
Actions

Scenes being small rooms or areas the player can explore to find items and solve puzzles. Callbacks for scenes would include entering a scene, exiting a scene.

var Intro = Class(Scene, function(supr) {
    this.init = function(opts) {};

    this.onEnter = function(previousScene) {};
    this.onExit = function(nextScene) {};
});

Actors would be NPCs that can initiate dialogue and potentially reveal information or a piece of the puzzle if the player says the correct things. Actors could also be part of the scene that isn’t an item but reacts when used with an item.

var NPC = Class(Actor, function(supr) {
    this.init = function(opts) {}

    this.onPush = function() {};
    this.onPull = function() {};
    this.onOpen = function() {};
    this.onClose = function() {};
});

Items are things inside scenes that progress the plot and can be used to solve smaller puzzles. These usually have the biggest impact on gameplay and contribution towards a resolution. Some callbacks for items would be using an item, combining an item with another item or combining an item with an actor.

var MyItem = Class(Item, function(supr) {
    this.init = function(opts) {};

    this.onUse = function() {};
    this.onCombineItem = function(otherItem) {};
    this.onCombineActor = function(otherActor) {};
});

Dialogue usually has a few options about what you want to say to an actor which will either trigger another line from an actor, conclude the conversation or progress the plot. You could make some lines of dialogue have the same effect or a line of dialogue could be key to solving a puzzle. Callbacks would be when the player selects a line of dialogue.

var TalkingDude = Class(Actor, function() {
    this.onDialogue = function(lineSpoken) {};
});

Actions are how the player interacts with items, scenes and actors. Callbacks would be placed on Actors and Items for various actions such as open, close, push, pull, use, etc etc.

var MyItem = Class(Item, function(supr) {
    this.init = function(opts) {};

    this.onPush = function() {};
    this.onPull = function() {};
    this.onOpen = function() {};
    this.onClose = function() {};
});

I know this isn’t anything concrete but it is my interpretation of building an adventure game with the intention of modular and ultimate reuse. I intend to do more tinkering to come up with some working demos and maybe even design a JSON format to build scenes and lines of dialogue.

Welcome!

craftyjs — Sat, 10 Mar 2012 17:27:43 +1000

Hello all. I’ve decided to beef up my personal brand recognition, rather than networking under the guise of “that Crafty dude”.

It also allows me to post interesting things about the web but not necessarily related to Crafty.

Still trying to figure out how this will all be formatted (such as code snippets) so bare with me while I learn how to blog.

Bye!