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

Friday

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

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 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.

Sunday

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 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

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.

Monday

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

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

Matt

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%’.

David

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

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.

The post Our first game jam: Ludum Dare 33 appeared first on Volumes Of Fun.

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.

The post Development preview of Cubiquity for UE4 appeared first on Volumes Of Fun.

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.

The post Update on Cubiquity for Unreal Engine 4 appeared first on Volumes Of Fun.

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.

The post First look at Cubiquity for Unreal Engine 4 appeared first on Volumes Of Fun.

Well it’s taken me a few weeks of on and off work but I’ve got Cubiquity working on Linux as a Unity3D add-on. You can try it right now from the Git repository and as long as everything works correctly, it will be available in the next official release.

Cubiquity for Unity3D running on Linux

Porting

There are two essential parts to Cubiquity: the core Cubiquity code where all the magic happens and a thin wrapper providing a C interface to allow easy interaction with Unity’s C♯ code. Cubiquity builds heavily upon PolyVox which has been working on Linux for years now so at least we had a good base to work from. Like PolyVox, Cubiquity is written in C++ which makes it easily portable meaning I had to only make a few trivial changes to the code to get it to build. After a few tweaks to the CMake files, we had a libCubiquityC.so file built and ready.

In order to ease installation and avoid library mismatches, we decided that statically linking all that we could was the best option. Luckily, Cubiquity has few 3rd-party dependencies — in fact it only depends on the C++ standard library and two small Boost libraries. Boost was only being used to fill in features which are now part of C++11 and so by increasing our compiler requirement we could remove the Boost usage entirely. Once here it was simple enough to statically link in libstdc++ and avoid and difficult dynamic library requirements.

For testing purposes, David sent me a simple Unity application which had been exported for Linux and used Cubiquity to create a simple terrain. The idea was that I should be able to place the libCubiquityC.so alongside the executable and the Mono runtime would find the library and load the appropriate stuff from inside it. With a bit of tweaking of the C♯ loading script and recompiling the library as 32-bit (because the Unity app I was using was 32-bit) I was able to run the Unity application and have it render a terrain.

As you can see in that last link, the terrain was not rendering properly and so David set to work getting the shaders working correctly and fighting with some tricky Unity bugs and now it all seems to be working well.

What’s next

Getting Cubiquity working on Linux, as well as being an end in itself, is a useful step towards getting it running on OS X. We are compiling it with both GCC and Clang (which is the OS X compiler) to make sure the code stays portable. In the medium-term we’re working towards being able to easily build the library for all our supported platforms from one place and so I’ve been investigating cross-compiling from Linux to both Windows and OS X. I will give a more detailed description of what I’m doing in a future post but we do already have DLLs and DYLIBs building and they are undergoing testing at the moment. Once we’re confident in the Linux build, we will work on testing out OS X support.

The post Cubiquity now works on Linux appeared first on Volumes Of Fun.

As part of the next release of PolyVox, we’re going to have the first Python bindings available and supported as well as preliminary support for C♯ bindings. This will allow easy integration of voxels into the technologies you’re already using.

History

For a long time now (at least 4 years) we’ve had some form of Python bindings available for PolyVox, created via the SWIG tool. If you were paying attention in those days, you would have seen that the bindings were often broken or even disabled from building completely. This was largely due to the fact that PolyVox was a fast-developing piece of software without a stable API. We didn’t want to slow down the development of new features by having the impedance of also having to update the bindings.

However, since we starting making proper numbered releases (beginning with 0.2.0 last year) the API has settled down and we’re making promises about how much (or little) it will change. This makes it a much more suitable target for building bindings to other languages.

Current status of Python bindings

My main target for the next release of PolyVox (0.3 when it’s out) has been improving and polishing the bindings for Python. In addition to the Python bindings, I have also enabled the building of C♯ bindings for those who would like to try those out too. The Python bindings are better supported however (we have nightly tests run on them, documentation and a demonstration example) and are less liable to change.

If you’re interested in taking a look, then I’ve uploaded a first draft of a section documenting the Python bindings which introduces the bindings and goes through a short code example. That short example is expanded as a full example in the usual example location, PythonExample.py, which renders a blocky sphere to the screen using Python, PyOpenGL and PyGame without a single line of C++ needing to be written.

A voxel sphere rendered though PyOpenGL

For example, creating a volume is as simple as

import PolyVoxCore as pv

r = pv.Region(pv.Vector3Dint32_t(0,0,0), pv.Vector3Dint32_t(63,63,63))
vol = pv.SimpleVolumeuint8(r)

You can set the value of any voxel with a single call like:

vol.setVoxelAt(x, y, z, 10)

and you can extract a polygon mesh to be passed to your 3D engine of choice with

mesh = pv.SurfaceMeshPositionMaterialNormal()
extractor = pv.CubicSurfaceExtractorWithNormalsSimpleVolumeuint8(vol, r, mesh)
extractor.execute()

