Starting with the 1980s arcade games Galaxian and Missile Command, games and combat became nearly synonymous. This was only exacerbated in the 90s by the advent of wildly popular shooters like Doom. The choice to focus a game around antagonism, combat, and violence was not a conscious design decision, but a necessity of the industry and environment. There were abstract games that didn’t contain violence, but in general the highest-profile games were about, in essence, murder.

Doom: you shoot things. Dead simple.

Then a renaissance occurred in academia, and suddenly games were art. Nobody really knew what to do with this fact or what it meant, but it was revolutionary, and regardless of anything else, games were definitely art. To support this, a number of innovative (perhaps iconoclastic) non-violent games — games like Journey and Gone Home — were foisted up as evidence that games are art. “Games are art, they can convey aesthetics beyond violence.” Good, great. Innovative games that are fun without using violence in their designs are awesome.

Journey is one of the seminal games in the recent wave of “artistically-valuable” indie games.

However, this easily morphed into a reactionary movement. Since these games without violence or combat were touted as being somehow better or “more elevated” than your run-of-the-mill murder simulator, it became obvious that a game that was violent was inherently less.

Obviously, this sort of indiscriminate valuing of non-violent games is a terrible idea. A game that doesn’t use violence can be poorly designed and not-fun (Dear Esther, Mountain), just like a game that uses violence and combat can provoke deeper aesthetics (Hotline Miami, This War of Mine). Part of the problem is that nobody has developed the proper critical skills to analyze these non-violent, pacifistic games. Those that could view the design choices evenly and rationally are too busy climbing up their own assholes and praising the games for not using combat. On the other side, core gamers are immediately turned off by the lack of combat and write it off as boring.

Refugees have said This War of Mine accurately conveys the constant fear of living in a war-torn region.

One result of this dysfunction is the proliferation of so-called “walking simulators”. These are games whose main play involves walking around consuming either written, visual, or aural media, perhaps with light puzzle-solving mechanics (or similar accents). Many enterprising developers, whether they realize it consciously or not, have seized on the fact that making such a game guarantees some measure of success. They will be praised by academics and critics interested in furthering games as a legitimate medium, and have their game purchased by the small-but-steady audience of non-core, non-casual gamers (most of whom probably chafe at being called gamers).

Some walking simulators are great; I actually enjoyed Gone Home, in a way that I probably wouldn’t have if it had been a movie. They do a good job of immersing you in a focused, meaningful experience. Others are scattered or diluted by dissonant design decisions — like Corpse of Discovery. But nobody cares, because these games aren’t being evaluated on their merits as a game. They are either praised for being a game without combat mechanics, or they are ignored because they are a game without combat mechanics. Little else tends to go into the evaluation process.

Gone Home gives the player a meaningful experience despite being limited to looking at rooms and listening to audio.

A student game at USC, Chambara, got changed during development to be “non-violent”. The game originally saw samurai dueling in a starkly colored world. Now instead of blood, hitting an enemy produces a burst of feathers. Apparently this one tweak now qualifies it as “a transcendently beautiful and artistic entertainment game with a pacifistic outlook”. That is a direct quote from a faculty member at the school. You may see why this is troublesome to me. First of all, changing blood to feathers doesn’t change the fact that your game is about sneaking around and hitting other people with sticks before they hit you. That seems a far cry from a “pacifist outlook”. Second, this change actually hurts the game aesthetically. The blood splatters beautifully complemented the dichromatic nature of the game’s world. I consider the stark look of a blood splatter to be more artistic than a burst of feathers. Yet the game’s devs decided to make this tweak. Did they do it because it would benefit the game? No. According to the devs, “we were uncomfortable with the violence the game displayed and did not feel like it accurately reflected who we were and what we believed.” In other words, they value a game that contains bloodshed differently than a game that does not. Are they allowed to make this decision based on their personal beliefs? Absolutely. But isn’t it absurd to pretend that this tweak lends the game a “pacifist outlook”, and that it in turn allows the game to transcend to the angelic ranks of non-violent video games?

Blood splatters…

…and “feather splatters”.

