(Post stolen reposted from Shamus’ Good Robot Devblog)
Way back in July, I said the plan was to have the game “feature complete” by September. I think we sort of met that goal. We’ve completed all of the features planned so far, but I think everyone expects to add a few new features between now and the planned February 2016 release. We do have a mild case of Feature Creep, which can probably be managed through medication and therapy.
What we’ve done since July:
- The interface has solidified. Actually, it’s not so much “solidified” as “been entirely replaced with something else, which has then solidified”.
- The gameplay still has a few remaining question marks, but the core rhythm of the game is there.
- The art style has taken shape.
- The story hasn’t exactly been written yet, but we’ve stopped re-inventing the setting every time we have a meeting. We’ve settled on a single idea that everyone seems comfortable with.
Last week I talked about Good Robot going to EGX. As of this writing, I don’t have the feedback from the public on the game. Although by the time I post this the show will be long over.
When Killing Things Gets Boring…
 |
It was almost two years ago that I said the game lacked interesting-ness. When I joined up with Pyrodactyl, the rest of the team agreed: The game needs “something else”. At least one more gameplay layer: A meta-game. Something to collect. A story to drive the action. A skinner-box mechanic. A mystery. Some humor. Something.
The robots kind of all felt the same. Some of them shot faster, some moved faster, and some were larger or smaller or had more hitpoints, but these variations were only enough to keep the player amused for about half an hour. Beyond that it just felt repetitive.
We were planning on adding some humorous story beats. That would help, but it probably wasn’t something to bank on. Yes, Borderlands gets away with this exact thing, but I think that game is the exception rather than the rule, and I wouldn’t want to bet on us being able to bolster lackluster gameplay with gag voiceovers. That sort of hope is the kind of thing that creates situations like The Writer Will Do Something. “Bah. We can make a shit game and then the writer will add a story to make it good. And if people don’t like the game, we can blame the writer.”
After a while we arrived at the idea that the current enemies didn’t have enough variety in their attacks. The weapons system had evolved over time in an ad-hoc way. There were a couple of different, independent weapons systems (lasers and missiles) that each had their own limitations and quirks and which had totally different interfaces. There were lots of options for the designer to worry about, but not a lot of interesting choices to make.
MOAR GUNZ
 |
