Welcome back to another edition of Voxatron's development diary. The game is available in alpha form (with access to all future updates) here. There's also an updated development plan if you'd like a broad feature-centric summary, and a FAQ.

Recently Voxatron has been going through a kind of annealing process; many sub-projects jostling for position as it becomes clearer how they interact with each other. I've collected a large wishlist of engine features and gameplay ideas, and now the goal is to gradually boil the whole thing down into something that is technically possible and creatively in self-agreement. The temperature is getting a bit cooler now, and it's clearer what form features will take and which ones will get squeezed out.

So, here's a run-down of some of those sub-projects in roughly the order that they'll show up in future updates..



0.2.1 & Twisty Castle

This one is already done, if you missed it! The changes in 0.2.1 were designed to provide everything needed to make a basic exploratory adventure level. Some of the new features (collect-once items, use-once doors, checkpoints) are stop-gap solutions until nearer the end of the engine's development cycle ( v0.4 ).

v0.3: Zoot

You might recall the sci-fi level that Anthony was working on in the last diary entry . This level turned out to be too ambitious in terms of working with unfinished engine features: persistent inventory items, scripting and custom monster design and sounds. So instead we decided to shelve it for now and go for a simpler short-term demo adventure. This way I don't need to rush temporary code in to get things working, and Anthony doesn't need mock-up parts of the level by making cardboard cutouts and manipulating them in a doll-like fashion.

Zoot is a map-based adventure with around 10 locations that you don't need to complete in order. It includes the first custom object (animations), along with new physics and a water base type.

Custom Objects

In v0.2., there is only one type of definable object: the humble prop. Props are burnt into the map when they are activated but are otherwise static and not very interesting. The 5 new types of customisable objects I've made for 0.3. updates are:

ANIMATION: floating multi-frame props that don't interact with the world

PICKUP: trinkets with definable scores and messages

DOOR: define open, close animations and collision size

MONSTER: define some stock behaviours with parameters

PLAYER: replaces the _char hack, and allows variable sized players

These objects share much of the same groundwork, so although I'll release them in separate updates, each one won't be so far apart. It's just a hop skip and a jump from collectable turnips to magnificent creatures!

Physics

It's now possible for objects to push and sit on each other, and for the player to pick up objects and throw them around. To test this, I added good old fashioned crates to improve Voxatron's OMM Crate Rating.

The existing monsters will remain roughly as they were, but it's now possible for tinymon to run around on your head, and will allow riding moving monsters/objects (good for moving platforms etc)

Resource Tree

easy to organise rooms into groups (e.g. a folder called "Forest", which contains "Castle").

share branches of the tree on the bbs, rather than VOBs

objects are indexed by a global_id, so possible to re-order, delete and move objects around the resource tree

the tree can be used to store whole level files near the root (and so allow multiple open files)

animations can be embedded inside objects and used to elegantly represent events (e.g. a door opening)

use it to store other types of resources later on (music, sounds)

can alias branches of the tree to external files for very large projects with shared components (e.g. my v1.0 world!)

One requirement of customisable objects is the ability to edit multiple frames per object. In order to do this, I've created a unified resource tree. Instead of having the current set of 6 'banks', with each voxmap having a set of frames, objects are instead store in one big tree of any depth. The whole thing is like a kind of file system; banks become folders and objects are the files. This will still take a bit of work as it requires a nicer interface for browsing, but there are many advantages:

Water

Water is something I needed for the v1.0 world anyway, but after Anthony animated some great water using the new animation tools, I couldn't resist bumping the water base type forward so that I could make it more interactive. The above image is a scene from Zoot with hand-animated water crashing up against the rocks. With a base water type, you'll be able to float objects on top of it (or in the case of hostile rough water, bob around for a moment before dramatically disappearing below the surface).

There are two possible schemes for water: a 2d heightfield, where water covers the whole level and can only exist at one layer (see lava) -- or generalized water that can exist at multiple levels (and in separate pools). The second type is much more difficult, and I'm still exploring possible approaches with varying degrees of success:

Numerically unstable water

Monster Editor

This comes under custom objects, but I know it's one of the more anticipated features, so I should give you a bit more detail about what the first version is looking like.

