Learning Web Assembly

Web Assembly is a technology that allows code to be compiled to a portable byte code that can be run at near-native performance.

Web Assembly modules can be run by modern browsers and called from within the Javascript of a normal web page.

This offers the tantalizing prospect of creating high-performance code for games that can run on multiple platforms without the need for the user to download or install any ‘apps’.

Mandelbrot Web Assembly

A view from within the Mandelbrot Set

The first full project I have completed using Web Assembly in the browser is a Mandelbrot Fractal Explorer.

This was a good project to learn Web Assembly as it involves a looping procedure that can require many thousands of iterations.

The Mandelbrot Set is implemented in C with a function that can be called from Javascript. There is no shared state between any of the function calls.

You can try the Mandelbrot Explorer here:

https://www.goshdarngames.com/mandelbrot/

The source code is available here – in a repository I’m using to collect the projects I use to learn how to use Web Assembly:

https://github.com/goshdarngames/LearningWebAssembly

Future Learning

The next project I try with Web Assembly will be a Cellular Automata. This will let me try something with a persistent state inside the Web-Assembly module.

I’d like to try using PixiJS as a renderer to see if it’s possible to speed up the access to the pixel buffer.

The GUI for the Mandelbrot explorer was hacked together in a few days using native Javascript. It is a bit of a pain to keep a DOM form full of data in sync with the data being used to render the image so I may try using a framework such as VueJS for this purpose.

Learning how to render the Mandelbrot set is a lot of fun and it is addictive to mess with the colours and improve performance. I ultimately decided on a limited set of features just to get the project complete as my main goal was to learn Web Assembly – not make the perfect Mandelbrot renderer.

A gallery of screenshots taken during the development process can be found here:

Get Lamp

Interactive Fiction on Twitter

I put together a twitter bot that lets you play classic Text Based Adventures through twitter. The bot runs a game on a Raspberry Pi and tweets the console output from the game. Periodically the bot checks its mentions for tweets containing commands and sends those to the game.

The bot’s twitter feed can be found here:

https://twitter.com/TweetIntFict

The source code for the bot can be found here:

https://github.com/goshdarngames/TwitterAdventureBot

I made the bot after watching an interesting documentary on the history of Interactive Fiction:

The project served as a good distraction from burnout on my other project – virtual reality snake. In that project I have been using Test Driven Development fairly heavily with the goal of having complete test coverage. It’s slow going and I reached a breaking point when I went to shuffle a list in JavaScript and found that I would have to write my own shuffle function. I didn’t really feel like writing a Fischer-Yates shuffle for the millionth time

Making a project using Python was a nice change of pace since it includes most of those little functions you often find yourself needing.

The twitter bot also served as a good opportunity to make a project using Docker. Containerization on Linux is a new concept to me and I have to say I’m completely blown away by it. It solves a lot of the problems I was having with Python in the past – chiefly: packaging Python programs for other people to use.

Repeat Fractal

I put a gallery of fractals I made here:


Looking for underground bunkers to rent…

The future is made of virtual reality. Soon there will be no sound apart from the occasional thwacking of controllers hitting furniture.

WebVR with Babylon JS

Babylon JS is a 3D graphics library targeting HTML Canvas with WebGL. It includes support for WebVR and with relatively minimal setup you can get the controllers working in a simple VR space:

WRM Controller in BabylonJS

WRM Controller in BabylonJS

That’s a screen shot I took from within a virtual reality session running inside a web browser!

I’m working on a simple game of Simon Says to test the VR waters. You can follow the progress in the repository here:

https://github.com/goshdarngames/Simon-Says-VR

The main goal of the project is to create a ‘base game’ that can be adapted to future projects. Learning the Babyon library is great. It astounds me that you can get high quality 3D graphics out of a web browser without needing to download any additional plug-ins.

Smell You Later Cell-u-later…

My work with Cellular Automata with Python hit a brick wall.

