Friday, November 20, 2015

Unity3D At Home Project - Day 10 - From Simulation to Gameplay

So this is a bit of an interim post, where I just talk about game developery things, without having done real work on the game itself. As such, it's likely to turn into a rambling diatribe that no one actually gets to the bottom of, but there's a process that happens here - it's really important - and one of the reasons I'm doing this blog as I make this game is to share the things I've learned from fifteen years of game developement. So here goes.

Look how far we've come already!
The Story So Far
So up until now, in our game (it really is going to need a name soon), all I've really done is worked on simulation. That is, we've just been working on some fundamental things we knew we were going to need, without really thinking too much about actual gameplay. And we've seen even just that is actually quite a bit of work. We've got a mech animating, walking about with a game controller, playing sound effects, and a camera that follows in a pleasing manner, and it all works over multiplayer. But now we're ready to start actually firing weapons, and that means the mechs need to have health, and we need to do damage, and that means we actually have to start thinking about gameplay. Now, I could slap a health value on the MechController component, and I could just jump right into putting together a weapon that fired some effects and ultimately modified that health value. That is, I could, continue right on with building a weapon that does the most basic thing, and I would probably learn a lot - but if I did so without really starting to think about gameplay, then I would probably end up - pardon the expression - shooting myself in the foot.  That is, without taking a moment to actually design some of our game, we would either be building a weapon that didn't take into account all the things we want to do. Or worse, at the opposite end of the spectrum, if we build too generic of a system, we might end up doing a lot of work to support things we never really intended to build.

Exploding Design Space
So in short, before we go any further, we need to think about the actual design of the game. And when you start thinking about all the things you might want to do, well the problem space just explodes. For instance, here is just a short list of thing to think about in our game design:

For mechs -
How many different types are there?
What are their characteristics? Health? Armor? Speed? Acceleration? Weight?
Do they have jump jets? Shields?
Do we worry about heat and heat dissipation?
Does terrain effect our mechs? Do they cool down standing in water? Go slow through mud?
Are we even going to have water and mud?

That's just a few. What about weapons?
How many different kinds of weapons? Lasers? Missiles? Chain guns?
Do we have hard points? Can you swap out weapons on a mech in some kind of loading bay?
Can you pick up weapons while in game?
What are the effects of weapons? Do we have healing weapons? Slowing weapons?
What about ammo? Do weapons have ammo? Do you have to carry it with you?
Can you pick up ammo in game?

And then let's think about the gameplay itself:
What do the levels look like? Is it terrain? Is it a city block? Both? Some kind of interior?
Are there powerups, in the traditional shooter sense? Repair stations? Cooling stations?
Are there destructible objects in the world - trees, buildings, etc?

Okay I'll stop - you get the idea. Now, I know that you know, what I'm about to say next. Yeah Dusty, we get it. You can't do all of it - pick the things that are important, and focus on those. Duh. But the thing is, (and yes, that was what I was going to say next, thank you very much) while that's very easy to say, when you've got your sleeves rolled up and you're down in the trenches building your game, it's actually really hard to do. Because, like me, you love games. And you want your game to do all those things. For every single item I've listed up there, I can make an argument as to why we absolutely have to have them in our game. Jumpjets? Whoever heard of a mech game without jumpjets! Ludicrous! No destructible buildings? Mech games are all about smashing trees and buildings! It's not a mech game without that! No hardpoints? Deciding on your loadout and swapping weapons is key to playing one of these games! It's where some players spend the most time - how could you make a mech game without it?

In 2006 Rob Pardo, then with Blizzard Entertainment, opened the Austin Developer's conference with a keynote on Blizzard's design tenants, and how they shaped the success of World of Warcraft. It was, for me, a watershed moment. I was there, I listened to the keynote, and I furiously wrote down everything he said, but it turns out I didn't need to. Because those things have stuck with me, and here, ten years later, they are still my creed when it comes to game design. And one of the biggest things he talked about, in Blizzard game design, was having to make tradeoffs.

The company also tried to remain conscious of trade-offs in game design, and the fact that "every decisions costs" in one way or another. "All game designers are very greedy by nature," Pardo said. "We want to have every cool feature, and we want to serve every market. The reality is that almost every design decision comes with a trade-off. Nothing in game design is black and white, it's all shades of grey."

That's from a GDC article on his keynote. And it goes on to list the examples Rob gave of tradeoffs they had to make for WoW - Instanced dungeons, flight paths, stylistic art design, and so forth. And the interesting thing is, if you look at some of those decisions, you know that they have since then changed their direction on many of those things. And you can say those tradeoffs were the wrong things. They were bad decisions because they ultimately reversed them. But they weren't. They were good decisions, because they allowed them to ship the game at the time. And then, years after the game had shipped, they had time to revisit those decisions, and make a different set of tradeoffs.

If you aren't familiar with Rob's GDC keynote, I highly encourage you to read the article I've linked below. In my opinion, it's required reading for anyone making games - large or small.

There's a lot I can learn from MechAssault
Find a Model that Works
Okay so I've rambled on about the problems around your exploding game design, and the necessity to make tradeoff decisions about what you do and don't want. So how do you go about making those decisions? Well one important thing to do is to find a game that is shipping, that is similar to what you want to do. For instance, for me, I looked at MechAssault. It's an old game, but they had to face some off the same tradeoff decisions I'm thinking about right now. What did they decide? If I were making a game, say about interstellar trading, I would probably look at the greats like Trade Wars 2000. Or I'd play a lot of Eve Online. The thing is, there is almost certainly  out there, somewhere, a game that already exists that does at least some of the things you want to do in your game. Find it, play it, learn from it. That doesn't mean copy it. But what were the things they decided to forego. Why? Did it work for them? That knowledge will help you in making your own decisions.

The other thing that helps, and unfortunately this just really only comes from the school of hard knocks, is just your own experience. The more you do this, the more you'll come to understand the ramifications these decisions have. For instance, I know that if I decide I want to have hard points and swappable weapons, I'm signing up to build a complex, yet intuitive interface to allow users to change, select, and set weapon systems. And that's a lot of work! Even just saying yes to Jumpjets means hours of tweaking thrust times, landing velocities, animations, and particle effects.

Constrain Constrain Constrain
You have to make tradeoff decisions regardless of how many people you have working on your game. And those decisions aren't easier, just because you have more people. In fact, often they're harder, because with more people, you're tempted to tackle more systems. But when you're just one or two people trying to knock out your indy game, the mantra has to be constrain, constrain, constrain. Even myself, in my own head, when I think about the decisions I have made for this game already, I know I'm probably biting off more than I should. One of the biggest problems I faced in Atomic City Adventures was that I built too large of a game, for one person. And it took too much time. So if you got this far, and you come away from today's blog with only a single thought, it is this - take everything you want to do in your game. Widdle that list down to the absolute bare minimum list of things you absolutely have to have in your game.  And then be ready to throw half of that away, and figure out what you can do in your game with what's left.

Skip to the End
Okay I've rambled on about game design long enough. For the next blog, I'm going to talk about the specific decisions that I have made for the At Home Project, and then about some ways to data drive your game systems.  And then I think we'll be ready to actually build some weapons. 
Questions? Thoughts? Please post them below

Useful Links

This is the writeup on Rob Pardo's keynote address at the 2006 Austin Game Conference. Required reading for game design, in my opinion.

Interested in reading about this project from the very beginning? Find it here!

No comments:

Post a Comment