So, I'm finding the prospect of free-form monster design pretty exciting, and managed to feature-creep 0.2.6 all the way to what was going to be the 0.2.7 feature set. Sorry about that, level designers! (And people hitting the BBS levels room-zero bug). Here's a quick preview of what's coming in the form of some silly test monsters showing examples of modifiers, emitters, custom bullets, particles and new triggers.
These octopi are made by emitting particle animations from the head so that they look like solid tentacles.
Using periodicly triggered modifiers to implement regular jumping.
Disco blocks -- collision events trigger the blocks to change their animation, with a separate warm-down animation when they are no longer touching another actor.
Circling the player.
A monster that contains a randomly triggered modifier that causes him to be physically taller, walk slower, and emit bullets from a hat.
Do monster/objects only chase the player, or can they chase other monster types ? (to make allies, ...)
Are some events triggered by the proximity of other monsters/objects ?
I can see plenty of uses to ally monsters not to focus on the player only. But it is a bit more work programation wise...
@CyberSkull just to clarify -- these features aren't available yet, but will be in 0.2.6 shortly.
In 0.2.6 they can only chase the player, but in the future they'll be able to have arbitrary 'targets', which may be either a moving object or a particular point in the room. This might also eventually be useful for multi-part monsters like the dragon (each segment follows the one infront) and scripted cut-scenes. And as you suggest, to create more interesting movement patterns and A.I.
Yes, you can trigger events (modifiers) based on proximity. The event triggers available in 0.2.6 will be: collide, hurt, is_standing, speed, life, time, random, periodic. I'll expand this set as required for common cases, and then in the future more specific cases will be able to be handled by general scripting. I'll explain this in more detail in the next dev diary, as the design for scripting as evolved somewhat.
Another test .. these guys randomly lunge towards the player and flash a random colour.
Daaaaaaaang I can't wait!
Random off topic idea (if you don't mind answering, Zep): What are your thoughts about compiling a version of Voxatron for the Raspberry Pi? 2.5 already works surprisingly well on my crappy ASUS EeePC 700 (Crunchbang Linux, Intel Celeron-M ULV 353 800MHz, 500 MB RAM), so it probably just needs to be compiled for the ARM processor that the Pi uses, correct?
Pi, yes absolutely! But it won't be until around 0.5 (quite a while later), as managing and testing extra builds does take a bit of time. One of the rendering options will be a simple orthogonal view (like the [web version](web version)) which should allow it to run at a decent speed on slower machines.
Yeah, it's late o( )o
I shouldn't pick a new eta as I already changed my plans twice, but I'm really down to just bugs now and it's easier to predict. So.. Tuesday! See you all then ( ^ _ ^)b
@ladybug twistyness is a new parameter for wandering that controls how much the monster turns (0 == straight lines, 1 == twisty path)
Really cool to see so many awesome changes to Voxatron recently, after being so much time away!
I still felt there was something lacking, though, and only now realized what it was:
Moving the camera sideways during gameplay! :D
That would be really awesome! Even if it is just locked to the 4 sides of the rooms
Log in to post a comment