I was using Cython to run the expensive inner loops with C. This gave great run-time speeds.

Unfortunately I was unable to package the code so that it could be easily downloaded from repositories. After editing what seemed like a thousand config files I was burnt out.

I am still interested in using cellular automata to create a game similation. I hope to try and get something running in future using Web Assembly. It has the promise of C-like speed with the ease of distribution of a website that runs in the browser.

Devlog – Gift-wrapped Python

Cellular Automata with Python

I am interested in exploring game design focused around simulating a game world using Cellular Automata.

Conway's Game of Life

Conway’s Game of Life

Using Python I have implemented Conway’s Game of Life. The code for the project can be found in this Git Hub repository:

https://github.com/goshdarngames/Autumn-CA

The code is still quite rough around the edges with plenty of TODO statements to be found.

Creating a Python Packagae

Usually I would dump my code in a folder and call it a day but for this project I decided to try and follow standard Python practice as much as possible.

This talk from Dave Forgac was a great resource:

The process of using Virtual Environments, Cookie Cutter and Tox integration testing tools was well explained.

I ran into some difficulty getting my Cython code to build correctly as this was outside the scope of the video.

After some searching I found the solution was to update the manifest file to include the code:

https://stackoverflow.com/questions/43163315/how-to-include-header-file-in-cython-correctly-setup-py#43364656

Conclusion

The Autumn CA package provides Cellular Automata computing through NumPy arrays.

Other tools such as rendering engines could import this package.

Most of the work in the short term will be ensuring the code works as a standard Python package.

Devlog – Cellular Automata

Simulating the Universe

Cellular Automata could provide interesting results for the simulation of video game worlds.

Systems using this model are described by a regular grid of cells with a numerical state. During the simulation each cell decides its next state by applying a rule function to the cells next to it.

An example of such a system is Conway’s Game of Life. This famous Cellular Automaton shows how incredible complexity can arise from a system with simple rules.

All of the cells change their state at the same time using the data from the last state. This is interesting because it means Cellular Automata could benefit from parallel processing from multi-core CPUs, GPUs and perhaps even Quantum Computing.

Besides simulating the universe Cellular Automata can be used to make psychedelic ‘living paintings’:

Creating my own CA with Python

I have made some progress in creating my own Cellular Automata using Python:

Game Of Life - Python

Conway’s game of life running in Python. Rendered using Pygame.

The first iteration can run a 100×100 simulation at around 13 frames per second. Python’s lists were used for the data structure so the performance is not great.

Now that I have the basic structure of the program and benchmarking system I am working on making a faster version using the NumPy library. It provides access to fast arrays implemented in C so it should be possible to make the simulation much faster.

Unfortunately the process of speeding up the program is more involved than putting ‘import numpy’ at the top of the file. This is my first time trying to use NumPy Arrays and it is an interesting learning process!

DevLog: One Step Forwards – Two Steps Back

The development of the Flower Plower prototype is currently on pause.

Flower Plower started 5 months ago with the hopes of making a ‘quick prototype’ that would give me a chance to develop my tools and frameworks so that future games could be prototyped more quickly.

The overall design of the game was not completely solid. I had some vague ideas of how things would work but changed my mind as things progressed. The design of the project changed from Pacman to Chu Chu Rocket.

While I still really like the idea for Flower Plower as a simulation puzzle the process of converting the code from how it was designed for a maze running arcade game to a puzzle game is getting in the way of the initial goal for the game: Optimize my Unity Workflow

The work I have done so far on Flower Plower was by no means a waste of time as I was focusing on code that I can re-use for any game.

I have taken the code that I developed for Flower Plower and re-purposed it for a new game. Now I can focus on building my tools and solving the problems relevant to many games rather than refactoring classes and staring at compiler warnings.

The idea for the new game is kinda dumb so I’m really excited to work on it!

Devlog – Discretion Required

