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.

Monday, July 29, 2013

Radiator Book Club: Architecture, design and criticism.

Book Club posts recommend books and approaches to consuming them for today's go-getting game developer / enthusiast.

ARCHITECTURE
These are books that I find useful for learning about architecture as design and theory. I've never formally studied architecture; my reading usually has to pass a "can I apply this to video games?" test that is intellectually cynical but like whatever. Fortunately, few things in architecture fail that test.

Grammar of Architecture (Emily Cole)
Every single environment artist should have a copy of this book; it's basically a 300+ page cheat sheet that talks about common decor patterns / floorplan structures of most pre-Neoclassical architectural styles around the world. Cole generally does a good job of balancing discussion of ancient Indian temple ornament with the The Alhambra's mathematical dimensions, trying to explain the history and ideas behind individual elements. It's effective because it doesn't try to be deep and is content to be a general survey, relying heavily on (numerous, small) drawings and pictures. It gives you a fast surface understanding of a style (e.g. a few pages for Gothic, and that's it) -- enough to build it and move on. These are, essentially, 150+ pre-assembled moodboards.

Thursday, July 25, 2013

Experiment 12

I'm not sure if it's in the spirit of the thing to actually explain or say anything about the thing, so I'll say very little about it, I suppose:

Terry Cavanagh thought it was cool how the RPG Maker community did chain games, so why shouldn't we? We agreed. And so: Experiment 12. My chapter was kind of disappointing -- I went out of my comfort zone and came back with mixed results, especially after following the great work Michael Brough did on his chapter -- but I guess it's okay, you can't win 'em all... And overall, I think everyone did good work, and the diversity makes it all feel really human and raw.

Wednesday, July 24, 2013

Radiator Book Club: the Game Design Bibles

Several independent parties have asked me for book recommendations and stuff, so now I'm starting a series of posts about books to read, and some notes on how to possibly approach them.

THE GAME DESIGN BIBLES
These are core books that establish terminology and basic theory about games and development. If you've played games for a long time, much of this material will seem obvious / simple / not worth saying... but that's only because games are in your blood. A lot of it isn't obvious to everyone. So, it's important to maintain a "greedy" attitude in reading -- pick and choose what you like from these texts, and don't feel obligated to like (or read) the entire book.

Rules of Play (Katie Salen, Eric Zimmerman)
I'm pretty sure Rules of Play is taught in, like, every university-level game design class in the world. It's extremely comprehensive in approaching game design as science and culture -- it's pretty much a primer on everything. The problem I'm seeing, though, is in the people who've rarely played games but want to make games as a career: they read this book and think this theory IS games, rather than a tool that sometimes helps you think about games. (see: "the map is not the territory") These "textbook developers" have a strange way of doing things, often wondering aloud how best to satisfy The Five Different Types of Players or how to Teach the Core Mechanic, instead of, uh, talking like a human being. I think game design is really lucky in that the veterans / masters of this field will usually preach against simple fundamentalism like that... well, usually.

Tuesday, July 23, 2013

Radiator 1-2 Handle with Care, Sourcemod gameinfo.txt fix for Steampipe VPK file format shift

In the last few weeks, Valve has dropped the GCF file format. A "GCF" was like a ZIP file containing thousands of game files. They were usually quite large (several GB was common) and so they were prone to file fragmentation, which balloons loading times as games need to load more files and assets. With Left 4 Dead, Valve started shifting their filesystem infrastructure to a "VPK" format -- instead of being stuffed into one or two colossal files, game assets are distributed among many more smaller .VPK files, improving loading times. Valve has now converted all their older games to use the new VPK file format too.

It's great, but it has also broken most Source mods made before 2013. Fortunately, the fix is pretty trivial: it involves editing the "gameinfo.txt" to mount the file assets in a different way / order than before.

If you want to play Radiator (or any single player mod based on Episode Two), just follow these instructions:

Wednesday, July 17, 2013

A Half-Life book: some pillars.

(CAVEAT: Manifestos, by their nature, must be militant. I use environmental storytelling theory all the time in my games; however, that won't stop me from pleading for its death as the pre-eminent narrative methodology in action games. There are countless other ways to tell stories and mean things, we must simply discover, articulate, and disclose these new ways to each other.)

I guess I'm writing some sort of book, about Half-Life 1, for Brendan Keogh / Dan Golding's new recently sort-of launched book publishing project. So what's there to say about Half-Life?

I know I definitely don't want to focus on Half-Life's authored narrative (dialogue, scripted sequences) or "environmental storytelling" -- I think that approach is played-out, and the promise of that approach has proven to be a failure -- it's convinced so many game developers that a ragdolled corpse with some blood and bullet decals is supposedly a "good story" instead of a weak, generic vignette that's not really about anything. Two ragdolled corpses next to each other isn't a good story. A chair with a shotgun next to it isn't a good story. There are very real limits to this methodology if that's the most "subtle" we've been.

Tuesday, July 9, 2013

I made a video game trailer



I've had this song sitting in a folder (called "trailer music") for about 3 years.

Sunday, July 7, 2013

How a "Last of Us" art dump thread teaches "vision."


At Polycount, Rogelio Olguin posted an art dump of some environments from The Last of Us, as well as some notes on his environment construction process. All of his posts are worth reading, but I'm going to copy the part that really stuck out to me:
"One thing I hold true is that one texture will not make things look awesome. Imo well balanced shaders will. I think we are starting to move away from this one texture looks sick. Like the below textures are kind of boring alone but together it looks sweet. I really do not think anything we did in ND is "special" it just well balanced from good forms and composition (Modeling) to materials treatments (texturing)"
This shift in AAA art workflows, from focusing on individual art assets to thinking more holistically about how shaders, lighting, and art direction work together -- I think most AAA-affiliated 3D game artists agree with that in concept, but a cursory look around the Polycount forums shows that many of them still focus on honing one perfect asset for one screenshot.

Part of the problem is a games industry that demands certain types of presentation, style, and specialization in portfolios. ("To work here, you must have one normal-mapped sci-fi crate prop, with perfect topology and no wasted UV space.") But I think most of this problem stems from a lack of vision.