So I tore out the various enemy weapons systems and replaced them with with a new unified system of projectiles. The designer could control number of projectiles, the rate at which they fired, their color, appearance, sound, how much they scattered, and numerous other things. You could make anything from a shotgun to a railgun to a missile launcher.
For the purposes of testing, I changed it so that the player could fire these new weapons, simply because it’s easier to launch the game and push the fire button than it is to launch the game and then fly around for thirty seconds looking for a robot carrying the weapon you’re trying to test.
What we discovered in the process of testing was that this made the game a lot more interesting. These weapons were supposed to be for enemy robots, but the real fun was when we put them in the hands of the player.
This also fits in nicely with something I really enjoy, which is making open-ended systems where other creative people can discover possibilities I’d never considered. You give them lots of options with potentially emergent outcomes, and see what happens. If you’re curious, here is what a weapon definition looks like in the game files:
#First is the name of the projectile, in brackets. This is the name used to assign the weapon to a robot in robots.ini. [GenericGun] #This is the name of the weapon shown to the player. Title=Plasma Repeater #This is the description for the shopping interface. Description=Start a conga line of bouncing chaos. #Type can be bolt or beam. Type=bolt #Slot is either primary, secondary, or "robot". (Robot weapons won't be available for the player. Default is robot.) Slot=primary #Size is the width and length. (Beams only use width.) Size=0.6 0.6 #The color of the projectile. Also the color of any residual particles and explosions. (Three-digit RGB hex.) Color=afc #The name of the sprite from sprite.ini Sprite=projectile5 #The name of the sprite that will be used as a pickup icon. Icon=Gun1 #The name of the sprite that will be the player's hand when this is equipped. Hand=Hand1 #How the hand will move. Values are: Fixed, Aim, Spin. HandAnimate=Spin #If true, the sprite will glow, like lasers. False means opaque, like a robot. Glow=1 #If true, the weapon can hurt the user with splash / reflections. FriendlyFire=0 #The brightness of the comet-tail effect. 1=full. 0=disabled. Tail=0.05 #If true, the projectile will chase the target. (Doesn't work for beams.) Homing=0 #If true, this projectile can be shot down by others. (Good for missiles.) Shootable=0 #The size of the glowing aura around the projectile. 0=no aura. AuraSize=0.4 #The color of the glowing aura. AuraColor=333 #Movement speed, in units per frame. Speed=0.08 #How long it takes for the projectile to reach full speed. Zero will disable acceleration. #THIS NEGATES BOTH GRAVITY AND SPEED SCATTERING. Use wisely. AccelerationTime=100 #The starting speed. ONLY used if AccelerationTime is not zero. StartSpeed=0.01 #How much the player is pushed back when firing. (Also pushes robots, but only cosmetically.). 0.0 = none. 1.0f = very strong. Recoil=0.0 #How much the trajectory is changed by gravity. Warning: Robots can't correct for this. Gravity=0 #Makes the projectile spin as it flies. Degrees per frame, so 1.0 = 60 degrees per second. Spin=20 #If this projectile is a homing projectile, this controls how fast it will turn. Degrees per second. TurnRate=0.5 #If this is greater than zero, then it will explode on impact with this damage radius. ExplosionRadius=0 #This controls the accuracy of the shots. 0.0 = precise. 1.0 = totally random. Scatter=0.05 #This is how fast the weapon can fire. Higher=slower. RefireRate=2 #The sound effect when fired. Sound=laser_med #How much damage is inflicted on impact. Damage=3 #How long the projectile will live. No effect on beams. Lifespan=2000 #How long it takes for the glowing to fade after the projectile expires. (Important for beams.) Fadeout=500 #How often (milliseconds) to emit sparks. CAREFUL! Low values can create insane numbers of FPS-killing particles. 0 to disable. SparkInterval=50 #How long (milliseconds) between pressing the button and the weapon firing. (Applies only to player.) Warmup=0 #How many projectiles do we get out of a single shot? Volley=1 #If true, the weapon must be re-triggered and warmup before firing again. (Applies only to player.) OneShot=0 #How long in milliseconds does it take the weapon to become ready to fire again? (Applies only to player.) Cooldown=0 #When the projectile hits something, it can bounce off and keep going. This is how many bounces are allowed. Bounces=1 #How many little bits of rock particles you get when this projectile hits the wall. Debris=5 #The cost to buy this weapon in the store Cost=2000
This is often how I document features for the artists. I make an example and cover it in comments. I don’t know how AAA studios handle documenting systems between teams or individuals. It seems like making a document or a wiki would be more organized or professional, but this seems like it would be more convenient to use. Also, it makes the documentation available to the players if they decide to go poking around in the data files and trying to mod things.
But nothing fuels feature creep like adding new features. Once we had new guns, we came up with the idea of giving the player the option to change weapons, which led to having robots drop weapons, which led to adding stores where the player could buy weapons.
“It’s Like 2D Borderlands”
 |
This is all well and good, but the focus of the game has been dragged away from “dog-fighting and dodging incoming projectiles” to “acquire better guns”. Arvind is seriously considering adding a system to generate random guns, Borderlands-style. For the last several weeks it’s been like there’s this pervasive gravitational pull towards more Borderlands-ish ideas: The story, the foes, the weapons, the humor. Every time there’s a problem it seems like, “We could try doing things the way Borderlands does it” is the answer.
This is good, inasmuch as it’s more entertaining, but we need to be careful about making extreme changes this late in development and introducing massive new systems that will take months to tune and balance properly.
I have this writing gig, and I’d already given up hope of Good Robot seeing the light of day, so if it turns out to make money at some point that’s a bonus. But other members of the team have the more sensible position that we shouldn’t just keep hammering away at a videogame for free, forever, constantly changing the foundational mechanics, and never nailing anything down long enough to ship a game and get paid.
A lot of indie devs say things like, “If I was a millionaire, I’d make the ultimate version of [game that they love]!” But if this experience has taught me anything it’s that if we didn’t have to worry about money, we’d never ship a game at all. There’s just too many possibilities to explore.
Posted In: Games, Good Robot