Booming flower prices promise great rewards for the fastest Flower Plower!

Initially Flower Plower was conceived as a Pacman style maze running game.

The design of that game called for a continuous movement grid. Objects on the grid can move smoothly between grid cells but are only allowed to turn when they are in the center of a grid space.

Objects have two variables controlling their direction. Current Direction and Desired Direction. If the object wants to change its direction it sets the Desired Direction variable.

When the object reaches the center of a grid space it checks if the Current Direction is equal to Desired Direction and tries to turn if not. If a wall is blocking the turn the Current Direction remains the same until it is possible to turn.

This system allows the player to hold the direction they want to turn early and their character will turn when it is possible.

Continuous Grid Turn

Objects move continuously and are only allowed to turn in the center of a grid node.

One added complexity is allowing 180 degree turns in between tiles. It might feel better to allow players to turn slightly late and move back to perform a turn – just a slightly wider window of opportunity.

This system works well for a Pacman style maze runner but now that my prototype is heading in a simulation puzzle direction I have decided to use a discrete grid.

A discrete grid uses arrays of integers for positions rather than Unity vector3s with float values. This means that an object can not be between two grid locations.

This approach has brought with it a lot of additional complexity but I am starting to see the light at the end of the tunnel! So hopefully there will be more details in a future post.

Devlog – Fine by Design

Coordinate the chaos of flower farming during boom times. Become the ultimate Flower Plower

The Limitations of the Design

The initial plan for the game was something similar to Pac Man where you plant seeds and grow flowers.


As development progressed important questions such as ‘What should the player do?’ and ‘What makes the game fun?’ were mostly answered by hand waving.

The rough idea is that the player would plant flowers in the paths between fields. The fields would be filled with sheep who would periodically move from one field to another blocking the paths. As the game progressed the player would expand their network of fields and paths so the strategy would be to create paths that would be good for farming big combos from the flowers while still having enough branches to avoid the sheep.

On the surface it sounds great but when trying to make the ideas more concrete it becomes more difficult to find the fun. Flocks of sheep that block the maze as the main obstacle isn’t great and while the idea that the player creates their own maze is cool the mazes would ultimately be a little dull. After creating your own 4 directional maze you will still end up with a simple maze – it’s hard to see where there’s much room for excitement.

Simulation Puzzle

So the new idea is something of a Simulation Puzzle.

The player places signals on the farm that control the movement of tractors. The tractors pull trailers that will perform actions such as planting seeds and harvesting flowers. The game will reward getting things done as fast as possible and their will be an emphasis on timing actions so that they occur simultaneously.

The main influences on the design currently would be the Dreamcast classic Chu Chu Rocket and a great construction sim called Factorio. There should be plenty of potential fun to be found from setting a farm up, watching it run and trying to improve the amount of flowers you can produce.

Implementation Progress

A focus of the implementation strategy is to reduce coupling between components so that the game objects can be repurposed without throwing out all the code. Happily the plan is working and good progress is being made.

The new design does have the requirement that objects should move across the grid in a predictable fashion.

Objects move continuously through the grid using floating point numbers to represent their current position. The downside to this is that if you move two objects the same distance at the same speed they may arrive on different frames.

This indeterminism is caused by inaccuracies that can result from rounding floating point numbers. Long numbers can’t be represented exactly by a 32-bit number so over time mistakes will creep in.

I have dealt with this problem before when trying to make an action replay system for Jet The Pack and my solution then was to just scrap the replay system. It’s very hard to get the Unity physics engine to do the same thing twice.

For this game I plan to update the objects that move on the grid so that logically they are only ever in the center of a tile. They can move periodically using a tick sent through the event system and the meshes that provide their graphics on-screen can be moved over time using linear interpolation.

Devlog – Every Event Needs a Queue

Sow the seeds of an ultimate score rush combo in Flower Plower!

Before adding exciting gameplay features an important question has to be answered:

