Wright! Magazine uses a custom built Javascript game engine with any other external dependence that uses some standardized technologies for video, audio and input processing that are usually implemented in most of the web browsers - so that means that Wright! games can run on multiple operating systems and devices, included mobile one with touch screen.

You can use it as a complete game engine as I'm doing within this magazine, but the Wright! engine was built for being as short in length and as much lightweight as possible, so you can read its code, understand how it works and - eventually - use it as inspiration for your own projects. Yeah, It's missing comments and some good documentation but... It's how it worked when game source codes used to be printed on magazine, so Wright! is opensourced and MIT licensed by design.

It implements a 2D renderer for drawing stuff on the screen, that uses DOM elements (i.e. the stuff you can usually find in a web page, like images and text - but used in the wrong way) or a CANVAS element, in which you can draw what you want, that was introduced with HTML5 few years ago and works like true 2D libraries like the old good SDL libraries, which is way better for videogames. You usually can switch the rendere when starting a game - nothing relevant changes.

So what's the point of having 2 renderers on a web game engine? Early web game developers that already discoverd the potential of Javascript back in the '90s, when it was just used for field validation in forms, used to move HTML tags on the page for making small games, so I decided to use the same technique for celebrating them. Later I decided to try porting everything to the CANVAS tag, as I did for the Akihabara game library in 2010, keeping everything compatible as a challenge. The result is: Wright! engine covers almost 30 years of web game development techniques in a single project. Just because.

It contains a custom made rectangle-based physics engine that's quite sketchy but short, fast and works enough for most of the arcade games I'm going to develop. Obviously some of the games that were suggested to me by friends along these years mostly needed a full featured engine, like a pinball, golf or fishing games, but, despite the hate I had for these bad people, early videogames on 8 bit machines used to work fine mostly without physics... so - Wright! game engine physics engine is limited but pretty enough for me :)

Scripting is done mostly via JSON with a technique I use to call 'stencils': everything in this game is described by a set of key/values I call 'stencil', which defines how it looks (i.e. the bat of pong has a long height, short width and a white color) and how it behaves (i.e. moves up and down with keys and blinks when winning). Multiple stencils can be merged together in order to create object variants, so the left and right Pong bats have a basic stencil that describes how they look and move, but the left one is merged with another stencil that places it on that side of the screen and moves with the player 1 keys and the right one with the opposite. That makes the code of most of the games reusable from game to game - and that's why most of them are made in just two weeks of lunch breaks :)

Music mainly uses HTML5's Web Audio API, adding audio channels (i.e. different default volume for music and sound effects), simplified sound effects (i.e. fading) that can be automatically applied by some game elements, like music fading together with screen.

Many advanced features of a game engine have been cut or implemented with simplicity in mind: animations are implemented with a simple frame-by-frame sequence, artificial intelligence is implemented ad-hoc for every game using the JSON scripting language that decides object logic, memory management is done mainly by the Javascript virtual machine and networking play and localization are still missing - and not planned.

Wright! engine doesn't use any tilemap implementation in order to keep game code simple but uses a 'clustering' technique instead, in which every object in the game is automatically gathered in a grid of groups depending on their position on the screen, so just the clusters around the visible part of the scene are rendered - and only clusters around an object are evaluated in collisions. That means that, while there isn't a clear implementation of tilemaps, everything is in a giant tilemap!

Wright! changed a lot of times during these years, changing, dropping and adding features but one thing still amazes me every time, despite I've developed this by my own: once found a funny and fair compromise, a game is always possible. The No Man's Sky demake called 'Bounds Unknown' has a simple superformula implementation in its own JSON code!

To celebrate the control system rewrite, that allow multiple control configurations and touch screen layouts, let's play a competitive offline multiplayer game! Well... probably one of the oldest ever made. Whatever.

Plot!

This is like tennis, but in the future! Kick the ball back to your opponent field and let him lose it! Use the START button for starting a new match and use UP/DOWN for moving your bat. Good luck!

(Want to share something? You can find me on Twitter!)

Install / Add to home View game sources ...or play it online below!