Our first game jam: Ludum Dare 33

Last weekend David and I took part in our first ‘game jam’ event. As part of Ludum Dare 33 we had 72 hours in which to make a game from scratch (or as close to that as possible) following a prescribed theme. You can find our live-updates that David was posting throughout the weekend on our Ludum Dare page (start from the bottom) but I’ll give a summary here.

If you would like to play the game it’s available from our Ludum Dare page or directly from our website. You can also download the project source.

The weekend


David arrived at my house on Friday and while waiting on the official start and theme announcement (not until 2:00 Saturday morning) we had to decide on the technology we would use. It came down to a choice between something simple in 2D using HTML5 or Python or making use of Cubiquity in a full 3D game engine like Unity3D or Unreal Engine. While I was apprehensive about the production-readiness of Cubiquity for Unreal Engine we decided that it was worth giving it chance, even just as a test of the system. Also we really wanted to have destructible scenery worked into the game somehow!


Saturday morning we woke up to find out the theme this time was ‘you are the monster’. After working through some ideas (hunting Pac-Man as a ghost or a moving-maze labyrinth game) we settled on a simple fantasy-style twin-stick shooter where you kill villagers with fireballs. Choosing the game to make was one of the hardest parts as it’s very easy to get carried away and it’s difficult to have a sense up-front as to the difficulty of some part of the design. Deciding to start from as simple a concept as possible with plenty of scope for adding features along the way definitely turned out to be the right decision as we were able to get a first draft working quickly, knowing that we would have something to ship.

Since we were using Unreal Engine we decided that I would do the programming and David would develop the artwork. I set to work playing with the twin-stick template provided by Unreal Engine and tried to get a handle on how AI and navigation works in UE4 (something I’d never worked with before). The documentation on this was very good though and within a few hours I had a working prototype with enemies moving towards the player, firing arrows.

Meanwhile David had been hard at work getting some assets ready, primarily a first draft of the game level and some character art. All the artwork was done using MagicaVoxel which David had never used before now either.

The monster

The monster in MagicaVoxel about 16:00 on Saturday

By the end of Saturday David had most of the in-game props made (including towers and trees) and was starting to get more artistic with the design of the level itself. I however, having got Cubiquity integrated was having a lot of trouble getting it to play along with Unreal’s navigation mesh creation. In the case that we weren’t able to get the two to play nicely within the time limit we devised a potential hack of making the Cubiquity terrain simply visual but non-blocking and recreating the basic collision shapes with Unreal primitives for the navigation system to use.

We went to bed exhausted from a fraught day, not quite as far along as we would have liked but happy with the progress nonetheless.


I started Sunday with the aim of getting a complete working first version with as much of the art in as possible and all of the basic features. It was helpful for David to see the art in-game so that he could start iterating and make sure that everything looked correctly scaled against each-other. By mid-afternoon we had a first complete version of the map in the game and an early version of the complete combat process between the peasants and the monster.

First version of the models and scenery in-game

First version of the models and scenery in-game about 16:00 on Sunday

From this point on it was ‘simply’ a very large polishing process and working through our feature wishlist, hoping to get as far as destructible terrain. Throughout Sunday afternoon and evening we really found our flow and were both making very good progress. By the end of the day David had mostly finished the game map and I had a working game which, if necessary, we would have been ready to ship.

The full map at the end of the day on Sunday

The full map at the end of the day on Sunday

While we hadn’t got as far on Saturday as I would have liked, I felt that by the end of Sunday we were further along than I had expected. Luckily this gave us a whole day to iterate and tweak and make the game feel less like a tech demo.


On our last day we were starting to feel the crunch. When you’re counting down the hours you have to start prioritising and so we each started working against a to-do list. David spent a lot of time fleshing out the map and trying to make sure that there’s always something interesting on screen as well as paths to encourage the player to explore. I was working hard to make sure that we had everything in there that made it a polished game such as a HUD, help text, depth-of-field, sound effects and powerups.

Until this point we hadn’t created a full build so I spent an hour or so getting that working and testing it on David’s computer so that he could iterate on the artwork and have it appear directly in-game.

Almost final version of game about 16:00 on Monday

Almost final version of game about 16:00 on Monday

We still didn’t have voxel destruction in-game but soon after lunch David convinced me that I should see if it’s possible to get it to work easily. I’d been putting it off due to potential problems with collision and navigation mesh updates but I decided that to first order I would just do the voxel destruction under an explosion and make collision and navigation ignore it. In the end Cubiquity made this easy and very quickly we had the effect you see in the game. I’m glad David encouraged me to try to get this working as I think it makes a big difference to the feel of the game.

With about an hour to go I realised that while we were recording the player’s score to the screen during the game it was hard to pay attention to it while playing so often you didn’t know what highscore you’d achieved. With less than an hour to go until we would stop development I threw together a highscore system which ended up working very well.

