Game Dev Project Management Theorycrafting: Ownership Threads

May 5, 2021 Leave a comment

There are two dimensions to feature ownership in game development: how strongly are features owned by an individual member of each discipline, and how tight is the collaborative connection between those owners in different disciplines.

It is common to sort teams into pools of talent based on their discipline. This makes sense: two artists are much more likely to be able to share work than an artist and an engineer. From a project management perspective, knowing roughly how much “engineering” work and “art” work there is, measured against the number of “engineers” and “artists”, gives a good first approximation of how much time it will take to finish all the work for the game.

However, to a second approximation, interchanging tasks between members of a discipline carries a penalty, either in time or quality or both. One engineer may be more familiar with the game’s animation systems, while another is more familiar with the physics system. One artist may be faster at environmental modeling, while another is faster at prop modeling. This can be captured as “Ownership Strength”, the first dimension of feature ownership.

In a project with strong ownership, it is highly advantageous to silo your developers; that is, the engineer who works with the animation systems gets assigned all the animation-related tasks, and none of the physics-related tasks. In a project with weak ownership, each developer is able to take on any task within their discipline. Typically, strong ownership carries an efficiency bonus (devs get really good at working within their silo) at the risk of introducing bottlenecks (the game requires much more animation-related work than physics-related work, causing an uneven work distribution).

Each feature in a game requires some amount of work from each discipline. Artists, designers, sound designers, animators, and engineers all must collaborate to get a given part of the game to a shippable state. There are two broad strategies to managing this collaborative aspect. The first, as previously mentioned, is to sort devs into discipline-based pools, or “teams”. The second is to sort devs into feature-related “pods”, in which developers of all disciplines who work on a particular feature are treated as an organizational unit. This strategic spectrum can be described by the second dimension of feature ownership, “Collaborative Tightness”.

In a project with loose collaboration, an artist that asks for engineering support will create a ticket that is passed to the engineering team, which is subsequently assigned to an engineer, who will perform the indicated work and then send that ticket back to the art team. In a project with strong collaboration, an artist will work closely with an engineer, rapidly iterating and trading ideas, asking directly for support until the feature reaches the desired quality threshold.

Strong collaboration not only leads to higher quality features, but also stronger team morale due to a higher sense of teamwork and feature ownership. However, it comes at the cost of degrading the benefits of sorting developers into discipline-based teams. When small, agile, cross-discipline teams work iteratively and collaborate closely, it can be difficult to capture the work involved and effectively create a projection of how long it will take to finish all the work for the game.

That is, as long as we are using standard project management paradigms.

It is clear (to me, at least), that tending towards both Strong Ownership and Tight Collaboration is a recipe for a high-quality game. The only downsides are the risk of bottlenecking and the difficulty of predicting work schedules. These downsides are simply failures of the traditional game dev project management framework.

Starting with the first principles of supporting a Strong Ownership / Tight Collaboration development environment, let’s craft the ideal project management framework. This framework should ensure that the project meets internal and external milestones, is predictable in development time and cost, and meets the desired quality bar across all aspects of the game.

Strong Ownership is most effective when it grows naturally within a discipline. This accounts for natural collaboration between a group of artists, a group of engineers, etc. that leads to better problem solving and technical skill growth. Top-down assignment of feature ownership is a recipe for disaster. At the start of development, the Lead of each discipline should be considered the owner of all game aspects. As needed, the Lead can assign out ownership to specific team members, and similarly ownership can be passed between team members as needed.

As distinct aspects of the game become obvious and individuals begin gaining ownership over them, Tight Collaboration can be encouraged. In cases where it makes sense, an individual from each discipline can become the owner/liaison for that feature. For example, an artist has a single engineer, a single animator, and a single sound designer to talk to regarding a particular feature in the game. This group of inter-discipline collaborators can be called a “Thread”. Each person in the thread is responsible for getting the feature to the desired quality bar and estimating the required time to do so.

As development continues, more and more Threads will form, until there are very few aspects of the game that aren’t Strongly Owned by individuals. 

In many cases, there will be more work to do on a feature than can be done by a single person. Multiple members of a discipline can support the same Thread, either as primary owners or “secondaries” (in fact, having a secondary for each Thread would help reduce the “bus factor”). Tasks should be more-or-less assignable to any primary or secondary in a Thread; e.g., any art-related task can be assigned to any artist associated with the Thread. If too much specialization occurs within a Thread, it is time to split the Thread to form 2 or more new Threads. 

By polling each Thread, a project manager can quickly gain an understanding of how much work is required to bring each aspect of the game up to a given quality bar. For each person, the work from all of their Threads can be summed up and compared to find team members who are bottlenecks. The Lead of a discipline may re-assign ownership of Threads as needed in order to reduce bottlenecking to a minimum. High-level feature prioritization converts into Thread prioritization, which easily converts into task prioritization in whatever project management software is being used.

Within this framework, achieving a first approximation of the amount of “art” or “engineering” work is still completely possible. But a second approximation is much easier to get and much closer to the reality of feature development. We have unified team member management, schedule management, and feature quality management into a single theoretical framework.

Allowing feature designations to naturally precipitate out as Threads, rather than attempting to impose them top-down, also helps ensure the game reaches a quality bar across all features. For example, in a game where the player performs ranged and melee attacks on enemies, a project manager might think that “melee combat” and “ranged combat” are a good way to separate the different types of work. However, by allowing designations to precipitate naturally, the manager might discover the team finds it more useful to categorize work into “damage and dismemberment” and “weapon handling”. This sort of thing cannot be determined a priori, so allowing these feature designations to develop naturally via a formalized Thread framework is highly superior to imposing them top-down.

