Re-Debris

Hi All,

Back again after quite some time. Hope you’re doing well! As Derek can attest, over these past several months I’ve been dividing my time and attention between my job, various entrepreneurial pursuits, and now married life, with some time on the side for game dev. Aside from learning the hard way that if you don’t stick to one thing you won’t finish anything, I also finally learned that it’s not about the amount of free time I have but how I use that time, however small. I don’t expect this division of labor to change anytime soon, so I just have to increase my hustle. Hopefully, that will mean more frequent progress, updates, and videos.
If you’ve been following my YouTube channel you’ll know I’ve worked on other games, such as We Are Being Boarded, but all roads lead back to Debris. Debris is that one game idea that I just can’t seem to shake, which always seems clearest and most exciting in my mind, and which actually seems within my abilities to deliver it. Thus, as much as I’ve tried to avoid it for smaller, simpler projects, it just has to be the next game I bring to market independently (no doubt, with Derek’s help where I can steal it).
debris
However, with game dev being my 3rd lowest priority goal, I really have to rein in my ambitions for what the first, playable prototype looks like. It required a lot of soul-searching, but I’ve distilled it to the following core features:
  1. Basic astronaut animation spritesheet
  2. Basic tactical AI for NPCs
  3. Basic spaceship AI for NPCs
  4. Multiplayer (local multiplayer only…I’ll save online for another year)
  5. Ability for players to take up unique roles on a spaceship (pilot, gunner, etc)
  6. One spaceship (exterior and interior art)
  7. Spaceship-to-spaceship combat
Now, I know there’s a lot of work hidden in there but by distilling it to <10 features, I now have an achievable and short-term goal. In addition, because I had been jumping around with my game dev, I already have some code that I can reuse. I will likely have to adjust this plan as I go, so I’m trying to avoid wedding myself to unproven design ideas. Instead, I’ll let the design dictate which features are highest priority in the stack. As Todd Howard says, “Great games are played, not made.”
So, in the coming months I hope to post more blog updates, videos, and maybe even some demos for Debris. They may be brief, they may be few and far between, but they’ll always be moving forward towards the next Send More People release. Stay tuned!
Check out the last dev video HERE.
Cheers,
– Eric

Pondering Permadeath: Responding to Game Difficulty

ftl1

This blog was originally posted on Eric Daily’s personal blog, Epic Helicopter Rescue.

One of the reasons I keep playing Skyrim after hundreds of hours (and the main reason I have started so many different characters) is because of the joy I get from permadeath runs. Permadeath is where you’re given, or you give yourself, just one life to live. If you die once it’s game over. Sometimes this is built into the game while other times players impose the rule upon themselves, which is what I had to do with Skyrim. After many attempts to convince my buddy Derek that self-imposed permadeath in Skyrim was fun, he took a turn and asked me a question: Why is permadeath fun to you? “Because it increases my sense of immersion in the game’s world and I find that feeling of immersion enjoyable,” I replied confidently. His second question was harder to answer: If permadeath was enforced by the game, would it still be as enjoyable?
Good question. After some thought, I found the answer: No.

Well, usually, no. One example is FTL, a space-faring ‘rogue-like’, a genre of games centered around permadeath. As much fun as I had with that game, I found its permadeath mechanic more frustrating than fun. It’s not that I didn’t enjoy FTL, I did. I just didn’t like that there were no retries, no second lives, that death was so…permanent. I spent all this time building up my ship and crew, only to have them be extinguished in a flash mob of Mantids.

But that’s the point of permadeath, isn’t it?

Sure, but playing under the threat of permanent death wasn’t as fulfilling in FTL as it was in Skyrim because I lacked control over my fate. I find permadeath in Skyrim more enjoyable because Skyrim is a totally open-world where, literally, each step and misstep was my own. If I chose to safely hang out in town or venture into the dangerous night, that was my choice. If I was killed deep in a bandit’s hideout or from idly walking off of a cliff, it was my own damn fault. I admit that most of the times I died in FTL were due to my own arrogance or impatience, the same reasons I often died in Skyrim. Yet, many of my deaths inFTL simply due to the fact that the pursuing Rebel fleet forced me to keep jumping to unknown sectors with dangers impossible to avoid or prepare for. In other words, FTL forced my hand. It pushed me off the cliff.

Skyrim, on the other hand, was not designed with permadeath in mind and thus all the premature deaths that came my way were the direct result of my choices. I understood how the world was set up, all the systems and dangers at play, and I could choose whether or not, and how, to engage or avoid them. It’s not just about gaining control over those systems, though, as that would seem to suggest that I should develop an overpowered character that no enemy could kill. You still want there to be a challenge because otherwise those choices are rendered meaningless. I usually loathe power-fantasy games for this very reason. In fact, very few of my Skyrim characters are over level 20 simply because I get too powerful, become bored, and start over. So it’s not about power, it’s not about controlling fate, it’s about controlling risk.

