This is the first post in an ongoing series detailing the development of Voxatron. I should probably do a separate entry bringing you all up to speed on the history of the project as it's already over a year into full-time development and the first prototypes were in 2004. But maybe more of you are interested at this point in what's happening with the planned updates. So I'll start with what I've been working on for the last couple of weeks.

Voxel Properties

The current version of Voxatron has just one type of voxel property: colour. Eventually it will be possible to give voxels or objects some other properties. Current candidates include: indestructible, super-crumbly, slippery, floating, bouncy, sticky, non-interactive, negaitve (subtracted from map) and hurts player. Although I'm yet to decide how to build these into the engine at a low level, they won't be too expensive cpu-wise and most of them are fun/useful for making levels so will make it into the final product in one form or another, even if they don't appear in the main game.

Another group of properties determine how voxels instead interact with each other. An example is sand, shown in the screen-shot above. This type of interaction is much more cpu-intensive as even if there's nothing else moving in the world, each grain of sand should fall down slopes until it reaches some kind of stable state. In the top left image you can see a test level with some sand in a wooden container. The top right and bottom left images show what happens after shooting some holes into the container with a blaster and waiting for the sand to pour out. The last frame shows the action after some sword slashes.

It's fun to play with, but unfortunately requires more cpu than I'd like. I'm wary of bogging the engine down with stuff that might prove mostly academic and not used much in practice. It's fun to play around with sand but it doesn't open up design possibilities the way a mean-and-lean scripting engine and monster/object designer will.

Another example of impractical but interesting properties are water that collects and pools nicely, or properties that allow mechanical circuitry to be implemented. Imagine building a some kind of intricate machine out of logic gates and wire, and then hacking away at it with a sword and watching the functionality degrade!

Monster System

This hasn't been a problem so far, but at this point I really needed something to build on. So instead of fixing these bugs, I skipped straight to rewriting monsters to be compatible with a monster designer and scripting, and let the bugs come out in the wash. The new system looks pretty much the same (I want to keep it backwards compatible with existing BBS levels) but is now much more modular and extendible. This will also be useful for the relatively simple task of adding a few new monsters in 0.2.0 (Doom barrels!)

Scripting

I'm leaning towards Lua at the moment. It's a fast, portable and flexible language, and supports fixed point number representation (Voxatron is all fixed point, and it helps being reliably deterministic across platforms to implement replays and possibly network play). The one thing that irks me is the 1-based array indexing, but it's hardly a deal breaker.

The plan is to allow people designing monsters and other objects to take control at different levels. At the top level, you can just pick pre-designed monsters as you do now. One level down, you can choose the properties of monsters and draw their frames of animation. This should be enough for a decent variety of monsters. At the lowest level you can override the standard behaviour of each monster property by replacing or extending it with your own piece of script.

Story

So, I've been chipping away at the story and possible gameplay scenarios a bit recently, and finally settled on what looks to be a likely format for v1.0. I don't want to give away much about the story or characters until v1.0, but here's a rough picture:

There are 3 characters that the player takes control of at different points of the game. Each one is used for different style of play and has a different inventory:

Arcade: Similar to the alpha demo 'adventure', mostly blasting monsters and action puzzles. These levels are score-based and replayable to get higher scores.

Adventure: This character can't shoot, and there's more emphasis on exploration and puzzle solving levels using items collected along the way.

Rogue-like: Later in the game, this character goes off on an expedition that includes item collection and procedurally generated sections of the world.

The story is nothing special -- it will be just a set of fairy-tale excuses for setting the theme and having an adventure. But a little deeper than rescuing a love interest from some bad guys.

Linux Installers

I also reduced the linux dependencies further by modifying the video code to make use of SDL's dynamic opengl loading feature. By default, Voxatron doesn't start up using opengl blitting (it's slower and with tearing, on my machine at least) so there's no need to require it for most users. This should alleviate some dependency confusion in the next update.

Account System

Default Tileset

Lastly, I'm adding a few new default models for the next version's editor to avoid getting too many similar-looking levels. Also it's a good chance to get rid of the horrible default tree which was supposed to be place-holder art. Here I'm trying out some Jasper trees.

If everything goes well, 0.1.7 should be out sometime this weekend. Check back to the blog for an update announcement, or the development status page if you'd like to see what's coming up later.

Great work so far and thanks for the update! Looking forward to the next release.

Are we able to use our old maps when you add new features on editor? I'm kind of scared about incompatibility.

Thanks for the update. I see that you think how to lay a solid foundation. I like to read about reasons you approve or reject features.

As for the scripting language, I don't have any real experience. I like Python, but it's not ideal as an embedded scripting language. It's better standalone. Many successful projects use Lua, its syntax looks deceptively similar to Python. And besides, I'm not afraid to learn another language.

Speaking of different characters, it would be nice if you could make it simple to switch characters within the same gametype. It should pay off once multiplayer is enabled. Minor specialization can be fun, players might need to use their specific abilities to succeed.

About monster/character editor: could you elaborate on hitboxes and "collision boxes" ? At the moment it seems that player character is always the same size except for appearance. How about calculating it automatically based on topmost/bottommost voxel ? It could be fun to create smaller or larger characters, powerups that change your size....
Will we be able to create monsters with holes in them ?

Are you open to releasing the source code of the game in several years, at the point you think you can no longer profit from selling Voxatron ?

About sand and water: it may be too expensive to be calculated in game, but how about level editor ? It would only need to be calculated once, then saved as static voxels.

Cool, excellent look into the development process, very much appreciated. It sounds like you're getting a lot done and planning a lot more, should be awesome. :)

Great stuff, I really like the direction Voxatron is heading in :D

I think the scripting engine will bring about some amazing things over time, looking forward to it's implementation. I have no idea how to do any scripting myself, but I'm sure we've got some awesome "scripters" chomping at the bit to see what they can do.

Thanks for the update. I know what a hassle updates like this can be when you just want to work on the game, but it's really great to hear what you have planned and where you want to go with it.

Personally, the rogue-like aspect alone sounds like enough for me to want to buy the game all over again. If you can randomly generate content, plus collectable items that slowly level your character up the further into the game you go, well, that's just about a dream come true.

Keep up the good work and I can't wait to get my hands on your next release. Thanks for the great game!

Sounds like you have really big plans for Voxatron. (to be expected of course) I'm looking forward to 0.1.7!

More story! voxel music man & bloody nose man have a lot of character, I think you could get some emotion into a storyline.

Can't imagine what vesrion 1.0 will look like ... it's just the alpha 0.1.6 and I'm playing this game more then COD !!

"I did a bit of work on user accounts, which will be used in 0.1.8. There will be an option under the player menu to log into your lexaloffle account, and Voxatron customers will automatically be identified as registered players. This will allow things like favourites and play-list syncing, as well as screening out pirates to reduce level/score spam and server load. Sorry, pirates."

What about people that bought the game through the humble bundle? Will we be blocked from playing, since our Lexaloffle accounts don't list us as owning the game?

Thanks for the update news. :)