Overall, this sort of framework seems like a good compromise between a strict discipline-based team approach and a strict “feature cabal” approach, while maintaining more flexibility and accountability than either, and also boosting game quality and team morale.

Filed under Analysis, Blog, Games, Idea Tagged with , , ,

Will Half-Life: Alyx Set VR Back?

April 4, 2021 Leave a comment

Half-Life: Alyx poses a conundrum for the future of VR. On the one hand, it is praised as one of the best VR games yet. It is critically acclaimed and immensely popular, bringing a best-of-class experience to countless enthusiasts and VR-newbies alike. Yet, as some (disgruntled) people have pointed out, it hardly seems like the game is native to VR. Little in the game requires VR to be playable. The environmental exploration and the gunplay, arguably the core loop of the game, could be turned into a paint-by-numbers flat FPS.

How can we reconcile this paradox? If VR is truly a medium that can upheave and uplift interactive entertainment, how can its poster child be a simple shadow of a regular flat gaming experience? Will every VR game just be a watered-down pancake game with a small garnish of VR laid on top?

Previously, I posed two questions for determining if a game belongs in VR:

  1. Would I rather play this game in VR, or on a flat screen?
  2. If this game wasn’t in VR, would I choose to play it instead of another flat game?

The answer to the second question is almost certainly “No”. Flat games have had decades to refine their metaphors and mechanics; a game that has been shaped to fit in VR will inevitably lose out to non-VR games in their home territory.

So if the second question is answered “No”, the answer to the first question better be “Yes”. But it’s tricky to get a “Yes”. If you play VR games, you have likely felt frustration or boredom and wished that you weren’t wearing an uncomfortable headset and could instead snuggle on your couch and play on the TV using a gamepad.

But perhaps surprisingly, the answer is “Yes” for Half-Life: Alyx. Of course it’s subjective, but it seems that most people (myself included) are eager to strap on a headset in order to dive into that immersive world. What other games make you eager to throw on the headset? Only a handful. Beat Saber’s continuing popularity is in part due to the fact that user’s are willing to jump into the headset just to play a few rounds of Beat Saber.

There is no one answer to why Alyx succeeds where so many fail. Polished audiovisuals; excellent pacing in visuals and spatial design; finely-tuned tension in combat encounters; compelling characters, dialogue, and worldbuilding. The game keeps you present and immersed in the virtual world, and that is the value of the game. Conversely, the game’s core loop is sufficient, but not spectacular. You come for the virtual adventure, and the core loop keeps you from being bored.

Previously, I posited that a VR game can succeed only if it stands out on at least 1 of 3 pillars:

  • Kinesthetically pleasing core loop
  • Compelling character
  • Fantasy fulfillment

Alyx certainly succeeds at having compelling character. The worldbuilding, environments, characters, dialogue, and humor are all engaging. For fantasy fulfillment, the game leverages its distinguished IP, drawing you back into a universe that has been in our collective consciousness for nearly two decades, growing to near-mythic proportions.

And yes, its core loop has kinesthetically-pleasing elements. The tuning on the gravity pull is just right, making it a simple joy to fling objects towards your hand. The stress of reloading the pistol during a tense fight is exhilarating, when in other VR games it can be frustrating. Jabbing a syringe into yourself to heal while in cover makes you feel like an incredible badass.

It’s no wonder Alyx succeeded. It executes expertly on all the things that people seek in games, and VR games in particular.

And yet.

Mechanically speaking, the actions you do in the headset are things that can translate to non-VR. Point at a thing, pick it up. Reload a gun. Climb a ladder. Push joystick to walk. Point a gun, shoot. Crouch behind cover.

Compare to the acrobatic gun-fu of SUPERHOT, where you can dodge or block individual bullets, or the savage skull-bashing of GORN. Compare to the rhythmic, full-body synthesis of Beat Saber and Pistol Whip, or the graceful low-gravity navigation of Lone Echo.

Previously, I said that the promise of VR is one of hyperreality, a world that is better than reality: denser, more exciting, more enabling, less annoying. 

Half-Life: Alyx is hyperreal. But its delicate tuning is a brute strength solution to the problem. It isn’t through new clever design paradigms that Alyx captures the hearts and minds of VR gamers, but by relentlessly polishing a mediocre foundation. It is a triumph of budget, not a triumph of innovation.

And accordingly, history will not remember the game for its design. The other games mentioned above will accord a place in history as innovative pioneers, similar to how Spacewar, Pong, and Pacman are still fun to a modern gamer. But in 10 years, Alyx will hold little appeal for VR gamers. Game development tools will advance, decreasing the cost of fidelity. Its audiovisual polish will become less impressive. Correspondingly, its laggard design sensibilities will become more grating.

***

The sad truth is that there is an inverse relationship between design innovation and the overall scope of a game. When following well-worn paths, a development team can spend their energy creating more content and polishing the game. 

Gamers want big, polished games. VR is young enough that the bar has not yet been raised too high in terms of design expectations; players will suffer clunky design because, for the most part, they don’t realize it could be better. 

But clunky design limits the growth of the medium, because it restricts more casual players from being drawn in by the experiences. When an uninnovative yet polished game succeeds, it lures more developers into believing that it is fine to settle for less when pursuing the promise of VR. Collectively, the level of expectation is dragged down. The raising of the bar is stunted. And the longer the bar stays low, the longer new casual users are being exposed to an imperfect incarnation of hyperreality.