David spent the last hour or two doing things like writing a readme, looking into the submission process, setting up hosting for the game download and making some artwork. In the end we submitted at about 19:00 on Monday.

Final thoughts


Since I was alone doing the programming there was a lot of pressure to get something working at the beginning. However as soon as we were underway I got into the flow of it and really enjoyed it. I think we were realistic with our scheduling over the weekend with

  • Day 1: Prototype of game
  • Day 2: Make it into a real game that is theoretically submittable
  • Day 3: Polish

Unreal Engine really did make things very easy and it’s great to still be using the engine which I first played with 17 years ago. Making real use of Cubiquity with UE4 showed me the areas where I should focus next, particularly the packaging pipeline and asset management.

The things I’m most proud of are the voxel destruction and the highscore system. They were both very late additions but they’re the main things that have been mentioned on the Ludum Dare review page. They both could have easily been left out but the game would have definitely been worse off without them. This really demonstrates to me the importance of polish in a game and helps justify that final ‘10%’.


This Ludum Dare was a really interesting experience for me. Despite being a programmer, I was keen to try my hand at doing art because being a Jack-of-all-trades is very valuable in indie game development. I’ve also been really impressed by some of the things I’ve seen made with MagicaVoxel, so was curious how well I could do, and I’m pretty happy with the result considering my previous voxel art experience was limited to making the enemies in Voxeliens (about 50 voxels each!).

One quadrant of the map loaded in  MagicaVoxel

One quadrant of the map loaded in MagicaVoxel

MagicaVoxel is a very cool program and I’d definitely recommend budding voxel artists play around with it for a few hours. There isn’t a lot of documentation though, and most things had to be discovered by trial and error. There are alternatives such as VoxelShop and Qubicle Constructor so I hope to play with those in the future to see how they compare (the main reason for using MagicaVoxel was that we already had a rudimentary importer for it).

Overall I really enjoyed doing voxel art and hope to do more in the future. In the past I have purchased small pieces of voxel art but I don’t think I’ll be doing that again when I can make it myself! This should open up many more options for making future demos in Cubiquity.


Development preview of Cubiquity for UE4

Just a quick notice for those who have been waiting on news of the Unreal Engine 4 integration of Cubiquity. Today I have released a pre-alpha development preview of the plugin.

Development is happening on GitHub under our new GitHub organisation. If you want to keep up-to-date with the latest developments, that’s the place to be. For information about how to test out the plugin, see the post on the Unreal Engine forums.

Do note that this is still a very early release which while functional is quite rough around the edges. Expect bugs and missing features but do let me know on the Unreal Engine forum post if you give it a try or of there are features want.


Cubiquity for Unity3D is now free!

Well we’ve got some exciting news today – we’re pleased to announce that Cubiquity for Unity3D is now available for free! It has always been free for non-commercial and evaluation use, but we are removing this restriction so that you can use the system for commercial purposes too. This is effective immediately, and you can download Cubiquity for Unity3D via the asset store or from BitBucket.

Cubiquity let's you create natural voxel terrains and edit them in real time, or build your worlds from millions of tiny colored cubes.

Cubiquity let’s you create natural voxel terrains and edit them in real time, or build your worlds from millions of tiny colored cubes.

So what has led to this decision? Well, there are a number of factors at play here:

Time restrictions: Over the last year we have spent a lot of time developing Cubiquity for Unity, but I anticipate time being less plentiful in the future. I’ve just accepted a new job as a senior software engineer, expect to be moving house in the coming year, and we have also had Voxeliens be accepted onto Steam. With less time available for development and support I don’t feel comfortable charging money for the system.

Research aims: There is a huge difference between a research-oriented project and a commercial one. Selling Cubiquity for Unity3D means a lot of work has to go into the workflow, documentation, support, and other tasks which are frankly not much fun. I’d rather shift the focus and spend more time developing cool features and demos, or doing more general voxel research.

Increase number of users: Getting paid for developing Cubiquity for Unity3D definitely has it advantages, but I can honestly say that the satisfaction of seeing someone else use your system is far more rewarding. We really hope that going free can further increase adoption and that we’ll see more games building on Cubiquity.

So what’s the catch?

There isn’t really a catch, but users should be aware that the core Cubiquity library remains closed source. A precompiled version of this Cubiquity library is shipped with Cubiquity for Unity3D and you can use this mostly as you please (see asset store terms and conditions) but you don’t have the source code to build it yourself. You do however have the C# scripts and shader code which integrate this library with Unity.

We do still have further opportunities to generate revenue from Cubiquity by charging for source code licenses, charging for additional platforms (e.g. mobile), or offering contract services. I don’t yet know if we’ll pursue any of these but there are no short-term plans to do so.

