Sunday, August 4, 2013
7HFPS: "Harriet"
For 7 Hour FPS, I imagined some sort of Tribe-ish Mechwarrior game where you're a Harriet pilot ("Harrier + Jet") and you fly around shooting homing cluster missiles at things, deforming the terrain to make new skiing slopes / carve new lines. But in my early control tests, I decided the "piloting a death robot" fiction wasn't really helping / wasn't terribly interesting, so now I'm ditching it. I'm not sure what to do with this, now, but I think I'm leaning toward a game about the undesirability of godhood / immortality, and maybe I'll polish it up for 7 Day FPS in that direction.
Similar first person games about movement / hopping / surfing / skiing: Perfect Stride, Purity, the endless CS / TF2 surf maps, the notorious Tribes series... typical first person movement just seems so terribly boring in comparison.
In other games, surfing / skiing is a byproduct of messing with the engine's friction implementation and using strafing / jumps to build-up momentum. It's kind of fascinating, to realize that these player communities have invented a new way of walking, a sort of expressive movement without strategic or instrumental purpose -- a type of dancing, maybe?
Play prototype #5 here (< 1 MB, Unity web player): https://dl.dropboxusercontent.com/u/19887116/harriet/web5/web5.html
In Unity, my implementation is really simple but it works: just a standard terrain collider and a rigidbody-powered player capsule with a low-friction physic material. To help prevent a tunneling / falling-through-the-world effect, I also set the rigidbody to "Continuous Dynamic." Everything from there was a lot of testing and tweaking.
The biggest technical problem, though, is something I have very little control over: uploading data to the Terrain object causes framerate hitches. Generally, it seems like modifying the texture blend splats is very cheap and performant -- next, editing the TreeInstance array starts getting expensive after you have a lot of trees (~10000+ trees), and editing the structs unfortunately does not refresh the tree renderer, so you're stuck with having to insert a whole new array every time -- but by far the most expensive thing is modifying the terrain and deforming the heightmap / geometry. I think the possible workaround here is to use some sort of "cell approach" -- make one big mega-terrain from dozens of smaller stitched-together terrains. If I pursue this prototype further, that'd probably be the first thing I look at. The alternative is to make my own terrain system, which sounds like something that's not worth it.