I would urge critics and academics to judge pacifistic games on their merits as a game, not on their merits as a non-violent game. I would urge developers to treat the presence of combat and violence as just one among a countless sea of other design possibilities. If it aids your experience goal, you should include it and tailor it to the needs of your game as an experience. If it doesn’t don’t include it. But don’t decide to make your game non-violent or exclude combat mechanics just because it means your game will be valued as inherently better by a specific set of people.

There’s this really big problem when it comes to working on games (or really any sort of project that lies at the intersection of engineering and design). It has nothing to do with programming or design or testing or art or sound or anything else like that.

The problem is staying motivated. This is especially bad when you are working alone, but it can even happen in groups of 2 or 3 people. Beyond that, you can always find motivation in the stuff that other people are doing, because it comes from outside of your personal drive and creativity. But in small groups or solo projects, the game becomes your baby, and then you get tired of your baby.

Sometimes this happens when you work so long on one subset of features that they sort of blur together and become the totality of the project to you. You quickly get tired of this smaller sub-problem (especially tweaking and tweaking and tweaking), then get tired of the game without realizing there is other interesting work to be done.

Or maybe you realize that there is a lot of stuff to do on the project, but you’ve been working on it so long without much visible or marked improvement that you begin to despair. Maybe the project will never flower, you think. Maybe your efforts will never be used to the full extent they were designed for.

Wherever this loss of motivation comes from, there is one piece of advice I heard that really helps me. It boils down to this: if you keep wishing your game was awesome, make it awesome. Add in that feature you keep thinking about, but keep putting off because there is more important framework-laying to do. Or take some time off and mess around with that one technical gimmick (shader, hardware stuff, multi-threading, proc-gen, or what have you). When you feel yourself losing motivation, give yourself permission to go off and get it back. Don’t soldier on, because your project will inevitably end up on the dump heap with all the other projects you abandoned.

The only problem is, everyone (including myself) always says that adding eye-candy and little trinkets to your project prematurely is a Bad Idea. If you make your game cool by adding eye-candy, the wisdom goes, then your game is no longer cool because of the gameplay (you know, the point of a game). Arguments about whether gameplay is important not-withstanding, if adding a few bits of visual indulgence saves your game from succumbing to ennui, then by all means, add the cool things!

Like this:

I haven’t posted in a while, in part because I’ve been busy with a lot of things. Maybe I’ll make posts about some of those other things at one point, but right now I just want to talk about From Light.

From Light is a game that I have had the pleasure and honor to help develop. It was originally created as a class project by two other students, but when it showed promise they decided to develop it further. Our team has now grown to 10 people, all (save one) students at USC.

The game is a 2D puzzle platformer based on long-exposure photography (holy hell have I said that line a lot). Basically, you can etch out light trails onto film using the stars in the sky, then jump on those trails to navigate the levels.

I mention that I’ve said the above line a lot because the game got accepted into the PAX 10 for PAX 2015, and I went up to Seattle last weekend with 3 other teammates to show the game off at the four-day gaming convention. This, you may have gathered, is completely and mindbogglingly awesome. I get to work on a game that is recognized and validated by real-world people! And truly, the reception of PAX was way more than I ever would have expected. People frickin’ loved the game!

And at PAX one of the things I heard again and again was that taking a game to completion, to the point where it could be shipped and sold as an actual game (y’know, for money), is an invaluable experience. Not only do you get a sellable game and a fantastic line on your resume, you also get all the experience involved in taking a game from 80% to 100%, and all the non-development business stuff involved in getting your game out to consumers. Needless to say, this convinced me that we should take From Light to completion. Before, I had been hesitant because as students it was unlikely we could put in the time to finish it fully. However, I am now willing to work harder than I have ever worked before to finish this game.

I’ll continue to post either here or on Gamasutra about development (both technical and non-technical posts), so make sure to look out for that.

Like this:

Imagine you are driving a car, and you have three of your misanthropic friends in the back. Suddenly they lean forwards and ask if they can help steer. You think this might be a bad idea, but before you can react they clamber forwards and put their hands on the wheel. Most people would at this point judge the situation as “not a good idea”.