What about Unreal Engine 4 (UE4)?

In principle none of the above should affect Cubiquity for UE4. Matt is still working on this though again he is limited to his spare time. The pricing and distribution model for Cubiquity for UE4 may or may not match the Unity version – we simply haven’t decided this yet.


All support for Cubiquity for Unity3D will be handled through our existing thread on the Unity forums. There is also a board on our own Volumes of Fun forum, but we encourage users to use the Unity thread where possible as it boosts the visibility of the system and shows an active community. Please avoid sending email or private messages unless the content really needs to be private, as we try to keep communication open where possible.

Anyway, we hope you enjoy playing with Cubiquity for Unity3D and look forward to seeing what you create!


Implementing Morton ordering for chunked voxel data

We’ve recently been doing some work in PolyVox to switch the ordering of voxel data from linear order to Morton order. This work is now complete, and in this relatively technical post I’m going to highlight a couple of the interesting tricks which we came across while doing it. Hopefully these will be beneficial to other people working on the low-level details of voxel engines.

Like many voxel engines, PolyVox allows volume data to be broken down into a number of ‘chunks’. The primary advantage of this approach is that not all the data has to be loaded into memory at the same time, and we can instead load and unload chunks on demand. Note that this is an implementation detail of the our ‘PagedVolume’ class, and algorithms which operate on the data (mesh extractors, raycasting, etc) are not aware that the data is stored in this way.

The size of each chunk can be specified by the user (with the ideal size depending on a number of factors) but typically contain 32³, 64³, or 128³ voxels. The ‘ordering’ of these voxels refers to the way they are laid out in memory, and two possibilities are shown below for the 2D case. The linear ordering is the easiest to understand and can be traversed with a simple nested for loop, but the Morton ordering brings numerous benefits in terms of locality of reference, ease of downsampling, and increased compressibility.

Linear ordering (left) vs. Morton ordering (right)

Linear ordering (left) vs. Morton ordering (right)

However, the purpose of this blog post is not to explain the benefits of Morton ordering, nor to describe how (x,y,z) positions are mapped to locations on the Morton curve. For this we refer you to the Wikipedia article and the excellent blog posts by Jeroen Baert and Fabian Giesen. Instead, we wish to highlight a couple of optimizations which were useful in our implementation.

Continue reading


Update on Cubiquity for Unreal Engine 4

It’s been a little while since my last update on the progress of integrating Cubiquity with Unreal Engine 4 but plenty has been going on behind the scenes. Since the last video I’ve improved performance, added support for Coloured Cubes terrain, added LOD support, tested large map support and made sure that all of the functionality of Cubiquity is being exposed. A lot of time has just gone into making the code-base more future proof and reducing duplication between the different terrain modes.

Check out the video below to see the new features in motion as well as me just blowing stuff up at the 9:42 mark.

This more or less marks the features I wanted present for the first pre-release, so between now and then I will mostly be working on tidying things up and hopefully adding some initial documentation. I don’t have any ETA on the first release since this is fitting around my full-time job but any information will be posted here and on twitter.

The best place to follow development is the WIP thread on the Unreal Engine Forums.


A new version of Cubiquity for Unity3D is now available

Today we are pleased to announce that a new version of Cubiquity for Unity3D has been released on the asset store. Version 1.2 brings performance and memory gains, adds support for 64-bit architectures, includes faster transfer of mesh data from the native library, and provides experimental heightmap import.

A new example map is included (imported from here).

Our new example map shows a city modeled at a resolution of 512x512x64 voxels which can be destroyed in real-time (complete with physics). Data courtesy of William Rigby and the game ‘Build&Shoot’).

We have improved both performance and memory usage by introducing an octree to reduce the number of mesh chunks which are active at an given time. We’ve combined this with a sophisticated time-stamping system, which allows us to minimize the amount of work required to synchronize our internal representation with Unity’s scene hierarchy. The city map shown above loads in just a few seconds and runs smoothly with destruction and physics enabled.

We have also replaced our ‘ConvertToVDB’ and ‘ConvertToImages’ tools with a single general purpose tool called ‘ProcessVDB’. This provides experimental support for importing heightmaps as terrain volumes – experimental in the sense that it seems to work well but needs some refinements to the workflow.

This map was created using the new (experimental) functionality to import from a heightmap.  It can then be edited as usual to create caves and overhangs.

This map was created using the new functionality to import from a heightmap. Once in the editor the usual sculpting tools can be applied to create caves and overhangs, or to apply materials and textures.

The licensing model hasn’t changed – you can use the system free for non-commercial and evaluation use, or for $200 (per-seat) you can buy a commercial license through the Unity asset store:

