#game development principles

We measure engagement for single player games the exact same way we do it for multiplayer games. You know how you have your PSN, XBL, or Steam account with the achievements and stuff? Do you notice how even single player games offer additional content like DLC and cosmetics? Single player games also communicate with our servers, they just do so more intermittently. It's how single player games get their live updates and new content.

Further, have you noticed that a large number of the most successful and beloved AAA single-player titles have already changed gears to be long-term open-world huge content affairs designed to be played for weeks or months? Just think about this list of extremely high-selling single player games and consider how many of them are also open world and/or long term engagement games:

GTA5

Skyrim

RDR2

Spider-Man

God of War

Witcher 3

Horizon: Zero Dawn

Ghosts of Tsushima

Cyberpunk 2077

Animal Crossing: New Horizons

Breath of the Wild

Pokemon Sword/Shield

None of these games are "beat it, enjoy it, and move on". The common thread is enticing the typical player to continue playing these games for weeks or months, and they are beloved for doing so. This has been happening for years now. It is not a recent development at all. Engagement is still the goal whether it’s a single player title or a multiplayer title.

That said, short-form finish-and-forget single player game experiences are not going to die, but they are also not worth the modern AAA development cost - not when the development cost is so high and return on investment so low compared to high-engagement games like the above list. There exists some equilibrium point where a publisher and/or game studio can afford to build short form single player game experiences that are profitable for the development cost, but those are absolutely not at the AAA production level. Lowering the budget and the sales/revenue expectations are the main path to getting sustainable short-form single player games.

This also doesn’t mean that short form single player AAA games can’t exist either, but they are basically limited to situations where they don’t have to be profitable. This is typically limited to one kind of situation - where a console manufacturer or new platform wants a system seller, so they essentially subsidize the development cost of system-selling exclusive titles like Uncharted because their goal is more system sales than it is individual title profitability. As long as the exclusive title sells enough copies and doesn’t lose too much money, it’s a success. Aside from those kind of rare situations, we’re basically beholden to the realities of development costs. Low engagement games don’t earn as much as high engagement games. That fact dictates how much we developers can afford to spend to build and market games.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

I’ve been thinking a lot about user generated content in the past year, and there’s really nothing nefarious or lazy about it. If anything, it’s more of a new set of challenges for a different kind of team than what you may have expected in the past.

Here’s the thing - AAA professionals like me usually build most of the game’s content for a large target audience. In order for us to make the most efficient use of our development resources, content designers have to build content that is aimed at the broadest spectrum of players. This generally means that we don’t have the sort of bandwidth to experiment with more creative themes or level ideas. We can’t include a kaizo-style stage in the critical path. We can’t include more than one or two kaizo stages at all, because we have to spend the majority of our time building for the major audience. But do you know who isn’t beholden to those kinds of business and production constraints? Do you know who doesn’t have to make content for everybody and can instead focus on the small niche that really enjoys that sort of stuff?

The answer to these questions is players like you. Players aren’t beholden to revenue targets, production schedules, or bug triage. Players have a lot more freedom to experiment with things than we do with the final product.

This brings me to the first core pillar of a “maker” project - the challenges for a “maker” project are different, so we need to field a different kind of team. Instead of staffing up with a lot of content and level designers to build a lot of levels, a "maker” project needs a lot more system designers, UI/UX designers, and engineers who can build the systems for the players to create the levels and content. This is a really big challenge in and of itself! Most level design tools are super duper complicated because they have to be - the designers who use those level design tools need a lot of fine tuned control in order to create extremely nuanced environments, placement of objects and AI, and so on. But players don’t have that kind of training or time to learn, and the kind of tools we have to use usually require weeks of training before people are proficient with them. This means that our main goals here are to condense all of these details into a user experience that does most of what the players will want and keep it easy and simple to pick up. User experience and user interface work is the most important thing for any user generated content element, because it’s the main factor in the percentage of players who will engage with the creation elements.

The second enormous challenge for “maker” projects is distribution. Making content isn’t very fun if nobody can find or play your work. Only a small percentage of the total player base will ever seriously engage with the creation tools; most will only ever play the game… and that’s only if they can find new things to play with. That means that the second pillar of any “maker” project is some kind of online back end system for players to upload their creations, for us to vet them for things like playability and presence of penis, and then put them up for distribution among other players who might want to play them. Players need a way to find levels or content to play. Maybe that’s through a robust search feature, keyword tagging for levels (e.g. “kaizo”, “automatic”, “traditional”, “water”, “weird”, “boot”, etc.), favorite creators (with a subscription or RSS style list for their latest uploads), player ratings for creators and content, featured content, and so on. These are not trivial issues by any means - they’re quite substantial technical challenges! We need a substantial back end to store and distribute the game data and we need a significant investment in the UI/UX of the system so that players can find the content they want out of all of the stuff that’s available. It’s an entirely different set of design and technical challenges from building an ordinary platformer.

The primary goal of the “maker” project is to create a self-contained ecosystem of players and creators that can build interesting types of content that is a little too weird or different for us to include in a mainline release. We usually also get to add additional content to the pool over time for post-launch support (as well as our own professionally-designed levels to showcase ways to use that new content). Overall the paradigm lets us get a better return on development resources in terms of player engagement by empowering the players to make the sort of content that we can’t realistically spend our resources on. It really isn’t that we ran out of ideas, it’s that we wanted to try tackling a different set of challenges and have a different team makeup to do it.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Today we continue the talk about optimization in video games and the tricks involved with improving performance. What if you had a way to approximately halve the number of polygons you'd have to draw? You wouldn't need to calculate how the light hits them, you wouldn't need to draw the textures on them, and guarantee that your player would never even notice that they are gone. Wouldn't that be great? You could use less memory and have more CPU and GPU cycles for calculating things that actually matter. This is the concept of backface culling.

Today's post is about programming and problem solving. I've tried to keep it as digestible as possible, but these sorts of concepts are valuable to designers and artists in addition to engineers, because optimization is everybody's job. Poor performance will harm a game's reception more than anything else, because it affects every bit of the moment-to-moment gameplay that must be sufficient to engage the player.