Replace your annoying friends with the Internet (uh oh), and replace the car with an indie game. Congratulations, you have just created the perfect environment for a terrible game to develop. Actually, often times the situation only gets as far as the Internet playing backseat driver, yelling out confusing and contradicting directions that are both useless and hard to ignore. But for a game like KSP, the community has leapt into the passenger seat and nearly wrested controls from the developer.

The developers of KSP are driving towards a cliff of not-fun. They could probably make a good game that stood on it’s own and appealed to a certain audience if left to their own devices. However, because the early prototypes of the game drew such a diverse crowd, the fans want the game to head in a couple of conflicting directions. Few people share a common vision for the game, and a lot of people like to play armchair game designer.

I honestly think some of the more prolific modders in the community have been taking the game in a more suitable direction. Meanwhile, the community quibbles over what should be included in the stock game and what shouldn’t. I want to take one of my biggest peeves as a case study:

One of the most touted arguments against certain large features is that the feature merely adds another level of complexity without adding any “true gameplay”. For example,

Life Support would just mean another thing to worry about, and it would reduce the amount of shenanigans you can do (stranding Kerbals on planets for years, etc).

Living Room/Sanity mechanics? Nope, it would just be a hassle. You have to bring up bigger habitats any time you want to send a mission to somewhere far away. It doesn’t add any gameplay during the mission.

Reentry heating? That just restricts craft designs, making people conform to certain designs and plan around reentry.

Different fuel types? Too complex, requires a lot of learning and planning before hand, and only restricts your options during a mission (again, restricting shenanigans).

Realistic reaction wheels that don’t provide overwhelming amounts of torque and require angular momentum to be bled off with a reaction system periodically? Could prove to be annoying during a critical part of a mission if you hit max angular momentum. Requires you to put in a reaction system even if you only want to rotate your craft (not translate).

Do you see the problem with these arguments? You are arguing that something shouldn’t be added to the game because it adds gameplay that isn’t in the game right now. See how circular and pointless the argument is? The worst part is that it could be extended to basically any part of the game that exists right now.

Electric charge? What if you run out of charge during a critical maneuver, or go behind the dark side of the planet. It’s A GAME, we shouldn’t have to worry about whether or not the craft is receiving light. Just assume they have large batteries.

Different engine types? That would add too much planning, and just limits the performance of the craft. What if I need to take off, but my thrust is too low to get off the ground? That wouldn’t be very fun.

Taking different scientific readings? That sounds like it would be pretty tedious. You shouldn’t add something that is just going to be grinding. The game doesn’t have to be realistic, just fun.

A tech tree? Why restrict players from using certain parts? What if they want to use those parts? You shouldn’t restrict parts of the game just so the player has to play to unlock them. That doesn’t accomplish anything.

Hell, why even have a game in the first place? It sounds like a lot of thinking and planning and micromanagement and grinding.

Of course, this could be considered reductio ad absurdum, but the problem is that it actually isn’t. The arguments against Life Support or different fuel types or reentry heating just don’t hold any water. Yet people hate against them, so the developers are less likely to put them in the game. Since I started with a metaphor, I’ll end with one:

The developers of KSP are driving towards a cliff because the community told them to. Fortunately, they realized it and are now putting on the brakes. In response, the community is shouting “why are you putting on the brakes? That only slows the car down!” To which I reply, “yes, yes it does.”

Like this:

In the USC Games program (which spans a number of majors and schools), we have annual process that falls under the moniker of Advanced Game Projects, or AGPs. This process involves a student-assembled and student-lead team building a game in a roughly 10 month development cycle. I’m excited that this process exists.

Bloom, an AGP from a previous year.

It starts with a pitch process in the Spring semester, currently consisting of three phases: a paper proposal, submission of a prototype, and finally a live pitch sessions with a board of judges. Games that pass successfully through the pitch process get slated for development the following year. A student lead (who presumably came up with the idea, assembled a small team for the pitch, and is generally the main driver behind the project) begins to recruit a large team and pound out pre-production design over the Summer.