So Half-Life: Alyx makes me happy and sad. It is a triumph that gives visibility to the medium and may attract new users in the short run. But it is a mediocre vision of what VR could and should be like in the future. It is sufficiently hyperreal in today’s marketplace, but it accomplishes this with brute strength, not with cleverness. And in doing so, it threatens to set the medium back in the long term.

Filed under Analysis, Blog, Games, VR Tagged with , , , ,

Real-time Strategy in VR

February 22, 2020 Leave a comment

Real-time strategy is the genre that’s possibly been knocked hardest by the evolution of modern gaming. Interest in games like Starcraft have waned in favor of action games and MOBAs. There are two competing explanations for this: either the modern market isn’t big enough to support an RTS ecosystem, or the developers of real-time strategy games have failed to innovate and keep up with the times. In either case, it is undeniable that the RTS is a dead genre.

Or is it? Of course not! The spirit of the RTS is alive and well. The same things that hooked players back in the 90s still hook players today. Human psychology hasn’t changed. But to survive in the vast and confounding battlefield of modern gaming, the genre has had to twist, split, and adapt to fill sustainable niches. To the legions of fans forged in the heyday of the RTS, it seems as though the genre is dust and bones because the RTS is held, in the public mind, as a single monolithic conception.

The RTS suffers the same fate as Star Wars. A novel presentation in a fallow market captured the hearts and minds of many, for myriad reasons. Unfortunately, its fame necessitates its failure; the intersection of so many interests leaves nowhere to progress, creatively. Moving in any particular direction will cause some fans to lose interest. So in a sense, the RTS genre is dead, if you define the RTS genre by the specific mechanics found in Starcraft, Warcraft, and Dune. Such a precisely defined genre is a dead-man-walking.

To find the modern RTS, one must look at the aspects of play that create such a devoted fanbase. As I mentioned, these are diverse — from a quick survey of internet threads where people discuss why they love real-time strategy:

  • Building power over time
  • Introduction of mechanics over time causing increasing complexity
  • Discovery / Exploration
  • Having to choose where to invest time and resources
  • Managing multiple tasks / dividing attention
  • Single-player stories
  • Challenging yourself
  • Directing troops
  • Base building
  • Devising strategies offline and then implementing them ingame
  • Improvising when a plan falls apart
  • Defeating an equally-matched human opponent
  • Analysing your own mistakes and better learning the specifics of the game to improve

There are some high-level generalizations about player experience to draw from these. I think the attractions of a traditional RTS can be reduced to the following:

  • Fantasy of Command / Warfare
  • Struggling to acquire and subsequently manage streams of information (in real time)
  • Efficiently growing a base, set of units, and pool of resources (in real time)
  • Overcoming opponents by building and manipulating a superior mental model of the game dynamics (in real time) [“dynamics” in the sense of the MDA framework]

Note that I have appended “(in real time)” because these can be fulfilled by a number of turn-based strategy and tactics games, just not with a time-constrained component. Indeed, what separates the RTS from other “games of command” seems to come down to giving commands at multiple locations at the right time. Many modern games of command involve a single unit, or do not have a relentless time component (i.e. not turn-based and no pause feature). For this reason, the “Fantasy of Command” can be safely put aside for the purposes of this essay. It is fulfilled by other games and is incidental, not essential, to the genre.

We expect that modern inheritors of the RTS mantle will continue to fulfill some subset of these general player experiences. Indeed, we see Offworld Trading Company fulfills most of these, but is weak when it comes to “Fantasy of Warfare” and “Struggle to acquire information”, since the game lacks any units, and there are few mechanics that allow players to learn more about their opponent than what their opponent knows about them. Clash Royale delivers a strong experience when it comes to “Overcoming opponents through superior mental models”, but lacks virtually any information-gathering or economic growth components.

Those are the elements of the high-level player experience, the aesthetics of play. When it comes to crucial mechanics, I found this analysis compelling. The analysis essentially pinpoints 11 features that are both necessary and sufficient for calling a game an RTS:

  • Players themselves are not in control of turn progression, and there are no direct interruptions of the progression of actions within the game.
  • Not being in direct control of the pacing of game events put pressure on the player to make fast, accurate decisions based on limited information.
  • Poor decisions must be eliminated or mitigated in future attempts (that is, later in the course of a particular match or in future matches against the same or different opponents).
  • RTS train players to quickly evaluate situations to determine the best future path forward.
  • Acquisition and expenditure of stores of value
  • Array of options with which to progress
  • The player must be asked to invest limited (though not necessarily scarce) resources into progressing and expanding, capitalizing on their past actions towards future goals
  • Players be able to actually lose their investments
  • they must defend their own investments and use them as wisely as they are able.
  • Require the player to simultaneously manage multiple game pieces or elements.
  • Uncertainty of other player’s actions to be incredibly important

As a summary:

Multiple participants engage in competitive economics, managing limited resources to expand multiple game elements in order to gain an advantage and ultimately wrest control of one or more critical systems to attain a concrete victory.

While this is useful for determining what is and isn’t an RTS, or figuring out which elements of a specific RTS are core to its being and which are secondary embellishment, it doesn’t necessarily lend itself to the sort of abstract, blue-sky thinking that you need when pushing an existing, well-loved concept into uncharted waters. You could follow its prescriptions to the letter, and find yourself with a product that fails to fit its niche or entertain its users.

Real Time Strategy in VR

Plenty of developers have tried to make archetypal ports of existing genres into VR. These evidence themselves as being bids for the statement “X is the Y of VR”. “Pavlov is the Counter-Strike of VR”, “Space Junkies is the Quake of VR”, “Sprint Vector is the racing game of VR”, “Beat Saber is the rhythm game of VR”.

