Epic Airship to Airship Combat
Our composer, Adam, has cooked up great new music for Guns Online – and at the same time, we’ve designed a system which allows for music in game to be driven by in game events.
Here is a sample of one of his tracks for Guns Online – if you’re interested in our music system, read on and I’ll go into some depth on our implementation of dynamic music in Unity.
Your browser does not support the audio element.
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.
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:
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.
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)
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.
I always felt that there was much to be desired from controlling vehicles in some of the top shooters. I remember playing some of the first shooters where I could control a fighter plane. I think they got a lot of things right in that the controls weren’t incredibly responsive like usually how driving a car would be. Turning was slow and difficult, risky even. Sure, it’s close to reality but that doesn’t mean it’s enjoyable. Maybe there wasn’t enough intermediate feedback. Either way, it’s concerning because vehicle driving is a core gameplay element in GoI: Online.
The world of Guns of Icarus is in an interesting place, historically speaking — a grand civilization devastated by relentless war and sunk into a post-apocalyptic ruin, so much progress and knowledge and technology lost, the people who remained scrabbling and struggling and surviving, barely.
But that’s not where we enter this world. We enter it later, as the tides are changing and something new is shifting beneath the surface of the restless sands. As more and more airships are built in makeshift dockyards in villages scattered across the Burren, as young men and women leave their homes and take to the skies to crew them, traders and adventurers and daredevils and visionaries, a new class is arising, with the potential to change the world. Airship captains and their crew are the new knights errant, the new merchant class, explorers and ambassadors and warriors. As trade routes open and formerly isolated communities come into contact with the wider world for the first time, a seismic shift is underway, and nothing can stay the same. Not that it will be easy. Not that it will be peaceful. Not that anyone knows what it will be like.
Because in the multiplayer campaign mode, those new adventurers changing the world are you, and we don’t know what you’ll do.
This is something that I’ve been not only thinking about but experiencing myself. The opportunities and problems afforded and created by the addition of different dimensions (mostly in the traditional sense like 2D to 3D but the definition is loose) becomes both amazing and daunting. I’ll keep this confined to map and level design.
Starting with making 2D Flash games, level constraints are quite straight forward. You only have two degrees of freedom (x, y axes). Take for example the ubiquitous platformer: movement is defined by floors. 2D platformers are easy to grasp whether due to its simplicity or its commonplace nature in games. I remember drawing Sonic the Hedgehog levels before I could spell Sonic without looking at the box. Walking on terrain is a simple game that we all know because we’ve played these games as children–skipping over cracks in the pavement, hopscotch, and etc… Creating levels for 2D games are fairly straightforward and are easily produced on paper by drawing simply lines to represent the ground. There is easily a standard for designing with these constraints. The information that is required to effectively convey the workings of a level can easily be read and drawn on a piece of paper for an everyday platformer.
The art team is hard at work putting a trailer together for Guns Online – here is a sneak peak of things to come.