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!
Shaped is now free on iOS and Android
We’ve gotten a lot of experience out of making Shaped, and now, three months after release, we’ve received practically all the sales we’re likely to make through it. So here it is – play Shaped for Free in your browser or on your mobile device of choice.
Thanks for playing. Please rate the game if you enjoy it.
 |
 |
.png) |
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…
Happy Holidays from Send More People!
Nothing says holiday spirit like swag!
Progress on Level Design – e2d!
“I love you, new me. But where are your pants?”
So we’ve gotten a lot done on Summit, in the past few days.
I’m delighted that Eric made the discovery of the Unity asset, E2D. Our use of Uni2D to generate terrain was meeting with some snags – namely, that the editor crawled any time we tried to drag an object with the Uni2D script attached. For the quick generation of player terrain, E2D is much simpler. You just drag and drop nodes, and voila – a new piece of terrain in seconds. I learned how to use the software and generated the environment above in about 2 hours of work – the bare bones of a level, which I can now fill in with environmental details.
We took the animation rig from the free robot Kyle and put our new textures on it.
We also have a new model for our dude guy. At first glance he doesn’t look much better – where are his clothes? – but if you look under that pasty pale skin you might see a humanoid Mecanim rig as opposed to the one that Eric valiantly set up way back when. The benefit of this rig is that there are premade animations for it, which we hope to take in, learn from and perhaps modify to work on a 2D plane. Incidentally I recommend that Unity 3d users look into Space Robot Kyle - he comes with a great animation tutorial.
Eric has proposed that we employ something called Agile development, which is apparently all the rage (my mother, working at a software company, works using Agile). Essentially our system is to set 2-week “sprints” and break up our goals into achievable blocks. I’m down. Thinking about what I can accomplish in two weeks helps keep ambition in check. If I learned anything from my solo Ludum Dare 25 experience is that you need to keep your goals – short term at least – as simple as possible. Get too ambitious, and your interest starts flagging as you toil without any discernable success.
We’re also switching up the control scheme. More on that later.
Honestly, folks, I’ve felt very motivated about the project in the past few days. A gleam of the final result is starting to peer through.
Seriously, 2d indie developers! Check out E2D.