The difference, I concluded, between a fun in-game death and a frustrating one is the difference between victims and volunteers. In my college years, I wrote an ethnography on the straight-edge hardcore scene. Based on my interviews, it was clear that people who ‘claim the edge’, that is they don’t use mind-altering substances like beer or drugs, largely do so because they don’t want to hurt anybody. Odd then, that the straightedge hardcore community’s most cherished ritual, the hardcore music concert, features some of the most aggressive dance moves (read: mosh pits) in the world. They’re proud of their wounds and it bonds them together. Why was violence in one setting bad, but in another perfectly acceptable?

People getting hurt from inebriated dolts are victims while those getting hurt at shows are volunteers. If you were reclining on the grass while at a show for some mellow band and someone kicks you in the face you are going to be upset. You weren’t expecting physical harm in this environment. You’re thus a victim. At a hardcore punk show, however, you know full well that standing near the pit is likely going to end up with a shoe to the face. People volunteer for the risk and thus do not mind, in fact they seem to enjoy, any damage that results. Battle scars and all that. It’s the same thing for self-imposed permadeath. If I chose to keep pushing deeper into that dungeon and ended up dying, it was because I volunteered for that death every step of the way. No mechanic forced me deeper into that dungeon. I could have turned back any time I wanted. With FTL, you’re being prodded along, closer to the mosh pit, and have no chance to turn back. Robbed of the choice at every step, I end up a victim rather than just a greedy, foolish volunteer.

Now, if I may pass the blunt and move on from theory to more practical applications. How does this victims and volunteers paradigm translate into game design principles? I’ll give you an example from my own game development project. While Drift is not a permadeath game, death of the player or destruction of their ship will set them back to the last visited space station—a sufficiently severe penalty. We knew we wanted to have this three dimensional grid of instances where each cell held the chance for an encounter with some player or other danger. For the sake of production scale, we toyed with the idea that this universe was randomly generated; each cell would possess a random chance of encounter a weak or difficult opponent. So, for example, a cargo delivery mission from one station to another could have its difficulty measured by how many cells the player would have to travel through. The more cells, the higher the risk of attack by pirates.

That’s a cool idea, but I realized that without modification it is simply too much like FTL. Players would jump into a space with zero predictive capabilities as to the outcome. There is some fun in that unknown feeling to be sure, but it also could cause great frustration if the players’ most cherished ship ended up destroyed. Instead, we moved to system where the 3D grid of space held pre-authored zones of risk, that is, we tell each cell how risky it is. Ideally, this will be aggregated with real-world  statistics from online player encounters later on to produce an up-to-date heatmap. This means that players can look at the heatmap of the universe and plot a circuitous course through the safest cells, thereby granting them control over the risks they’ll face. If they want to take a shortcut through highly dangerous space and end up being pwned, at least that choice was theirs. There is no encroaching rebel fleet forcing them in a particular direction.

In the end, we decided to use a combination of both systems. There is a particular kind of fun to FTL-style surprises and I wanted to allow for the opportunity of some highly risky exploration of the frontiers of space. So, what we have settled on for now is a central, nebulous grid of ‘Charted Space,’ where the dangers of each sector are public knowledge. This is surrounded by the frontier zones of ‘Uncharted Space,’ where the level of danger in each cell is unknown. You could travel in a single direction for as long as you want and find nothing, or you could happen upon a pirate haven or lucrative shipwreck. This opens up the game for various types of systems and in the end makes the most sense from a gameplay and production standpoint.

If permadeath has taught me anything, it’s that you don’t need to force players to the cliff for the thrill of standing on the edge. The response by so many game developers to counteract enemy difficulty with player power is, I think, a misguided one. While many gamers enjoy being an immortal badass with a huge gun cutting a massive swath through the hordes of enemies, that is getting ridiculously played out. It’s boring and lazy. As anyone who has stood at the edge of a great height can tell you, there’s always that thought of, “What if I jumped?” If you then fall down due to lack of a tutorial on gravity or from some inescapable mechanic, you’re a victim. That’s no fun. If you’re falling with a parachute, the risk of falling is a non-issue, so that isn’t fun either. Voluntarily skirting the edge, however, embodies the fundamental purpose of play, to test the limits. When you’re truly playing the outcome doesn’t determine whether or not you’ve had fun. Gravity will reward your greed and you will die laughing.

Return to Orbit

replacement

Like ocean tides that recede yet inevitably return, Drift, our overly ambitious multiplayer space adventure, has once more drifted back into our weekend dev sessions. Poor poetics aside, it has been an interesting and often frustrating experience watching this phenomenon play out. Derek aptly described this as being attracted to “whatever is the brightest light.” We seemed to be in an oblong orbit around the star called Drift. We get pulled in by our passion so closely we get burned out. Then we are slingshotted away to explore another, smaller planetary body (read: game project) for which our passion burns a bit less brightly. The gravitational attraction of our super ambitious multiplayer space adventure game is the same force that repels us. The question is, how do we orbit around one project long enough to finish it?