A good rule of thumb here is to ask, “if I had the choice of playing this in VR or not in VR, would I rather play it outside of VR?” Then ask, “if I played this as a non-VR game, would I rather be playing something else?” The answer to the second question is almost always “yes”, so the answer to the first question better be “no”.

Everybody wants a VR strategy game, and plenty have been made: Tactera, Base Blitz, Airmech Command, Brass Tactics, Skyworld, Landfall, Cosmic Trip, Final Assault. (I’ve played all of them, by the way). Plenty of these come close to being an archetypal port, a true “RTS of VR.” Personally, I’m currently enjoying Final Assault.

But would I rather play these outside of VR? Absolutely. VR is uncomfortable, and these games don’t (for the most part) bring anything to the table that precludes playing them on a flat screen. No game has yet provided an RTS experience that is integral to VR.

Can we define an envelope for the “ideal” VR RTS? I will suggest two heuristics that help us towards a vision of this hypothetical game.

Heuristic 1

The perhaps less controversial heuristic is that the game shouldn’t be worse off for being in VR. By this, I mean that the game is not less player-friendly or less fun than the “pancake” version of the game you would get if you tried to port it back to traditional platforms. This applies to qualitative things like “fun”, but also concrete things like input level and game feedback. If the input scheme of the game is frictional, the player will immediately reject the game. The controls should grant the player new opportunities, not restrict their ability to act.

There is a corollary which follows logically from that first heuristic: the inputs to the game should not be able to easily be mapped to mouse and keyboard. For example, all of the aforementioned VR games — with the exception of Cosmic Trip — involve commanding troops to move around on a 2-axis battlefield. There may be height variation, but there aren’t even multiple levels. In addition, troops are commanded by selecting groups of units, then directing them to a point on the battlefield. Naturally, this is exactly how pancake RTS games work, and it becomes quickly obvious that a mouse and keyboard is much better than a pair of VR controllers for this kind of work.

But this also applies at a higher level of abstraction. It may not seem problematic if my VR RTS involves giving commands to troops at ground level by making gestures. How could that be translated easily to a mouse and keyboard setup? Well, players tend to build the most abstract mental model possible when learning a game. Unless there is a significant amount of additional unique control afforded by this gesture-based command system, there will be no difference between it and a simple top-down point-and-click command system in the player’s mental model of the game. It would be difficult to build a gesture system that affords control so unique that it couldn’t be easily replaced by a pancake GUI using a few buttons, hotkeys, sliders, or mouse gestures. But trying to imagine such a nuanced gesture-command system might lead to some interesting RTS ideas!

Heuristic 2

The first-person, gesture-based RTS as a thought experiment points to an important distinction to be made between the hypothetical “ideal RTS” and existing archetypal ports of other genres. All successful archetypal ports are currently action games. At a most basic level, the game’s fun is grounded in a certain viscerality. Arizona Sunshine isn’t about learning the game’s sandbox; it’s about being in a horror situation, about reacting to surprises and danger under loads of stress and anxiety. Sprint Vector is a game of going fast and perfecting your execution of maneuvers. You beat out opponents by performing actions more precisely, not because you’ve built a more sophisticated mental model.

Conversely, three of our four identified core player experiences of the RTS genre are dependent on the fact that the player will be trying to understand the game as thoroughly as possible (i.e. build a mental model):

  • Struggling to acquire and subsequently manage streams of information (in real time)
  • Efficiently growing a base, set of units, and pool of resources (in real time)
  • Overcoming opponents by building and manipulating a superior mental model of the game dynamics (in real time)

A good mental model will help you filter, prioritize, and categorize the information you collect. It will help you manage your resources most effectively, and it will allow you to overcome your opponents. The core fun of an RTS is the feeling of having achieved victory by being a total genius. The core fun doesn’t come from ordering troops around on a battlefield.

This leads to a second heuristic: victory in the game should be determined by whoever builds a better mental model. It should not be determined by whoever masters the controls better, or acts faster. This heuristic also ensures that one of the most egregious VR issues is avoided: frustration at the controls. It can be stated with certainty that if the player is annoyed at the controls of a game, the designer has failed. Having the player fail because they are struggling with the controls is the worst possible outcome.

Constraints For An “Ideal” VR RTS

We can take it as a given that this hypothetical game is about achieving victory. Thus, it must contain mechanics that combine to produce interesting, nuanced dynamics, since the core gameplay is the way the player uses their mental model to understand the dynamics, and subsequently determine the best way to harness the mechanics to their end. Additionally:

  1. The controls of the game cannot be something which map easily to flat gaming (mouse and keyboard, touchscreen, etc), following from Heuristic 1.
  2. It is difficult to imagine a mechanic which would work well in a pancake game, yet whose corresponding controls do not map well to mouse and keyboard (or other flat input device).
  3. Therefore, any mechanic essential to the game must be something which could not easily exist in a pancake game.

This is a tall order. It calls for something few VR games have achieved, which is a core loop and core mechanics that cannot exist outside of VR. We need, essentially, the Beat Saber of the RTS genre.

When we envision “VR native” mechanics, we must start at first principles. What does VR have at its disposal? The ability to look in all directions; locate audio sources; ability to feel presence in a space; a sense of scale; room-scale movement (the ability to crouch, jump, and walk around a space); and tracked hand controllers with haptics.

Acquiring Information

