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.
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.
These properties determine how voxels and objects behave when they come into contact with each other. Such interactions are not expensive cpu-wise because the voxels can sit around dormant most of the time and don't need to be checked unless an object is touching them. (An object is anything that is moving; a monster, bullet, or piece of dirt flying through the air).
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 SystemWhile fixing monster behaviour bugs, I found that the monster management code really needed to be rewritten sooner than I expected. Apart from the alien and the dragon, all of the monsters were completely drawn and written in the first 5 days of development and then subsequently left untouched. I was perpetually on the verge of releasing a preview alpha for a long time, so put off moving the code back into a broken state in favour of keeping the game in a releasable state.
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!)
ScriptingIt will be a while before I get deep into implementing the scripting side of things, but I needed to have a provisional plan in place to guide the design of the monster system. I spent some time looking at different scripting languages, and even the possibility of making my own parser and virtual machine. I love reinventing the wheel, and I think Voxatron has benefited from that in other areas. But in this case I should admit that it's not a good battle to fight if there is a decent alternative.
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.
StoryThis also might not seem super-important at this point, but I don't ever want to leave the overarching design of the game stopped completely cold. There's only so much that concept art and design documents can capture, and I find the best way to keep the vision for a game alive is just to keep stimulating the parts of my brain that came up with it in the first place.
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 InstallersThere's still a bit of manual labour involved in producing each update, so I spent some time automating the process more. There are 7 separate builds for each game, and I can now produce them all with two scripts (one for linux+windows, and one for osx builds).
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 SystemI 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.
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.
P#5151 2011-12-07 22:59
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.
P#5159 2011-12-08 09:16
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.
P#5161 2011-12-08 09:23
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!
P#5168 2011-12-08 12:56
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. :)
P#5201 2011-12-09 00:45
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.
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.
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.
I'll get everyone from the humble bundles registered with Lexaloffle accounts before 0.1.8.
P#5211 2011-12-09 05:09
Also do you think people will ever be able to create there on weapons and items using scripts and objects?
P#5214 2011-12-09 14:07
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.
P#5215 2011-12-09 14:32
P#5684 2012-01-03 22:57
:: New Ideas and One Question
+ 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).
P#5688 2012-01-04 19:52
By the way, I've seen someone using red letters on this "forum". How is it done ? [color=red]blah[/color] doesn't work.
P#5720 2012-01-09 05:51
Log in to post a comment