Horrible Places

It’s been a while since I last blogged, and I was announcing a rather exciting thing: my replacement of the stock Player movement code to make way for something hopefully more realistic and exciting. That’s still simmering away, with most of the main changes done, but needing fine-tuning, tinkering, and finishing touches.

I’m frankly not ready to show it yet – and that’s not even anything to do with the lack of an example character with the right animations and such. (That reminds me of another project I talked about a while ago and never mentioned again – the scripted animation manager is still alive, I promise!) But I’ve been pondering something for a while, and I thought I’d tell people about it to see if they were excited.

I was playing a lot of Stalker a little while ago, which inspired me to recreate that sort of environment in Torque. Something with a little ambience, like ths:

From Stalker: Shadow of Chernobyl

But my project at the moment doesn’t really require any of that specific content, so I figured I’d make an environment pack out of it, if my produce turns out good enough to sell. The pack will be showcased in a demo level. I was thinking of styling the level around a little abandoned hamlet on the edge of a forest in the hills. The level would be based around triggers to show off cool things, like ambient noises, swarms, and a gravity storm. Here’s the list of art I want to include in the pack:

-Two or three ruined houses
-Grass sprites, healthy and dead grass, in low and high resolution
-Several dead trees and several spooky-looking live trees
-Several dead shrubberies?
-A double-handful of detail objects like weather vanes, kitchen utensils and outdoor tools, and furniture
-Assorted warning signs and fences
-A few wild animals
-Two skies and assorted clouds
-Terrain and textures, of course

But an environment pack alone isn’t much good if you want a Stalker-style setting – I imagine a lot of stuff going on in that setting that would require code changes. To that end, I’ll also be making a code pack as well, adding some extra functionality to the engine to allow you to create nightmarish environments. Before I go on, I should mention that the code pack will be free, but the environment pack will be charged for. Why? I most likely won’t be using any of the art assets I make in my game – its setting just isn’t right for the environment I want to create right now. However, I will be using the code in my game. What does that include? I see it this way: if I’m giving something to the community that I won’t be using myself, I’d like to receive something for the effort. On the other hand, the things which I will be using will be their own reward. Also, I like packs that include code, but I have no need for the art in them; this way, people who want art can get just the art; people who want code can get just the code, and user their own art.
Anyway, a code pack. I thought the following things would be useful:

Global, dynamic gravity and wind
Both the gravity and wind in a level will be managed as objects in the Mission Editor. Scripts can set the strength and direction of wind and gravity in real-time. Also, the wind makes noise. (Note that water blocks will not be affected by gravity, I'm pretty sure :P.)

More things that hurt you
I’m not quite sure how I’ll manage this, but eventually both particle emitters and precipitation will be able to do damage to things they collide with. Also, if this isn’t already possible, I’d like to add some more dynamism to precipitation, allowing you to turn rain on and off, vary the strength, etc. Fog layers will also be able to do damage to characters who enter them.

Breathing
A breathing system linked to a GUI control makes walking underwater that much more stressful. It also kicks in when you’re in a fog layer that will damage you and can be fully script-controlled for other situations. I don't know whether to include simple swimming code, but I'll think about it.

Swarms and flocks
Swarms of insects and flocks of birds are provided as example uses of a new swarm class based off the fxSwarm resource.

Dynamic sky and sun
Both the sky and sun can be altered in appearance in real-time. This doesn’t include moving the sun, just changing its colour and brightness. The sky can dynamically change the images used for each of its six sides and cloud layers, with a time delay and blending.

Lightning
Lightning can do damage, and will cast light where it strikes. If it doesn’t do that already. I need to do some research.

Spooky eyes
Not an amazing feature, but I’ve always wanted to add some spooky eyes in the bushes that disappear when you look at them. This can be extended to objects that do all sorts of things while your back is turned.

Fauna
What horrible environment is complete without packs of roaming wild dogs? That try to bite your knees off?

Ambient sound
This is a tentatively planned feature, a ‘wouldn’t it be cool?’ sort of thing (along with spreading fire). The idea is for interior instances to play ambient sounds when players move around in them – creaking floorboards, ringing metal, etc. These could be synchronised with the player’s footsteps, or played semi-randomly, given time delays and variation, linked to certain materials in the interior, and whatever else I can think up.

Other stuff
I plan on integrating and making use of a few resources, such as Thomas Lund’s message router system, and Orion Elenzil’s radial force physical zones.

You could call this WarEngine code pack 1, because I've always intended for these sorts of features to be included in the WarEngine.

Now, I know I’ve made some big plans like this before, and not much has been produced. I’d like to think this is the start of me getting organised. Anyway, the real purpose of this blog is to gauge interest for a combined pack like I described – a free code pack with environmental features, and a priced content pack with a sample environment making use of the code changes. Do the code features seem useful? Would you like to see an environment in the style I’ve described? If the interest isn’t there, I may as well not bother with the environment pack, and just focus on the coding work. I’d also like your opinions on whether a big code pack is the way to go, or whether I should release each separate piece as its own resource. I’ll be implementing it in a modular way at any rate, so you can pick and choose pieces – it’s just the format of its release that I wonder about.

Thanks for reading.

Oh. Just in case this blog wasn’t long enough already, I’ll give you a little update on all that stuff I was promising last time. I am still working on it, but not actively. I’m in a rather tricky situation in real life, with the family moving countries and myself figuring out university – the upshot it, I’m programming on a netbook, which can’t run games worth a damn.

Right. The stuff I promised.

Basically, I’ve decided to curtail my use of springs somewhat. While they’re useful for legs (I think I’ve got them just where I want them, in that regard), they’re not so hot for arms. So for mantling, I’ve come up with a solution that I really should have thought of ages ago. What is mantling? It’s a jump. So why not make the player jump to mantle? Same thing with vaulting. Combined with a body animation, IK for the arms to look pretty, and there you have mantling.

I’m also looking at having an animated collision hull to account for multiple stances, rather than having to process multiple hulls for each character. Because if you think about the case where a player jumps at a ledge and connects with it halfway up his thighs. At the moment, my collision hull only covers the body. So that’s a miss. The leg springs only start at the knees, so that’s a miss as well. I can’t extend the collision hull downwards, because then if the character crouched, their hull would be touching the ground and the springs wouldn’t get a say in it. So I’d like to be able to animate the bottom of the hull, instead of adding another separate hull for the upper legs.

If I can find a way to optimise multiple-hull collision, though, that would be my preferred option. It’s more intuitive and provides some useful functionality, like having different collision responses for different hulls.

Then once I figure that out, I have to finalist my changes to the OrangeGuy and actually create all those damn animations. Fun, fun, fun.

Okay, that’s really all. Bye now.

What? No Toni? The poor guy must be shattered.

Sorry for the dearth of images.