How do game objects talk to each other?

One of the most important goals of software design is to reduce coupling.

Coupling occurs when the actions of one system depend on the state of another. If two objects are coupled then making changes one could result in a bug in the other. As the game grows in complexity this can lead to frustrating hours reading stack traces.

Ideally the components of the game should know nothing about each other. The tractor should have no idea what a flower is, how gravity ties it to the road or what strange force is compelling it to change direction. The tractor should sit in isolation just doing whatever tractors do.

If all the components are completely separate then how does the system handle interactions between them? How does the tractor tell the game that it just harvested a flower and scored a point if it doesn’t know what a flower is or even that its performance as a tractor is being evaluated?

This is where Software Design Patterns come in handy. This problem of code getting hairy when components meet has been suffered and studied for a long time. Some smart people have identified the problems that happen most frequently and come up with some template solutions that can solve them.

For this project I went with the Event Queue:

http://gameprogrammingpatterns.com/event-queue.html

The specifics of my Unity implementation are somewhat different but it has the following features:

  • An Event Queue component can be added to any object and stores a list of events that happened on that frame – the list is cleared during LateUpdate (So technically it’s the events that happened last frame).
  • Objects can read or post events using an Event Queue Accessor component. The accessor component stores a reference to the event queue and actively checks rather than being notified by the queue.
  • The Event Queue does not store a reference to Event Accessor components so it will not keep them alive if they are destroyed. The accessors need to have their reference to the queue set when they are cloned at run time.

An example of how I have used it in Flower Plower would be the detection of the tractor colliding with the flower. Both these objects have a parent called ‘Farm’ with an event queue.

When the flower collider detects a collision with a harvester it puts a ‘Flower Harvested’ event on the farm’s queue. The Score and Audio system don’t need to know the specifics of the collision but they can check the farm’s event queue to find out what’s going on on the farm.

It’s a powerful idea that the Flower and Tractor can do their thing without having to report to any component except to say ‘This Happened’ to the event manager it makes it possible to combine modules in various ways. E.g. the same Tractor that is used for player control could be used in a game demo system.

It took a lot of work to prototype this important system but hopefully it will work well throughout the rest of the development.

As a reward for making it through that wall of text here’s a bonus video of some integration tests running!

Just look at those glorious green ticks.

Each test starts the game and goes through the menus before doing their thing so any weird edge-cases will be caught! My last game Spacebomb has some glitches that can make the player totally invincible so I’d like to avoid that this time.

Devlog – Progressive Regression

Flower Plower is an arcade maze runner where you use a tractor to plant and harvest flowers. Score enough points and you can create new areas on the map. Shape the layout of the maze to maximize your combos and achieve high scores. Just don’t run over your sheep!

Prototype

Progress is coming along nicely on the prototype version of flower plower.

The basic mechanics of driving a tractor around planting and harvesting flowers are in place as this high quality but low file-size webm video will show

Recording videos and producing good quality web-friendly videos has been a learning curve. The current process is as follows:

  1. Record the screen using Open Broadcaster Software
  2. Edit the video using Power Director
  3. Convert to the video to webm using FFMPEG (My version of Power Director does not support webm).

It’s a slow process but it works!

Regression Testing

There’s currently a bug that occurs when the player changes direction when between two tiles.

As part of my new commitment to following some sort of Software Engineering practice I decided to make a test to re-create the bug before even attempting to fix it:

I had to redesign the input handling so that it would be possible to control the tractor via test scripts. The code is a lot stronger as a result!

I used the Command Pattern to encapsulate any calls to Unity’s Input methods. It helps reduce coupling and now it’s possible to create some sort of replay system if I decide to.

Creating a test that recreates the bug before attempting to fix it is a nice way to approach the problem as it gives you a chance to figure out exactly what the problem is before poking in code.

Unity’s Test Runner is great for executing testings from within the editor. It’s satisfying to watch all the tests run…