For those of you who are waiting on the integration with Unreal Engine 4, I spent some time with Matt over Christmas and saw that the system is indeed progressing nicely. Both the smooth terrain and ‘colored cubes’ volumes are largely working though integrating with the editor and blueprint system is a lot of work. We both have only limited time so there’s not currently a set schedule for the initial release, but keep an eye on the forum thread for the latest updates.


First look at Cubiquity for Unreal Engine 4

As you might have seen if you’re following us on Twitter, I’ve been working hard recently to get Cubiquity working with Unreal Engine 4. Both David and I have long been fans of the Unreal games and the engine and so I’m having great fun diving into the code. I haven’t spend a lot of time on it yet but earlier this week I had the time to push the integration to a point where I can start showing off some features. Take a look at the video below for an overview of the current state.

The aim is to have at least feature equivalence between the UE4 version and the Unity3D version. So far I have only the smooth voxel terrain working and haven’t started on the coloured cubes version yet. There is live editing in the editor preview mode but not yet integrated as an editor tool such as users might be used to after working with UE4’s heightmap terrain features but this is something I will try to get in before the first official release. For the first beta release I want to spend some time neatening up the interface to the engine to make what’s currently available as usable as possible.

I’ll be posting an update here on the blog when there’s code out for people to test but in the meantime follow us on Twitter @VolumesOfFun (or me personally @milliams) or track our updates on the Unreal Engine Forums.


A new version of Cubiquity for Unity3D has been released

It’s been a quiet few months, but we’re happy to say that a new version of Cubiquity has just landed on the asset store. Version 1.1.3 is primarily a bug-fix release but also adds a few new features such as normal mapping of the colored cubes volumes and an example showing how to build and save voxel databases from Unity scripts.

Colored cubes can now have custom diffuse and normal maps applied. Shiny!

We’ve also tidied up a lot of stuff internally, for example all of our PolyVox enhancements have been merged back into the main develop branch and we have overhauled the Cubiquity build system. Perhaps not so exciting for end users but still an important step as development can move a bit more smoothly from here on.

Licensing is the same deal as before – you can use the system free for non-commercial and evaluation use, or for $200 you can buy a commercial license through the Unity asset store:

Looking forwards, the main request has been for larger volume support and better performance with less memory. In other words, we’re going to put some work into optimization and possibly providing some tools (importers, etc.) to help create the larger environments.

We’ll try not to go another three months without posting, and I think the upcoming changes should give us plenty to show off!

Update 3rd Sept 2014: Version 1.1.3 is now out with collision and physics fixes for smooth terrain. The links above have been updated.


Cubiquity for Unity3D is now on the Asset Store!

Hi all, I’m pleased to announce that we’ve just made the first official release of Cubiquity for Unity3D, and that it’s now available to purchase from the asset store. This is a huge milestone for us and comes just over a year after we first showed our work on Unity3D integration.

The asset has been released at the $200 price point which we’ve been throwing around for a while now, and it remains free for non-commercial and evaluation use. Anyone who has been following our regular snapshots will already have a good idea what the system does, but the uninitiated can get the latest free version below:

It’s also worth mentioning that we’ve updated the documentation and placed it online. You can read it here:

And as mentioned previously, if you like the system you can now buy the commercial version at the asset store:

This is really just the start of the journey for Cubiquity and we have plenty of ideas for how we want to further develop the system over the coming months. But that can wait for a future post – for now we’d just like to thank everyone who has spent time testing our system, giving feedback, and providing encouragement. You’ve helped get Cubiquity for Unity3D to where it is today!


New Cubiquity for Unity snapshot with OS X and Linux support

I’m pleased to announce that today we’re releasing a new snapshot of Cubiquity for Unity. This version finally adds support for both OS X and Linux, and also includes a number of smaller improvements regarding stability, user interface and documentation.

Cubiquity for Unity running on OSX

You can download this latest snapshot using the links below (remember to check our YouTube channel for examples of what Cubiquity for Unity can do):

One of the main appeals of Unity is the ability to target multiple platforms from a single code base, and so we’ve always been keen to bring this functionality to Cubiquity as well. The process is more complex than for other Unity assets because Cubiquity is a native code library written in C++, and so it needs to be compiled (by us) for each platform which we want users to be able to target.

Matt kicked off the work a few weeks ago by compiling Cubiquity for Linux. This involved writing some CMake scripts, testing the process of loading dynamic libraries on Linux, and fixing some OpenGL issues. All of this helped lay the foundations for the OS X version, which then required extra tweaks to the the build process and handling of log files. But eventually it came together :-)

We haven’t added any significant new features beyond the improved platform support, but there has been more work on polishing the API and particularly on documenting it. The final release will naturally include API docs and a user manual to get you up to speed quickly, but we’re also hoping the API will be simple enough to be intuitive.

We currently expect that this is that last snapshot which we release before we put Cubiquity on the Asset Store! The end is now really in sight and we hope to be live by the end of this month.