Dirty Prototypes
Originally this post was supposed to be about prototypes in general, but with the popularity of scrum and agile these days I think everyone knows what prototyping is about. What I want to emphasize dirty prototypes. What I mean by this is creating extremely low fidelity prototypes. I think a lot of time is wasted when people get carried away and start paying attention to adding in details, me included. If I took this lesson to heart earlier in my career, I think I would have been able to catch many more mistakes earlier.
Why I advocate for developing tests quickly is to get results as soon as possible. You ask a question, you want those answers now in order to stay ahead of the curve. These answers may even tell you that the direction you’re going in is also just wrong. And because you’ve spent so little time invested in a wrong idea, you’re more likely to set it aside and revisit it later while moving on to something else.
I think the practice and habits are obvious. Scribble things on paper. Only spend a couple of hours coding something, hacking, in a separate Unity project. Get those cubes dancing. Get it out to your peers and coworkers and get their opinions. As a game designer, you must be ruthless and always follow a crumb trail of where tests lead you. Create a dirty prototype with your gut instincts (don’t spend hours looking for damn metrics, that can also waste your time) and test. That test is your metric. It will tell you if your idea is good or bad or needs some more work.
Relentless. Ruthless. Ever-producing.
Building a better UI workflow in Unity
A lot of people ask us about our thoughts on Unity as an environment, and I thought I’d share a bit of one system I’ve been working on recently.
Typically, we have only good things to say about Unity – however, our common complaints relate to the UI system(s). The 2.0 immediate mode OnGUI is quite configurable, but it gobbles performance – and isn’t artist friendly. It can be very powerful, but layouts are complicated and unintuitive – and did I mention it eats performance? While we use it heavily for editor GUI development, we consider it unusable in a game runtime environment.
Unity 1.0 GUITexture and GUIText on the other hand are simple to layout and use, and performant, but not nearly feature complete. I’ve worked with sprite based solutions as well, but hate the frequent pixel imperfect rendering and aliasing issues – along with the inability to display Unity’s super-cool dynamic fonts – essential for the display of asian character sets. Sidenote to devs at Unity – Feature requests here: Please expose the UVs of dynamic fonts for consumption by alternate UI display libraries.
What we really needed, was the simplicity of 1.0 GUI layouts – with the power of Unity GUI 2.0.
Enter my most recent custom GUI layout solution, built entirely on top of 1.0 GUITexture and GUIText. This system could easily support alternative rendering methods, such as a sprite system, however, I’ve chosen to use 1.0 GUI. Without further ado:
Lighting Up the Sky
We’ve always thought of Guns of Icarus as connected with big, dramatic panoramas of sky. Spectacular sunsets and rises, towering thunderstorms, mountainous ranges of puffy white beneath a noon sun, that sort of thing. I’ve been working recently on some things to populate our big empty expanses of 3D sky: clouds.
There are two competing goals here: first, to make our clouds look awesome, which means spending graphical resources, and in particular integrating with our lighting system. At the same time, I had to do this without slowing the display on user machines to a crawl. Simple particle systems fail both of these tests: the options for rendering are limited, and they become extremely fill-rate hungry when you layer them thickly enough to look good.
Some (okay, a lot) of shader experiments and procedural mesh manipulation code later, and I think we’ve got something pretty cool. Here’s the same scene three times, lit by a single directional light that’s been rotated to different angles.
There are a couple of technical tricks going on here that help performance a lot. Though similar to particle systems, in that these are flat meshes oriented towards the camera, the thick central portions of the mesh are fully opaque and participate in depth testing, which cuts down significantly on fill-rate usage. Also, we can do most of our lighting per-vertex, and it looks just fine – for big soft clouds, we’ve found that high-detail lighting actually looks worse, because it destroys the illusion of a mass of vapor.
Unity’s standard lighting model actually gives you quite a lot per-vertex, basically for free. The combination of multiple vertex lights per pass with spherical harmonics for very distant lights allows us to add lights almost freely so long as we’re willing to accept that they are low detail. For fast, flickering lights (explosions, thunderbolts, fires), this seems like a win-win situation!
The cloud particles are positioned procedurally (just random distribution), but within volumes that are defined (by boxes, nothing too fancy) within the Unity editor. This allows us to shape the cloud volumes, an important factor if we want to use these as level geometry, with players flying in and out of them for cover. Which is, of course, the plan.
These static images are well and good, but let me leave you with a better demonstration of just how well this system interacts with real-time lighting. This is the result of a simple script that spawns randomly positioned, short-lived point lights.
Pacing Actions
I’ve been playing a lot of Deus Ex 3 lately. Most of the office has. It’s got me thinking about how its different mechanics are spaced throughout the game. For the topic of pacing, I’d categorize them into core and intermittent mechanics. The core mechanic in DX3 is the sneaking or not-sneaking around buildings–taking out and shooting included. You spend most of your time doing that sort of stuff. The intermittent mechanics include both hacking and the talking/negotiation game. Intermittent is a good way to describe it because both hacking and talking stop the core mechanic from happening for a time. When you’re hacking, you better not be trying to sneak as well because you’re always in danger of someone seeing you. When you’re talking, you’re automatically always in a non-hostile area. Therefore, the core mechanic is put on hold for the duration of hacking or talking.
(Minor Spoilers Ahead)
Streamlining the Experience
I would argue that the core doing (different from motivation, goals, or the ambiguous “experience”) of an MMORPG like WoW would be in the combat. Specifically, combat against epic enemies and dangerous dungeons with your brave buddies (ok, I’m done with alliteration). Anyway, the reason why I want to break this down is because I believe that it gives us a good idea of what kinds of play styles people are interested in and thus give us something to map our own doing in GoI:Online to. So let’s start gutting out the interiors and try to find the foundation.
There are many roles a players can specialize in when dungeon crawling. I believe the most distilled format is tank, hitter (dps), and healer where more likely than not you will have one tank, one healer, and several hitters. A tank is responsible for maintaining aggro (aggressiveness) in order to attract the various creeps and enemies. The tank is ultimately a meat shield and are aggressive in order to prevent enemies from attacking everyone else. Hitters (yes, that’s what I called them in my MUD days) are responsible for dishing out as much damage as possible and as quickly as possible, thus the Damage Per Second ratio. Healers needs to heal mainly the tank who will be taking most of the damage. If the tank is unable to maintain aggro, then the healer must also make sure everyone else is safe too.