0.3 monsters won't have scripting (see below), so instead I've opted for a template system for doing basic monsters. This is probably a better approach in terms of usability, as you can get quite far without needing to learn the intricacies of scripting. Instead of typing in a bunch of text describing a basic monster's behaviour, you can do it by filling out a form (and drawing some frames of animation).

Each monster has a set of behaviours with parameters that can be adjusted with several sliders and checkboxes. For example, you might want to turn on jumping and then specify how frequently / high the monster jumps, and if it jumps out of the way of bullets, or at the player if they are close-by. In the current design, I've also allowed for some shooting attacks (although, this will become more flexible with scripting). You'll be able to draw the bullet animation, specify how many bullets and what kind of bullet formation each attack has, and the behaviour of the bullets (e.g. no gravity, seeking).

Voxel types

: Some special voxels are already usable in 0.2.1, but need better tools for managing them (negative voxels that subtract sections from the world, indestructible voxels). Other types I've tried that look promising and will probably appear soon are deadly voxels (invisible voxels that hurt you e.g. to put on the tips of spikes) and crumbly voxels (cave in easily when shot or pushed)

Cellular automata: Voxels that have per-frame behaviours based on the state of their neighbours, for example sand that naturally settles into a cone-shaped heap. This was fun to try out, but ultimately not very useful for designing levels and slowed the engine down too much. It has been useful for providing insights into how to general water however (which I might write about later if it works out).

Scripting / Events

In the last diary entry, I mentioned an event system that I thought would be a powerful addition to scripting that I could add in 0.3. This turned out to be a mirage. As I added more functionality to the design to justify its existence, I found it converging on being a full text editor-driven scripting system. e.g. if you have a list of event conditions and actions, and you can shuffle them around and change chains of binary operators between them, it really starts to look like a text editor. It's better just to make a text editor!

Instead, I'll keep events as a minimal interface-level feature in such a way that it can optionally be mixed with scripting. This will also make it a more flexible replacement for the triggering system. This might not make much sense yet, but here's a simple example:

Say you want to open a door when the player collects an apple.

In the v0.2 scheme, you'd group the door and the apple, and then set the door to TRIGGER_PICKUP

With the new scheme, you can add an event to apple (PICKUP), and an action (ACTIVATE DOOR (and pick out the door)).

You can specify multiple events per object, so there is no limitation caused by only being able to add each object to a single group.