If you flex a rubber band enough times, eventually it becomes brittle and breaks. Jumping from project to project is like that. We have both felt that friction, the increasing discouragement, and it has often made us rethink our decision to make games for a living, rather than as just a hobby. Have you ever tried jumping back into old code? Sucks. Now imagine doing that every few months and you can imagine our demoralization and frustration. A malaise had hung over us for a few months and we were getting impatient. We faced a choice: A) shift to a purely hobbyist approach to game development, or B) figure out how to shift our trajectory to a far more sustainable orbit. While neither of us wanted to ditch Send More People, it was hard to see it as the reasonable next step towards an actual future in the gaming industry.

Coincidentally, it was about that time that I randomly decided it was time to finally figure out what the hell ‘Agile’ and ‘Scrum’ were all about. Turns out, they both combine to form a pretty damn good cure to our indie game dev woes. By breaking up our game dreams into small, strongly prioritized chunks, and then tackling the development of those chunks in two-week ‘sprints,’ we are able to hold back the overwhelming wave of “How the hell are we going to implement all that?”

Instead, starting with the absolute-most-boiled-down core of our game idea, we focus on small, short term projects, each one building a layer upon the layer that came before it. It’s like building an onion from the inside out. At the end of every sprint, we have, for all intents and purposes, a finished onion. How big that onion gets in the end is always ‘to be determined’ and at any point in the game’s…err, onion’s development it is ready for consumption.

Todd Howard says, “Great games are played, not made.” By having a ‘finished’ game every two weeks, it’s always playable. This is great when it comes to play-testing, as it allows us to design as we go, finding out what works, what doesn’t, and what needs to be next. Because it is prioritized, we can change course if we need to without nullifying all the months of work that came before it.

In addition, the satisfaction of completion, which is what draws us away from Drift toward smaller projects, is felt on a bi-weekly basis, as each new layer of functionality is implemented. That itch is scratched. That release serves to keep us confident and encouraged. It keeps the ball rolling.

Lastly, and perhaps most importantly for indies deving on separate coasts in their rare spare hours, we can always just hang out and have fun in the Drift universe without feeling guilty about it. There’s always an outlet, a place to kick it, without feeling like you’re not doing ‘work.’ As Notch says, if you find that you’re losing yourself in your game for an hour or more then the game is fun. So you should probably check that is…frequently. In the end, entire development process is far more enjoyable and effective, and thus our passion for the project is more easily sustained.

We’re only in our second sprint right now, and we’re already seeing the benefits of this new methodology. Our orbit is starting to equalize. While we’ll still flirt with smaller satellites, like Summit, it is finally looking like Drift is going to get the attention and execution it deserves.  Wish us luck!

 

Now to go work on my poetry skills…

Humble beginnings of the Frame-Slot system

Hey All,

Eric here. I’m going to give a glimpse at the humble beginnings of our new building system. So, my goal today was to get a rough prototype up and running for the Frame-Slot system. I just wanted to prove to myself and Derek that it worked. So I made a simple Frame and a placeholder Module. In the empty spaces of the Frame, I have trigger colliders called Slots that look for things tagged as “Module.” When the Frame’s Slots detect a Module, they activate a function on the Module’s script. This function makes the Module assume the position and rotation of the Slot, ditches the Module’s rigidbody, and parents itself to the Frame. It is rough and jerky at this point, but we can make the transition smoother in the future. I then made sure that it worked on all 6 sides of the Frame, which it did. When I attached the current Satellite Dish mesh to the Module, it snapped into place just as easily. This was rad because it confirmed, to me at least, that this was the right building system for Drift.

This slideshow requires JavaScript.

In the end, Derek and I will make various different types of Frames, which can be used on their own or snapped together with other Frames to form interesting ship structures, and then these Frames will be filled in with even more varieties of Modules. Each Module type will have a different look and function. So, for example, one Module could be a window, another an exit & entrance hatch, another is an oxygen generator, and some just may be different types of walls. By placing these Modules where you want on the Frames, players can create a ship that suits them aesthetically and serves their purposes functionally. Because Frames can be combined with other Frames, players who started with a small dinky craft can build up into a massive starship or space station.

Now that we know ‘it works,’ Derek is going to work on designing Modules and Frames. I’m going to continue polishing up the system and adding some gameplay and visual tweaks to make it feel just right.

Stay tuned!

On the verge of something awesome…

So to create the newly re-envisioned Drift, I have had to create a tool that will allow us to make a solid 2D game in Unity. Derek and I are pretty excited about it. I don’t want to go into specifics as to what the tool is until all its aspects/kinks are worked out but I promise that, once said tool is done, it will be available on the Unity Asset Store for you all to download and use in your own projects. I will reveal more information once I have some pretty pictures to show alongside it. Stay tuned friends!

– Eric