Making asteroids



I’ve found a pretty excellent tutorial video on asteroid creation in blender. It’s quick and easy (although it remains to be seen as to whether all those vertexes will play nice with Unity.)

Next step, unwrapping the mesh to apply a texture so that Unity will be able to see it. I’m following along with this video, I recommend it. 


Today’s Progress: Working In-Game Chat!

As you can see from the photos, I got an (ugly but functional) in-game chat system up and running today. You can type in your username and it’ll appear next to your chat string in the chat window. In the future, this username sign in info will be stored on some database when you sign up. I also ported over the networking code to C# and commented it out for future reference. Once I fully grasp it, I can bend it to my will!

Pondering Permadeath: Responding to Game Difficulty


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.

Animating Summit

As you can see from Eric’s post we’ve decided as a company to return to Drift as our main project. But I’m still interested in working on Summit as a platformer, and will continue working on it as a Send More People side project. Perhaps it’ll turn into a full game, perhaps it’ll just help me to continue fleshing out my C# skills, but for the moment it has value in being incredibly fun to work on and make strides in.

As you can see above, I’ve created a character controller and have gotten him to climb around a course. Today’s achievement was getting an animations array working, so that the animation automatically updates depending on the player status. Now comes the hard part – drawing the actual animation key frames. I’ll be spending a lot of time thinking of Eedward Muybridge in the days to come.

Oh, and I got a little hand-drawn animation working here as well. It’s hard to tell which is jankier… my hand-drawn animation or my 3d.

Return to Orbit


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…