We could use the perceptive aspects of VR (looking around, binaural sound spatialization, stereo vision, haptics) to feed into the “struggle to acquire and manage information” player experience.
But we need to be careful not to violate Heuristic 2. For example, in Brass Tactics, the fact that you can’t be everywhere at once is an important gameplay element. You might think this would force players to use their mental model to choose the best place to focus their attention — a positive gameplay element. However, in reality, it means that the person who is better at moving across the table and orienting themselves using the game’s controls gains the advantage. The player who is better at using the controls is more effective.
In our ideal RTS, players must be able to quickly take in all the available information using an incredibly intuitive interface.

We should keep in mind the current limits of headsets. Resolution is very low (compared to angular size of pixels on flat displays), and focal length is fixed to a single distance. Empirically, visual acuity is reduced to between 20/32 and 20/42, depending on the anti-aliasing and supersampling settings the user employs [1]. Oculus says in its best practices document that it is most comfortable to view objects between 0.75 and 3.5 meters away, since the focal distance of the headset is about 2 meters.

Here is an image demonstrating a vergence mismatch between eyes.

Accordingly, we should place all important elements of the interface 2 meters away from the player (this minimizes the vergence-accommodation mismatch problem, illustrated in the image above). Any text (which there should be very little of, since people hate reading) needs to be big enough that someone with 20/42 vision could read it comfortably at a distance of 2 meters.

Managing Resources

As the player deals with resource management (let us generalize structures, units, and resources pools under the term “resources”), they will contend with VR’s input methods. At a low level, this is the position and rotation of their head and hands, and the buttons on their controller. The pose of the head should not be used as to not interfere with the player’s information gathering, so we are left with the controllers. Here, there are too many possibilities to enumerate.

Most of the existing VR RTS games utilize variations of the “laser pointer” input paradigm, which ultimately boils 6 degrees of freedom (DoF) into 2 dimensions (specifying a point on a planar topology). Our ideal RTS would require input along at least 3 dimensions, increasing the difficulty of mapping it to a accessible pancake and thereby increasing the likelihood of satisfying Heuristic 1.

Our input interface must also contend with Fitt’s Law. Specifically, in VR players can either do a lot of sweeping actions quickly, or they can do few precise actions slowly. If the interface requires precise actions, and increasing action frequency increases player power, then a player will become frustrated as they try to actions faster than is possible for them. However, even if the inputs involve broad movements, we would still like to avoid coupling input frequency and player power.

(As an aside, games like Starcraft contain just such a coupling. The faster and more precise your actions, the better you will do against a slower opponent of equal strategic mastery. However, this is archaic. Other modern genres have captured this “twitch” aspect. The modern RTS may safely abandon it.)

If inputs fall on the slow-yet-precise side of Fitt’s Law, they should not require fine wrist control. Many VR games use a laser pointer-style interaction, and anybody who has played these games knows that hovering over a small UI element and pressing a controller button is an exercise in futility. Besides frustrating the player, encouraging myopic focus on small interface elements means the player won’t be focusing on the larger environment around them, an experience that is one of the key selling points of VR.

Putting It Together

To recap:

  • We should avoid coupling input frequency and player power.
  • Inputs should not require fine wrist control or angular precision.
  • Inputs to the game should have 3 or more dimensions.
  • Interface elements should sit around 2 meters from the player, and not require much visual acuity to operate.
  • Players must be able to quickly absorb available information using an intuitive interface.
  • The mechanics must combine to produce interesting, nuanced dynamics.

Additional easy wins would include a focus on co-presence with other players, a component of play that involves scale (seeing big things or feeling big in VR is cool), and the option of playing the game sitting.

Side Note: Ergonomics

Many VR RTS games have poor ergonomics. Since their action takes place on a flat horizontal plane, you spend the majority of your time looking down. With the weight of the headset on the front of your head, this induces considerable neck strain over time.

Additionally, a lot of the games use some form of world-dragging to translate the player around the virtual game space. Smooth artificial locomotion causes people to stand still, which is biomechanically more tiring than moving around on your feet.

Our ideal game would have you looking straight or slightly up during the majority of the game, and would take place within a fixed volume to encourage the player to move around physically.

Specific Ideation

This section is going to be a bit of a freeform brainstorm on how to drive the design of our hypothetical game.

The geometry should be topologically 3D and exist within the player’s real space volume. Perhaps the battlefield exists as a series of nodes with links between them. Nodes would provide both resources and 3D arenas for engagements, while links could be created and destroyed over time, and have different properties (slow/fast, dangerous, etc).

In order to decouple input frequency from player power, we can implement an action budget. This might be a power meter that slowly fills up, and allows manipulation of nodes and other resources on the board. Managing and budgeting your energy would be an important meta-game. You could burn energy to push an offensive, or burn energy to defend more effectively. Having low energy would make you vulnerable. Final Assault is an example of a game that does this well.

During direct engagements, when two players are both competing for the same location on the battlefield, we must make sure to provide significant choices to players and also prevent the faster player from automatically gaining the advantage.

The majority of an attacker’s effort would be in preparing an attack. Adding a delay between finishing preparations and the actual attack would allow defenders to be alerted and turn their attention to the engagement.

Micromanagement would be penalized – it could cost energy from the action budget, and take time to be delivered to the battlefield. Sending too many commands in succession could paralyze your units.

Leveraging high-level inputs like unit formations and group composition could be effective. Having unit behavior change significantly based on group composition could allow deep strategic play and forward-thinking. For example, assigning a fighter escort to your bomber squadron could cause the bombers to focus on making headway towards their target rather then spend effort defending themselves.