The unusually long names for the classes is an artefact of SWIG being able to represent all the varieties of C++ template instances. You’ll also notice that the API is not very Pythonic at present. I’m trying to get all the functionality working before adding another layer of Pythonicness.

All of the above is already in the develop branch of Git already so feel free to try it out. If you have any question please do ask in the comments below or in the forums.

In a future post I’ll detail some of the technical challenges I’ve faced to get all of PolyVox’s functionality working in both Python and C♯ via SWIG.

The post Python bindings for PolyVox preview appeared first on Volumes Of Fun.

This release includes the following bug fixes:

• A compilation error on VS2008 (commit)
• One of the sampler peek functions would check in the wrong direction before moving (commit)
• SimpleVolume and LargeVolume had a problem with negative positions (commit, commit)
• The LowPassFilter test was using the wrong kernel size (commit)

Apart from those bug fixes there are no new features and so should be completely safe to upgrade to.

You can get the details for downloading the source from the PolyVox download page or download directly from these links:

• polyvox-0.2.1.zip
• polyvox-0.2.1.tar.gz

If you’re following us on Git, the 0.2.1 is now what is represented on the master branch.

The post PolyVox 0.2.1 released appeared first on Volumes Of Fun.

BitBucket offered everything we needed and since we were already using it for its unlimited private repos, it made sense to move PolyVox there too.

While we will be using the issue tracker to keep track of features and bugs, we will keep using the forum for most discussions. Feel free so submit any simple/small bugs to the tracker directly e.g. for compile errors etc.

To switch your local clone to follow the new repo on the command line just do the following:

# First check where you're currently pointing
$ git remote -v
origin  git://gitorious.org/polyvox/polyvox.git (fetch)

# Change the 'origin' remote's URL
$ git remote set-url origin https://bitbucket.org/volumesoffun/polyvox.git

# Now, it should look like
$ git remote -v
origin  https://bitbucket.org/volumesoffun/polyvox.git (fetch)

Otherwise, you can just use your GUI tool to change the repo URL to be https://bitbucket.org/volumesoffun/polyvox.git. You should now be able to carry on doing git pull as if nothing had changed.

The post New home for PolyVox git repo appeared first on Volumes Of Fun.

CMake Folders

The first thing we’ve done is to start using a nice little feature of CMake to make working in Visual Studio a little nicer. Before this change, the Solution Explorer looked like:

Obviously, this is a little hard to work with since all the tests, as well as internal targets like ZERO_CHECK and _PolyVoxCore are included in the list. What would be ideal is if it were possible to organise the targets into a hierarchy which matches how the code is logically organised. I found a blog post showing how CMake can do this. First of all, you must enable a global CMake property to turn on this feature.

set_property(GLOBAL PROPERTY USE_FOLDERS ON)

Then, for each CMake target, you mush set a property which defines the “folder” in which it will appear. For example, for the PolyVoxCore target, we add the following line to its CMakeLists.txt file:

set_property(TARGET PolyVoxCore PROPERTY FOLDER "library/PolyVoxCore")

Once these are added to all the targets you want to categorise, you will see something more like this in Visual Studio:

Which has put everything in a more logical place. This was added to Git a few weeks ago in this commit.

Git Branching Model

The second “feature” we’ve recently added is a new way of working with our Git repository. Up until now, we’ve simply done all work in the master branch (perhaps with the occasional local topic branch) and so it’s sometimes been the case that the version of the code in the Git repo hasn’t been in a compilable state. As we’re currently working towards making a proper release of PolyVox, we decided that we should be more structured with our usage.

I’d heard good things about Vincent Driessen’s “successful Git branching model” and after reading it through we decided that it would be a good model to follow. Even better, he provides a cross-platform set of Git extensions called git-flow which make the whole process painless.

As of today, we will be using the new branching model. The master branch will now only contain released versions of the code and if you want to get the latest development version, you’ll have to check out the develop branch. When browsing the web interface at Gitorious, you’ll see that you can switch between branches by clicking the name in the grey box at the top or in the right-hand panel when browsing the source tree.

When it comes to release time, it’s simply a few commands to merge the develop branch into the master branch and tag the commit.

What this means for users is that we’ll be making more regular, stable releases and the git repository will be in a much more stable state for you to use.

The post Some PolyVox Updates – Git and CMake appeared first on Volumes Of Fun.

We will be provided with a stand for people to come by and talk to us and play the game on the 11th and 12 of July. So if you’re going to be at the conference please come by and say hello – we’re a friendly bunch

Out of all the games that have been shortlisted, one will be selected as the overall Showcase Winner and one will be chosen as the People’s Choice via a ballot during the conference.

The Develop conference is one of the largest European game developer and publisher conferences and runs for three days from the 10th to the 12th of July. As well as providing talks and an expo floor for the professionals in the industry there is also a day and a half of talks aimed solely at the indie game developer community.

The post Voxeliens shortlisted for the Indie Dev Showcase appeared first on Volumes Of Fun.