In the Fall, most people on an AGP team register for the associated class, which gives time to meet and talk with mentors from the industry about the management problems that have cropped up. Because working on an AGP is a requirement of my major, there is always a pool of student talent for teams to pick up. This results in AGP teams that can range anywhere from 20 to 40 people. Needless to say, this is a huge undertaking and an incredible responsibility for the team lead.

However, by Demo Day in the Spring, the team will have (hopefully) created a relatively well-polished game, albeit generally small in scope. The games are displayed at Demo Day, and not only do students attend and sample the various AGPs, but industry professionals are present as well. So AGPs are a great opportunity for networking with professionals and finding mentors, as well as landing a big, fat, good-looking game in your portfolio.

I have an ambition to lead an AGP in my sophomore or junior year, but in the mean time I’ve hopped on board with an AGP that plans to pitch later this Spring. Being present from the start of the process and being able to talk with the team lead gives great insight. Even if the AGP doesn’t make it past the pitching process, I’ve learned a lot about do’s and dont’s of assembling and running a team, as well as formulating and developing an idea into a pitchable game.

The idea we are pitching is for a humorous single-player side-scrolling multi-character action-adventure role-playing hack-and-slash, or more basically, Castle Crashers meets Dawn of War 2. Or something.

A screenshot from our latest prototype.

The eternal struggle is a combination of scope and pushing the game in a direction that is likely to pass the pitch process. You see, certain types of games tend to be favored; the faculty making the decision explicitly point this out. Games that focus on pushing the boundaries of technology, implement rare or radical gameplay concepts, are socially progressive, or take risks and target uncommon platforms are generally selected over games that try to put a small spin on a well-worn concept, or aim to execute a tried-and-true concept especially well.

This difficulty is compounded by an ultimate lack of direction with our current concept (at least in my mind). The takeaway is that a game concept should be centralized around a single, appealing idea. Hearing that concept should instantly spark at vivid image in your mind, and should either inspire you to work on the project or play the game. This is why iterating on an existing idea is less appealing. In addition, if you find yourself searching for material to fill out your game with, the core concept probably isn’t strong enough. The feel or driving mechanic (whatever makes your game sound good in the first place) should spawn a myriad of possible directions. Thinking hard about what to cut out of your idea is a good position to be in; thinking hard about what would be a good thing to put in is not.

Maybe this seems counter-intuitive, or vague and unhelpful. Let me give you an example by explaining one of the concepts that I might potentially develop into a pitchable AGP.

I actually described this in a previous post. Basically, the player struggles to keep their third world country afloat, and build up. I like to describe it as Banished crossed with Civilization. The player experience goal is something along the lines of “after struggling to balance a myriad of factors based on real-life, players gain a new appreciation for the difficulties faced by distant and otherwise foreign places.”

As you can see, I would be approaching the game from a social-awareness / global education standpoint. Like KSP teaches players physics, this game would teach players the difficulties of third-world politics. Of course, the game is also a technical and design challenge. Technically, building a simulation with enough fidelity that also performs well would be hard. Creating challenging AI opponents would also be interesting. Design-wise, the game needs a fun yet realistic interplay of economics, politics, and sociology, which is a design direction I doubt many AGPs have pursued. This sort of novelty would be appealing to the pitch process, I imagine.

However, my plans continue to evolve as I watch the process unfold. If all goes according to plan, I’ll pitch next year.

Like it? Share it:

Like this:

I’ve been struggling with this problem for a while now every time I sit down to start playing KSP. As you may know, I am a huge space enthusiast, and a stickler for realism when it comes to portraying space and science topics. Then, of course, I also like playing fun video games. So I’m fundamentally at war with myself when I ask myself: how much realism is enough?

The key here is not striving for realism, but making it feel realistic. This means simulating what I know, and glossing over that which I know nothing about. Yes, this is lame. Additionally, there are some things that take far too much effort to simulate realistically — engine physics, weather patterns, n-body gravitation, physiology.

This problem has been eating away at me enough that I haven’t actually been able to play KSP. I tried a variety of different play styles, but ultimately I got stuck on one problem: I wanted my rockets to be as small as possible, and to take the optimal ascent route.