This concept of purchase-then-attack could be expanded by allowing players to purchase reserve units at a discount; if you can properly judge how an engagement will play out, you can get proportionally more power onto the battlefield in the right place at the right time.

Resource income should be expandable, but not exponentially. We want to prevent “steamrolling”, and instead foster a tug-of-war dynamic. Spending time arranging your resource production in 3D space could yield some efficiencies — but ideally this requires a trained eye rather than a fast hand.

In addition, adding unit exhaustion could prevent a well-designed push from completely overrunning the opponent without giving them opportunity to counter. Making defense easier than offense means you need to continually exercise superior play in order to win. Over time, this balance should become more unstable – this prevents a complete stalemate. After many minutes of play, a single advantageous play could cascade to victory.

Perceivable situational details should influence the outcome of encounters. Things like group composition, terrain, weather, flanking, formations, and unit morale, if properly exploited, can lead to one-sided engagements.

Game conditions should change to prevent a player from establishing a totally unassailable position. For example, a changing battlefield topology would open new flanking routes or render previously vital positions redundant. This would also require players to continually adjust their personal strategy, leading to more interesting matches.

We want to encourage strategic posturing. Placement of units should be a mind-game, to some extent. Direct engagements should resolve fairly simply and quickly, discouraging micro-management and feelings of helplessness as your forces lose. There could be several discrete points during an engagement where player commands are communicated to the units – creating a rock-paper-scissors guessing game. “Is the opponent going to change his formation command, or keep it the same?”

All together, this should lead to a “dance”, where the player shifts around the space, setting commands up that will execute at some time in the near future.

Anyways, I hope this has excited some ideas in your brain. It has certainly done so for me.

Filed under Analysis, Blog, Games, VR Tagged with , , , , , , ,

What can the current VR market teach us about design?

October 4, 2019 Leave a comment

In this post:

 

Introduction

I figured I would write this post now, since it is rapidly becoming outdated. For a while now, I’ve been following the popularity of various virtual reality (VR) games. Specifically, I’m interested in the real player engagement generated by these games, for the purpose of creating a rough qualitative model which can predict a given game’s success.

What are the stakes here? Assume we want to make a profitable VR game on a (relatively lean) budget of $500,000. In order to break even, you need to sell 25,000 copies at a $30 price point. In reality, your price point is probably lower ($20 or $25), and you’ll be selling a large number of copies at a discounted price point in Steam sales. Your budget may also be higher (think 1-2 million dollars). However, we can also assume your sales figures will be roughly doubled if you release the game on PSVR, and maybe tripled if you release on Oculus Quest (big assumptions, but these are all ballpark numbers anyways).

More than 1,000 games with VR support were released on Steam in 2018. Even assuming that 80% of those are hot garbage, you need to beat about 165 other games in order to reach that 25,000 sale mark. That’s right: by the time you get to the 35th best-selling game in 2018, you are looking at games that only sold around 25,000 copies.

I will delve a little more into the specifics later, but the crux is that, in 2018, there is heavy correlation between sales and active playerbase. That is, the games that people keep playing tend to get the most sales. Therefore the pertinent question is: what can we glean from the top-played games, so that we can more reliably develop profitable VR games?

More explanation can be found at the end of this post. But, a caveat: here I’m mainly looking at Steam and assuming it is a representative sample of the market at large. Ok, let’s jump right into it.

 

What are consumers choosing?

If we take a gander at what games people are playing on Steam in a given day, you’ll find a list that looks like this:

  • Beat Saber
  • Pavlov VR
  • B&S (full title: Blade and Sorcery)
  • Rec Room
  • H3VR (full title: Hot Dogs, Horseshoes, and Hand Grenades)
  • Skyrim
  • Arizona Sunshine
  • Job Simulator
  • SUPERHOT VR
  • Onward
  • Fallout
  • GORN
  • Elven Assassin
  • The Lab
  • Zero Caliber VR
  • Space Pirate Trainer
  • STAND OUT

This is roughly ordered by player count. Beat Saber usually has between 1000 and 1500 players, Pavlov usually has about half that; Rec Room, B&S, and H3VR have a few hundred players, and the others have between 120 and 20 players.

(Rec Room and The Lab are free, so we will ignore those henceforth)

Most of these have between 200,000 and 500,000 owners on Steam. Some are lower; B&S, Elven Assassin, STAND OUT, and Zero Caliber have 40,000 – 100,000 owners. Note that you can’t multiply the owner count by the sale price to get the gross revenue, because owners include people who got it for free or at a heavy discount. However, high owner count usually means high revenue.

All of these “top-played” games landed on the top 20 best-selling list of games for 2018. Despite the low ratio of active players to total owners, the top-played list is remarkably stable. All this suggests that it isn’t freak chance that these games are on top.

There are only a few games from the top 20 best-sellers in 2018 that aren’t on this “active playerbase” list:

  • Orbus VR
  • DOOM VFR
  • Raw Data
  • Rick and Morty
  • I Expect You To Die
  • Budget Cuts
  • Sairento VR
  • Sprint Vector

These all have ownership numbers between 20,000 and 100,000 on steam, but normally 10 or fewer active players at a given time.

The ones in bold are linear singleplayer games — i.e. you play them once and you’ve gotten everything out of them — so it isn’t surprising they don’t have an active playerbase. Three of the others, OrbusVR, Raw Data, and Sairento VR, benefit from a first-movers advantage. OrbusVR is the first “VR MMO”, while Raw Data and Sairento were some of the first games with significant amounts of content and “good graphics”. This has placed them as well-known titles in the VR market, and continues to drive consumer interest despite the fact that they clearly can’t sustain player interest. I would argue that Sprint Vector also benefits from a sort of second-hand first-movers advantage, being developed by Survios, the same company behind Raw Data (and thus benefitting from higher consumer awareness).