@tom.K
Any future updates will be compatible with levels made with the editor going back to 0.1.3 (the first release). I can't guarantee the levels will be exactly the same because of subtle changes in the physics engine and monster behaviour. But they'll load and play roughly the same.

@b0rsuk
The 3 characters are different enough that the levels mostly need to be designed around each of their abilities. There will be a bit of cross-over though -- for example, when you've finished the game, you can go back and play the rogue-like section with the robot.

For sure -- it will be possible to change the size of custom characters. It's just something the current set-up doesn't support yet. I'll be able to make it more easily around the same time as custom monsters (the player will also be internally represented as a custom monster, kind of).

It probably won't be possible to create non-cubeoid monsters without breaking them into segments. I'm still entertaining the possibility of voxel-perfect collisions for monsters, but it looks to be more trouble than it's worth.

I haven't thought that far ahead in terms of open sourcing Voxatron, but it's definitely an option. I also have a mechanism in place to open source my projects in case I get hit by a big yellow bus.

@entrican
I'm hesitant to develop the story side of things too much because it puts a constraint on what the player can do. For example, if the monsters in the alpha demo world had any kind of back-story, there needs to be a clear motivation why you should run around slaughtering all of them indiscriminately. Instead, I think it's nice just to leave it unasked, and let the robot blast monsters, because they're monsters and that's how robots roll.

So that's what I mean by 'fairy-tale excuses'. The story gives just enough thematic context without cutting out possibilities for various game-play scenarios. There are a couple of moments in the game that I hope will a bit touching though.

@FadedReality:
I'll get everyone from the humble bundles registered with Lexaloffle accounts before 0.1.8.

good to hear an update, I really like the idea of adventure mode and roguelike modes. Cant wait tell this game get scripting to get implemented. You will be implementing scripting for levels to right? So later on people can make really cool mods/levels that are rpg or turnbased rpg and other stuff? I know thats a long ways off but is that what you are planning to be able to do in the editor?

Also do you think people will ever be able to create there on weapons and items using scripts and objects?

The scripting I have planned is flexible enough to make new weapons, new game rules and even make a completely different type of game. Hopefully it will become a kind of general voxel game-maker.

@b0rsuk
By the way, that's something the scripting can be used for -- pre-generating room data at edit-time, or perhaps run-time when a room is entered. I probably won't add tools as specific as pre-calculating sand positions but that's the kind of thing that could be added nicely as a scripted module. It also means people can make their own tools for doing things like building architectural features or growing variations of plants more easily.

Awsome

Awesome. I'll be able to write level generator scripts, cellular automata and stuff !

And if player is represented as a kind of a monster, I reckon it will be possible to script powerups that allow you to possess another body ! Bwahaha.

Hey, don't hold your breath bOrsuk ! From the scope, I guess that those changes would probably take a few long months or maybe a year or two before being implemented.

Lua?! Why not python?

Python is still a contender. It might be a little too heavy and tricky to handle forced fixed point number representation. I'll have to try both out with real cases to see how they perform & feel (but this will happen much later).

Properties OH YEAH!!!

I hope the bouncy voxels don't just allow to jump higher, but bounce projectiles as well. This could be used to place them on borders of a room. A very effective player strategy is to stay near the border or corner of a room and just dodge missiles. If they bounced behind your back, it would get tricky !

I have several ideas, if not possible or if you like them all, did not read all comments =].

• To change the rate of fire and even the number of gun (default two).

• Change the shape of bullets.

• Change the power of bullets.

• New type of voxel, the invisible wall and becomes invisible wall (in the style of isometric games, for example: Project Zomboid, walls that are invisible to be behind them).

Also I have a question: in the new accounting system will have to buy again voxatron people who get the Humble Bundle? (I have no problem to buy it again =], I gave my money to charity).

If negative voxels end up being implemented, I DEMAND a Portable Hole power-up ! Not a Portal ripoff, rather a device similar to what you might see in cartoons. You pick it up like a piece of fabric and put it on a wall. Once on the other side, you can pick it up like an ordinary item. As a bonus, it would allow player to pass through indestructible voxels.

By the way, I've seen someone using red letters on this "forum". How is it done ? [color=red]blah[/color] doesn't work.