As I began researching this problem, I realized it was not trivial. In fact, planning an ascent path is quite complex, and the equations have a large number of parameters. Another compounding factor was that there is really no good documentation on the internet about ascent patterns. I’m not sure if this is because that information falls under some sort of ITAR restriction, or just because nobody is interested in it. I wasn’t even sure how to start thinking about it. I knew there was something called a “pitch-over maneuver”, but how does it work? Do they pitch over at a constant rate starting at some altitude, or is a more complex function? Are there multiple pitch-over functions? I could find nothing that answered this.

The second problem was that it is not easy to simulate rocket ascents. You have to account for the curvature of the Earth, so it is not a ballistics problem but a set of differential equations in a polar coordinate system. I tried some basic solution in both Scilab (a free version of Matlab) and in Python, but in both cases the complexity of the problem became so great that I threw up my hands before reaching a satisfactory solution. I mean, it’s hard enough if you consider one stage, but once you consider that a rocket can have any number of stages, the design space spirals out of control.

This problem would not stop bothering me. Every time I sat down to play KSP, I realized I was sitting down into a self-imposed math nightmare. Then after that nightmare was solved, I would still be stuck with a inability to truly simulate all the aspects of spaceflight I wanted to simulate, at least not without a lot of work making my own mods.

The moral of the story is: you can’t trust the system. don’t mix realism/math and videogames.

(There is another corollary problem, which is that Reality Is Unrealistic. We have these notions of how phenomenon look drilled into our heads by TV and movies, but the truth is often different and less COOL. Unfortunate that we have been trained to have that heuristic for coolness. TV Tropes says it best. An interesting example is Star Citizen, which shows the ship engines as firing all the time — even when they are off in the physical simulation — because it “looks cool”. Sigh.)

Like it? Share it:

Like this:

Many have predicted the fall of the PC in favor of large-scale mobile computing with smartphones and tablets. Most people don’t need the power of a high-end laptop or desktop computer to check email and play Facebook games. Indeed, most services are now provided over the Internet, with low client computational requirements. However, we may see an abrupt reversal in this trend.

There are two factors at play that could radically change the direction of the computing market. First, some experts are now predicting doom and gloom for the “free Internet”. The post-Snowden Internet is very likely going to fragment along national lines, with each country creating its own insulated network over security concerns. Not only does this mean the US will lose its disproportionate share of Internet business (and US tech companies will see significant declines in overseas sales), but it also means the era of cloud services may be coming to a premature close. As users see the extent of NSA data mining, they may become less willing to keep all of their data with a potentially unsecured third-party. If users wish to start doing more computing offline – or at least locally – in the name of security, then desktop computers and high-power tablets may see a boost in sales.

Second, the gulf between “PCs” and “tablets” is rapidly closing; the agony over PC-mobile market shifts will soon be moot. Seeing a dip in traditional PC sales, many manufacturers have branched out, and are now creating a range of hybrid devices. These are often large tabletop-scale tablets to replace desktops, or tablets like the Surface Pro to replace laptops. I suspect the PC market will fragment, with a majority of sales going towards these PC-mobile hybrids, and a smaller percentage going towards specialty desktops for high-power gaming and industry work (think CAD and coding).

I doubt desktop computers will disappear. In 10 years, the average household might have a large tablet set in a holder on a desk and connected to a mouse and keyboard, or laid flat on a coffee table. It would be used for playing intensive computer games, or the entire family could gather round and watch videos. In addition to this big tablet-computer, each person would have one or two “mobile” devices: a smallish smartphone, and a medium tablet with a keyboard attachment that could turn it into laptop-mode. Some people may opt for a large-screen phone and forgo the tablet.

It’s hard to tell whether or not the revelations about national spying will significantly impact the civilian net (the same goes for the fall of net neutrality). On the one hand, people are concerned about the security of their data. However, being able to access data from any device without physically carrying it around has proved to be a massive game-changer for business and society in general. We may be past the point-of-no-return when it comes to adopting a cloud computing framework. On the whole, transitioning from a dichotomy between “mobile devices” and “computers” to a spectrum of portability seems to be a very good thing.