Many of the top-played games also benefit from a first-movers advantage. Some happened to be high-quality games in a very early market: Space Pirate Trainer, Arizona Sunshine, Job Simulator, SUPERHOT. Some happened to hit a particular niche, maybe without being high-quality: STAND OUT, H3VR.

But, are there features intrinsic to these games that we can learn lessons from?

Only 40% of the top-played games have a multiplayer mode, and you would expect games with active playerbases to have multiplayer support. When you consider all the top 35 best-selling games (which, remember, you need to be in to turn a profit) only 25% have multiplayer. I used to think that a VR game needed multiplayer support, even if people didn’t tend to use it, because it added significant perceived value to the consumer. This is clearly not the case. From a numbers perspective, adding multiplayer support is currently not worth it.

I suspect that having a game with an active playerbase is healthy for sales, since it places you on the front page of the “What’s Being Experienced” chart in the Steam store. It looks like this:

As a player, this list is very appealing. It shows what games people have found to be continually fun; if I buy a game from this list, I have a higher chance of maximizing the bang for my buck.

So while VR games can and have been successful with low replayability (Moss and I Expect You To Die come to mind), creating a game that players can return to night after night significantly increases the chances of making a profit. A game that people can keep playing is also a game that people will keep talking about both online and in real life, and word-of-mouth is not to be underestimated as a force for generating sales in the VR market.

However, it is incredibly difficult to provide the sort of value that keeps a player entertained for months, especially since every player wants something different. This is where user-created content and mods are invaluable. It is no accident that the games with the biggest active playerbases are also well-known for their user-generated content and mod support: VR chat, Rec Room, Beat Saber, Pavlov VR, B&S, and Skyrim. In fact, it could be said the mods for these games are more popular than the games themselves.

If someone says “I couldn’t imagine playing this game without mods,” as is often said of those games mentioned above, it isn’t a sign of failure on the developer’s part. It is a sign that they have provided a platform that will continue to excite people and generate sales, even without further effort from the developers. It is the holy grail of VR game development: maximum engagement at minimum cost.

Thus, we have a basic template for thinking about a VR game with a chance of profitability: a mod-friendly singleplayer game that a player can jump into night after night and that makes them want to talk about their experiences.

 
 

Three Design Pillars

What keeps players coming back? What keeps them in the headset when they could be doing other things? In my estimation, all the top-played games succeed in one or more of three design categories, or pillars:

  • Kinesthetically satisfying core loop
  • Colorful and compelling atmosphere or character (henceforth “compelling character”)
  • Fantasy fulfillment

 

A kinesthetically satisfying core loop is a basic gameplay loop that, absent all else, makes you move your body in a way that feels good. The best of these have the player doing things you can imagine a kid doing by himself on a playground just because it’s fun to do. Beat Saber, B&S, GORN, Space Pirate Trainer, and SUPERHOT all get you moving in satisfying ways. There isn’t a lot of standing still, trying to point your controller at something, or fumbling with menus, or fiddling with two small objects. They have sweeping motions and encourage you to sway your body smoothly and sinuously. When describing the game to your friends, you can move your body and make sounds with your mouth to convey the experience.

Compelling character is when a character in the game, or simply the attitude of the game itself, makes you want to stay in it. Arizona Sunshine has a fun self-narrator that lends life to a game that otherwise would become a drag after half an hour. Job Simulator is silly and absurd. GORN is a masterful blending of comical and gory action that sucks players right into the universe with minimal friction.

Finally, fantasy fulfillment is the thing most players actively look for in a VR game. They want to be a Jedi, a gladiator, a marine, a wizard, a survivor of the zombie apocalypse. Whether through the story, the action, or the environment, a game with fantasy fulfillment transports the player to a different time, place, and role. Their return to the real world after a play session is a shock, and it creates a yearning to return to that place where they were something different than they are in real life.

Some VR games ride solely on their fantasy fulfillment. People harp on Skyrim VR for being a bad VR port, but it hits the top-played list because it has such rich, immersive environments. H3VR is a gun simulator with some game modes tacked on. Most successful VR games have at least partial elements of fantasy fulfillment. Even Beat Saber, a game that isn’t really *about* anything, still generates fawning comments about how it really feels like you are wielding a lightsaber.

Obviously, each of these pillars are highly personal. Different people like different characters, have different fantasies, and enjoy different motions. For example, I can’t stand the bow-and-arrow motion in VR, but I know a lot of people enjoy it — hell, the only VR “genre” more prevalent than bow-and-arrow games are shooters.

It is thus a developer’s goal to execute on a concept that squarely hits all three pillars for their target audience while still doing the other things a game needs to do to succeed, like providing a unique value proposition to the player and being easy to market. These three design pillars are necessary, but not sufficient, for success.

Does this describe your VR game?

A single-player game that fulfills a fantasy for players. Once in the headset, it immediately captures players with a kinesthetically fun core loop, and keeps them playing for its compelling character. Players want to talk about their experience in the game and play it again, exploring user-generated content and mods to play exactly what they want and how they want.

 
 

(The rest of this post is data sources and housekeeping. Feel free to skip it.)
 

Appendix

I’ve been using data from a few sources:

https://vrlfg.net/ VR LFG provides live stats from Steam for VR games.
http://steamspy.com/ SteamSpy provides historical data and ownership numbers for Steam games.
https://vrscout.com/news/steam-leak-reveals-vr-player-count/ This was a player count leak in summer of 2018.
https://store.steampowered.com/sale/2018_top_vr/ This is a list of games by “top-selling in 2018”, measured by gross revenue, sorted into buckets or “tiers” (but not ordered within a given tier).
http://gamstat.com/games/ Not relevant to this post, since I focus only on Steam stats, but GamStat provides stats on Playstation games including PSVR, currently the largest virtual reality platform.

The numbers I used in this post are mostly from May 2019, but I don’t think moving that needle backwards or forwards by 6 months would change the conclusions of this post.

To put game owner counts in perspective, at the tail end of 2018 there were roughly 2.5 million Oculus Rift headsets sold, and 1.5 million Vive headsets. There were also around 4 million PSVR headsets (thus the comment about releasing for PSVR doubling sales numbers). These PCVR numbers from Statista are corroborated by a report by NVIDIA that there are about 4 million PC headsets total out there.

[1] PCVR headset sales from Statista
[2] NVIDIA PCVR headset count confirmation
[3] PSVR headset sales

There are two major storefronts on PC — Oculus and Steam. This hampers analysis a little, because numbers from Oculus are basically impossible to come by. However, based on some other data I’ve been privy to, sales numbers on the Oculus store may be about 50% of sales on Steam. I have no idea how reliable this number is, or what the variance is, but it at least provides a starting point for ballpark estimates.

Rough player counts are possible for Steam through Steamspy, and Playstation through Gamstat, but ultimately without access to the raw data behind each of these platforms, opportunities for quantitative analysis are limited (as are my skills in that regard). However, obviously some patterns have emerged.

It seems to me that this general alignment between what people are continuing to play and what is selling well is a sign that 2018 was the first year of stability in the VR market. Games can no longer benefit easily from a first mover’s advantage, where people will buy a game simply because it fills a gap in the market.

Below are the best-selling VR games in 2018, along with ownership numbers. The games were sorted into tiers based on the sales achieved in 2018, meaning some games in lower tiers have higher owner counts than games in higher tiers, due to release date or sales pattern differences.

Platinum (Tier 1)

Game Release User Score Owners
Beat Saber 2018 [EA] 97% 563,000
Pavlov VR 2017 [EA] 89% 370,000
H3 VR 2016 [EA] 97% 297,000
Job Simulator 2016 84% 280,000
SUPERHOT VR 2017 89% 262,000
Onward 2016 [EA] 91% 256,000
Arizona Sunshine 2016 86% 249,000
Skyrim VR 2018 82% 215,000
Fallout 4 VR 2017 71% 201,000
GORN 2017 [EA] 97% 195,000
OrbusVR 2017 [EA] 81% 29,000

Gold (Tier 2)

Game Release User Score Owners
Space Pirate Trainer 2017 [prev. EA] 95% 164,000
DOOM VFR 2017 59% 119,000
Raw Data 2017 [prev. EA] 87% 97,000
Rick and Morty 2017 74% 89,000
I Expect You To Die 2017 92% 68,000
Budget Cuts 2018 73% 49,000
STAND OUT 2017 [EA] 77% 44,000
Zero Caliber VR 2018 [EA] 73% 39,000
Sairento VR 2018 [prev. EA] 90% 38,000
Sprint Vector 2018 90% 28,000

Silver (Tier 3)

Game Release User Score Owners
Audioshield 2016 82% 126,000
Serious Sam: The Last Hope 2017 85% 79,000
Blade & Sorcery 2018 86% 74,000
Fruit Ninja VR 2016 85% 69,000
Dead Effect 2 VR 2017 83% 55,000
Richie’s Plank Experience 2017 83% 45,000
Moss 2018 91% 43,000
VTOL VR 2017 94% 37,000
In Death 2018 91% 29,000
Duck Season 2017 86% 28,000
Creed 2018 82% 27,000
Talos Principle VR 2017 87% 23,000
Box VR 2017 87% 22,000
Serious Sam 3 VR 2017 89% 19,000
LA Noire 2017 62% 18,000

Filed under Analysis, Blog, Games Tagged with , , , , ,

Indiscriminately Valuing Non-Violent Games

May 1, 2016 Leave a comment

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 screenshot

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 screenshot

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. Champions of “games are art” too frequently praise the games for not using combat, rather than evaluating the game holistically and praising good design choices. On the other side, core gamers are immediately turned off by the lack of combat and write it off as boring.

This War Of Mine screenshot

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 screenshot

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

Blood splatters…


Feather 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.

Filed under Analysis, Blog, Games Tagged with , , , , , , , ,

Trapped between Eye Candy and Motivation

November 30, 2015 Leave a comment

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 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!

Filed under Blog, Games Tagged with , , , , , , , ,

From Light

September 8, 2015 Leave a comment

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.

Logo for the game.

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!

 PAX 10 Logo  Photo of us at the booth.

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.

In the meantime, if it strikes your fancy please “like” the game on Facebook, or follow us on Twitter, or just download the game from our website.

Filed under Blog, Games, Update Tagged with , , , , , ,

The Community-Driven Game

February 19, 2015 Leave a comment

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.”

Filed under Analysis, Blog, Games, Space Tagged with , , , , , , ,

Advanced Game Projects

January 30, 2015 1 Comment

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.

Filed under Blog, Games, Update Tagged with , , , , ,

The Simulation Problem

November 19, 2014 Leave a comment

(No, not 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.

The design feedback loop

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: 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.)

Filed under Blog, Space Tagged with , , , , ,

← Older posts