When mixed with scripting, the action can be replaced with a short script (that you type into a box) that can do more precise things if needed. For example, only open the door if all of the apples in the same group have been collected, or flip the state of the door (if it's already open, it will close and vice versa).

I've settled on Lua for scripting. It's a relatively easy language to learn, and a popular choice for other games. It also meets Voxatron's technical requirements -- tiny embedding, fast, can run without floating point math, and interacts nicely with C.

LEX500

LEX500 Palette Test

This project isn't part of Voxatron per se, but is something I've wanted to do for a long time and has suddenly become extremely relevant.

LEX500 (working title) is a little program for making low-res 2d games (160x120, 16 colour). It has a built-in sprite, map and sound editor, and allows the user to write games in Lua (surprise). The programs can be shared on this BBS, along with replays and new levels.

The great thing about LEX500 is that it can be built almost entirely out of components from Voxatron. I haven't done much work with scripting for games, so it's a great chance to prototype ideas that will eventually become part of Voxatron, and hopefully avoid some bad design decisions.

Some other advantages of making LEX500: 1. It will be a nice way to introduce players to scripting in LUA 2. It will attract more coders/designers and retro game affectionados that might become part of the Voxatron community and 3. It will be extremely fun to see what kind of programs people come up with!

I'll get into this after the 0.3 series of updates are finished.

World Persistence

I did a bit more work on world persistence (e.g. shoot some dirt and it's still gone when you come back to that room or load your saved game). Keeping the state of rooms stored in memory is very tied up with custom objects and scripting, so it will probably become available in 0.4.

Persistence also requires quite fancy loading/saving, and complex backwardly compatible save files is not something I want to rush into early (bug-prone and heartbreaking to lose save game data).

The saving scheme is quite cute, I think. Every time you leave a room, the state of the room is appended to the current save game file. So it's very fast to save, but you end up with one long save game file that takes a bit longer to load (around a second for a long game). A nice by-product of this is you end up with an entire recording of the game and could conceivably rewind to any previous time (including moments mid-room if key-press sequences are also stored). I'm not sure how useful this will be but I think it's a nice possibility to have.

Future Game Mode

Voxatron was originally supposed to be only a Robotron homage using my voxel renderer (hence the name) because I thought my plans for a map editor & grand adventure would take too long. After quickly prototyping the arcade version (which is still basically the same as the current arcade mode), I encountered so much passionate interest in the game that I decided to go ahead with the adventure part anyway. Because the time it takes to make would pass anyway.

If you have a look at the updated development plan, you can see the project has roughly 4 parts that correspond with game modes:

0.1->0.4: Adventure Demos (+ engine & tools to support them)

0.5: Arcade Mode

0.6: Battle Mode (local multiplayer)

1.0: Adventure

I'm not doing much work on 0.5->1.0 at the moment, but I keep coming back to the designs so that I know the engine will support what I need, and to keep the original vision of the game alive.

The current design for the 0.5 arcade mode is a wave-based thing (like Robotron and many shooters), but with procedurally generated waves. I've been experimenting with how to make this interesting and fair: the sequence of monster entry and terrain changes might be easier or harder on any given play-through, but the challenge is to identify that you've been dealt a good hand and have the composure to capitalize on it.

Many of these high-scoring opportunities comr about from combinations of temporary powerups, bonus multipliers and side-arm characters. If you have a side-arm bunnoid (robotic rabbit) and it seems to be working effectively with a triple shot modifier, you might be tempted in the midst of a thick wave to go for a duplicate and bonus multiplier combination lying in close proximity. I want these moments of brash glory-seeking, for the death of your vital bunnoid to feel truely tragic, and the out-gunned vain attempt at redemption equally sweet.

0.6 I haven't looked at much yet. But it will be a varied player vs. player arena thing driven by an assortment of weapons, pickups and objectives. Because 0.6 will come out after scripting, it will also be possible to design your own PvP games that might not even resemble Voxatron. Tennis, anyone?

1.0 comes with the main Adventure mode. Lately I've been working on new music for this, which I think is a great way to design and remember the feeling of pivotal scenes and locations in the game. The story follows 3 main characters: a girl, a robot (the robot) and a fox. Each character represents different styles of play (adventure, arcade, rpg/rogue-like), and so the music has roughly divided itself into 3 groups: incidental thematic music (like Jasper's Journeys, or the original Prince of Persia), thumping action music (a continuation of the style used in Voxatron trailers / arena rooms), and meandering background music that adapts to circumstance (for the fox's dungeon spelunking).

Synthesizer

Voxatron's music and sound is generated on start-up with a little modular synth . I updated it for 0.2.1 to get some more sounds out of it: for the hellephant boss's trumpet and more instruments for the music.

At some stage it will be necessary to allow the player to design their own sounds to go with custom monsters and objects (and music!). I made a visual interface for this, but it's still way too cryptic for the average user. Later I'll add some sfxr-style 'wizards' for generating common groups of sounds easily from templates: thuds, grunts, pickups & explosions etc.



Synth definition for the large explosion sound

Bit-7 Physics (Failed Experiment)

The voxels in Voxatron are represented as 8-bit values, meaning there are 256 possible colours for each voxel. So far I only use around 64 of them and want to keep the palette quite small. So I always knew there would be a spare bit (bit-7) available should I need it for something.

I learnt, once again, that just because something is possible it doesn't mean you should do it! In this case, the possible thing was voxel-perfect physics and collisions. i.e. instead of defining a size for each object in the world, the engine just looks at what the object is made of and calculates the weight and collisions based on that.

This is where bit-7 came in. I tried adding a 'ghost' layer to the world that disappears at the end of each frame. Every object draws themselves into the ghost layer every frame, and that information is then used to calculate (down to the voxel) when monsters crash into each other, walls, land on each other, etc. This way collision code only needs to read one source of information -- the world map -- rather than consider the world and objects separately.

I won't go into detail here why this didn't work out. But briefly:

Slow: even just clearing the 7th bit of the 256x256x48 map at the end of each frame is pretty expensive (the world state is updated at 120fps)

Ambiguous: when there are overlapping monsters, it's difficult to determine if they're colliding with their own voxels or each other, and when to allow collision exceptions that allow objects to untangle from each other.

Bad feel: even when it functions "correctly", it just doesn't feel good. Even though it might seem like a beautiful unified system from a programmer's point of view, in practise it's more comfortable for a player to abstract objects as some simpler geometric shape. This is especially true when you introduce animation and turning -- if a walking animation puts voxels inside a wall, or prevents movement that the player would have otherwise expected, the results are counter-intuitive. Basically it requires the player to keep track of too much information.

[As a side note -- this is similar to the reason I don't like gangly characters in 2d platform/action games. It's difficult to ascertain quickly what the state of the world is. I like beany characters like mario, meat boy and the worms in liero.]

Too much work for the designer: even though this scheme requires the designer to define a size for each object, they still need to define which frame should be considered the active physical mask of an object for any given point in time. Sometimes this shouldn't be the one being displayed, or should be the combination of several frames (e.g. body + feet)

So I went back to bounding boxes, and everything was swell. Bounding boxes aren't such a bad thing visually in Voxatron because many characters and objects look best blocky anyway.

Flash version

I made a flash version of the Voxatron engine using Adobe's experimental Alchemy compiler. I signed up to try out the beta of their commercial version which may generate faster code, but for now it seems to be reasonably playable. In the future this will be useful for sharing or previewing levels & replays, and maybe demos to attract more players.

Try it here

Shadow volume rendering

This will probably come out closer to 1.0 too, but I did some more experiments with varied lighting. One significant breakthrough I made was finding a nice way to generate 3d shadow volumes quickly, rather than 2d shadow maps. This will allow for effects like light emitted from a lantern that the player is carrying (well.. actually that's all I wanted it for). I'm storing the shadow state in Bit-7 (that I mentioned earlier -- it WAS useful!) and sampling that to get the soft shadows. This is great for cache performance, as organizing data to be efficiently accessible for a game like Voxatron is very important

Optimisation

Because of making the flash version (and renderer changes), I was prompted to do a bit more optimisation. Running the game and software renderer in a virtual machine is kind of a crazy thing that I never imagined would be possible, but it does require everything to be humming along efficiently. Testing under flash was a good way to expose inefficiencies in the gameplay logic that earlier profiling didn't pick up, and I was able to more than double the average performance. If you play a long arcade mode game and then PLAYBACK->SKIP PLAYBACK at the end you can see the result of this: the entire game is re-simulated in a few seconds. This might prove to be useful when randomly seeking playbacks, or journaled level files that include player input.

Network

The last major feature that I'm still not sure about, but am dearly holding onto, is online multiplayer. The current speed of the gameplay logic is a good sign in this department. There is probably too much going on in Voxatron to send data describing the whole world state, so there needs to be a fair amount of independent simulation going on. I tested a promising model with this in mind: by keeping two copies of the world state in memory:

state_1: the state of the world at the time when all players keypresses are known

state_2: the current local state of the world

.. so that only player keypress data needs to be sent across the network (along with initial world state and error-correcting patches). Each frame, the world is re-simulated from state_1 using incomplete player key data (complete for the local player) to produce state_2, which is what is displayed. A cut-down version of the gameplay logic can be used for this, which ignores things like bits of dirt flying around.

So network play is looking good so far, but I'm yet to see how it does under typical network conditions and with scripting. Eventually Voxatron will become a general game-maker like program, so it would be wonderful to be able to make networkable multi-player games without even caring how the networking is happening.

Volumetric Display

This blurry image is Voxatron running in glorious full resolution monochrome on a real-life, Help-me-Obi-Wan-Kanobi, volumetric display. More on this soon!

Pico Pico Cafe

Lexaloffle Games is now also Pico Pico Cafe, which means "Pixelated" or "low-fi" in Japanese. The idea behind Pico is to provide a public space people (including me) can go to work on creative things, to test out games on unsuspecting visitors, and drink coffee. Hopefully someday it will also be home to a volumetric cabinet of Voxatron, so that anyone can drop by and try out their levels in 3d. If you're visiting Tokyo or nearby, please do come by and say hi (or better yet, bring a laptop or notepad and make some stuff).

Next Up

Next up is 0.3 with Zoot and support for animations & water. It should be out in 2-3 weeks if all goes well, so please check back here or sign up to the newsletter to be notified when it's available.