What Is In a Name?

Original Author: Niklas Frykholm

Today I’d like to revisit one of the most basic questions when designing a resource system for a game engine:

How should resources refer to other resources?

It seems like a simple, almost trivial question. Yet, as we shall see, no matter what solution we choose, there are hidden pitfalls along the way.

To give some context to the question, let’s assume we have a pretty typical project setup. We’ll assume that our game project consists of a number of individual resources stored in a disk hierarchy that is checked into source control.

There are three basic ways of referring to resources that I can think of:

  • By path
  • By GUID
  • By “name”

By Path

texture = "textures/flowers/rose"

This is the most straightforward approach. To refer to a particular resource you just specify the path to that resource.

A word of warning: If you use paths as references I would recommend that you don’t accept ridiculous things such as “./././models../texturesFLOWers/////rose” even though your OS may think that is a perfectly valid path. Doing that will just lead to lots of headaches later when trying to determine if two paths refer to the same resource. Only use a canonical path format, from the root of the project, so that the path to same resource is always the same identical string (and can be hashed).

Path references run into problem when you want to rename a resource:

textures/flowers/rose -> textures/flowers/less-sweet-rose

Suddenly, all the references that used to point to the rose no longer works and your game will break.

There are two possible ways around this:

Redirects
You can do what HTML does and use a redirect.I.e., when you move rose, you put a little placeholder there that notifies anyone who is interested that this file is now called less-sweet-rose. Anyone looking for rose will know by the redirect to go looking in the new place.

There are three problems with this, first the disk gets littered with these placeholder files. Second, if you at some point in the future want to create a new resource called rose, you are out of luck, because that name is now forever occupied by the placeholder. Third, with a lot of redirects it can be hard to determine when two things refer to the same resource.

Renaming tool
You can use a renaming tool that understands all your file formats, so that when you change the path of a resource, the tool can find all the references to that path and update them to point to the new location.Such a tool can be quite complicated to write — depending on how standardized your file formats are. It can also be very slow to run, since potentially it has to parse all the files in your project to find out which other resources might refer to your resource. To get decent performance, you have to keep an up-to-date cache of the referencing information so that you don’t have to read it every time.

Another problem with this approach can occur in distributed workflows. If one user renames a resource while another creates references to it, the references will break when the changes are merged. (Note that using redirects avoids this problem.)

Both these methods require renames to be done with a tool. If you just change the file name on disk, without going through the tool, the references will break.

By GUID

The problems with renaming can be fixed by using GUIDs instead of paths. With this approach, each resource specifies a GUID that uniquely identifies it:

guid = "a54abf2e-d4a1-4f21-a0e5-8b2837b3b0e6"

And other resources refer to it by using this unique identifier:

texture = "a54abf2e-d4a1-4f21-a0e5-8b2837b3b0e6"

In the compile step, we create an index that maps from GUIDs to compiled resources that we can use to look things up by GUID.

Now files can be freely moved around on disk and the references will always be intact. There is not even a need for a special tool, everything will work automatically. But unfortunately there are still lots of bad things that can happen:

  • If a file is copied on disk, there will be two files with the same GUID, creating a conflict that needs to be resolved somehow (with a special tool?)
  • Lots of file formats that we might want to use for our resources (.png, .wav, .mp4, etc) don’t have any self-evident place where we can store the GUID. So the GUID must be stored in a metadata file next to the original file. This means extra files on disk and potential problems if the files are not kept in sync.
  • Referring to resources from other resources is not enough. We also need some way of referring to resources from code, and writing:
    spawn_unit("a54abf2e-d4a1-4f21-a0e5-8b2837b3b0e6")

    is not very readable.

  • If a resource is deleted on disk, the references will break. Also if someone forgets to check in all the required resources, the references will break. This will happen no matter what reference system we use, but with GUIDs, everything is worse because the references:
    texture = "a54abf2e-d4a1-4f21-a0e5-8b2837b3b0e6"

    are completely unreadable. So if/when something breaks we don’t have any clue what the user meant. Was that resource meant to be a rose, a portrait, a lolcat or something else.

In summary, the big problem is that GUIDs are unreadable and when they break there is no clue to what went wrong.

By “Name”

Perhaps we can fix the unreadability of GUIDs by using human readable names instead. So instead of a GUID we would put in the file:

name = "garden-rose"

And the reference would be:

texture = "garden-rose"

To me, this approach doesn’t have any advantages over using paths. Sure, we can move and rename files freely on disk, but if we want to change the name of the resource, we run into the same problems as we did before. Also, it is pretty confusing that a resource has a name and a file name and those can be different.

By Path and GUID?

Could we get the best of both worlds by combining a path and a GUID?

I.e., the references would look like:

texture = {
	path = "textures/flower/rose"
	guid = "a54abf2e-d4a1-4f21-a0e5-8b2837b3b0e6"
}

The GUID would make sure that file renames and moves were handled properly. The path would give us the contextual information we need if the GUID link breaks. We would also use the path to refer to resources from code.

This still has the issue with needing a metadata file to specify the GUID. Duplicate GUIDs can also be an issue.

And also, if you move a file, the paths in the references will be incorrect unless you run a tool similar to the one discussed above to update all the paths.

Conclusions

In the Bitsquid engine we refer to resources by path. Frustrating as that can be sometimes, to me it still seems like the best option. The big problem with GUIDs is that they are non-transparent and unreadable, making it much harder to fix stuff when things go wrong. This also makes file merging harder.

Using a (GUID, path) combination is attractive in some ways, but it also adds a lot of complexity to the system. I really don’t like adding complexity. I only want to do it when it is absolutely necessary. And the (GUID, path) combination doesn’t feel like a perfect solution to me. It would also require us to come up with a new scheme for handling localization and platform specific resources. Currently we do that with extensions on the file name, so a reference to textures/flowers/rose may open textures/flowers/rose.fr.dds if you are using French localization. If we switched to GUIDs we would have to come up with a new system for this.

We already have a tool (the Dependency Checker) that understands references and can handle renames by patching references. So it seems to me that the best strategy going forward is to keep using paths as references and just add caching of reference information to the tool so that it is quicker to use.

This has also been posted to The Bitsquid blog.

Analyzing free-to-play games development: the Game / Team Clock

Original Author: Raul Aliaga Diaz

Motivation

There’s currently a lot of information out there about how to approach the free-to-play business model and its implications in the Game Development Process. It becomes increasingly complicated to make sense of all this information, however: how does it apply particularly to successful games; how does knowing and doing all this prevent a game from failing, and how we can make it work on our game to succeed. In this post, I’ll explore a framework to evaluate free-to-play development execution. This framework is visualized by arranging your game’s needs and your team’s strengths on a Clock shaped chart to assess your game’s viability, opportunities and risks.

Figure 01: An Example of the Game/Team Clock.

Introduction

By taking a user centered point of view for inspiration, we can think about the questions players implicitly ask themselves at each step of their lifecycle as “users” of our game. The key to this framework is putting yourself in the position of a player of your game, and asking yourself 12 questions from that perspective:

  • What is the game about? The first step is figuring out a clear, unique, compelling way to describe a game to quickly grab players’ attention and interest.
  • Where and how do I get to know about this? There are many venues in which people can get to know new things: TV, websites, social networks, etc. This is why is so important to know where people are spending time.
  • Do I have access to any of the platforms in which is available? In an era with so many different gaming enabled devices, the platform in which a game is available shapes not only the development challenges but also the potential number of players to reach, and their expectations.
  • Do I understand and like the gameplay? Once you can play a game, you start familiarizing yourself with it and decide whether you understand, and like, the game or not. I’m stressing the difference between understanding and liking, because they’re both important when we compete for people’s leisure time.
  • Do I like the art and content? Games that look and feel nice do get noticed and hook people. This encompasses art, the story, the sounds and music, etc.
  • Does it suit my lifestyle patterns to play? Some games are enjoyable at any moment in which you have 5 minutes. Others require a heavier investment of time and scheduling, such as PC free-to-play games. But if a game fits into your gaming patterns (every other weeknight and some longer time on weekends, for example), then you’re more inclined to feel that you can commit to including the game into your busy life.
  • Is it not a burden? This is not asked right in the beginning, but it is increasingly present in the game’s interactions. Is it sending too many push notifications? Am I getting lots of prompts to pay before even trying to play? Is the game getting too frustrating? etc.
  • Do I want to keep playing this game? After the initial glow of the game and once you understand and like what it is about, does it make sense to continue playing? Are you getting somewhere? Is there a meaningful goal to achieve? In other words: Are you getting increasingly better engagement?
  • Do other cool people or friends of mine play it too? To play is inherently social, and it’s very rewarding to know when your friends enjoy the games you like too, or when you get to interact with other people based solely on the experiences a game enables.
  • Do I take joy in identifying myself as a player of this? This element is subtle. Are you grateful for the good times the game has given you? Do you tell (and encourage!) other people to play this game? Do you start thinking about why you like it and is it becoming a little piece of your current identity? This is a way to essentially figure out whether your game’s brand is resonating with the player or not.
  • Does this game have clear value for me? Next to identifying yourself as a player of a game, this must offer a clear value for you as a player. It’s the cherry on top of making the game part of your lifestyle. The game gives you something beyond fun. It’s a hobby, it reminds you of your childhood, you have enjoyed it so much that you want to see more of it and seek ways to support it, you tell other people that you play this game for a reason that is crystal clear for you.
  • Is it worth paying for this? After all this, having an answer for all the previous questions, you consider the trade off: Is it valuable for you to pay in the game for the things it has to offer you?

This is roughly the path of questions people implicitly ask and answer to themselves from first learning about a game to then deciding to pay for it.

This is radically different from non-free-to-play games in which the questions from 4 to 11 have to be answered before playing to whole game at length. This made the game development process so distant from people’s feedback that studios usually needed to rely on expensive focus groups, risky leaps of faith and existing brands or IPs.

Moreover, given the platform choice for some games, like in console games, many questions were rendered unnecessary to address because the platform comes with a set of expectations and assumptions. For example: you expect on the latest consoles to have things such as highly-polished graphics and long experiences to justify spending $60 on them.

These questions can be mapped to concerns you need to take care of when developing and launching a game:

Figure 02: Questions and their areas of concern.

Let’s adventure some definitions for each one of these concerns:

  • Unique Value Proposition: It’s the short, clear, attractive, unique description that permeates your whole game.
  • Visibility: The aggregated set of outlets in which people can find out about your Unique Value Proposition, visible where they spend time.
  • Platform: The place/device where people play your game.
  • Gameplay: The core experience of your game and its evolution.
  • Content: The elements that shape your game’s core experience and enable people to perceive it through their senses.
  • Lifestyle affordance: The way all previous elements fit on the (ever diminishing) leisure time of people’s busy, constrained lives.
  • UX Affordance: The way all previous elements not only fit, but are made more accessible, convenient, and affordable.
  • Meta Gameplay: The motivation for the longer run.
  • Community: The social aspects of your game and the part of the experience that happens largely outside your game application.
  • Identification: The positive encapsulation of all previous elements for each player.
  • Value accessibility: The clear realization of the reasons why YOU play THIS game (and not others).
  • Monetization: Whether you’re willing to pay for the previous reasons or not.

Additionally, we can map each of these topics to key areas of the Team’s Expertise, and which areas carry the biggest effort on each topic (note: your mileage may vary):

Figure 03: Concerns and their key driver Expertise.

You start with a strategy to make a game, coming either from business or creative inspirations, and then you make sure Marketing puts the game on people’s minds, making them come together to play a game designed and developed by tech, art and design teams, with additional effort contributed by teams including Product, UX, Live Operations, Community Management and Analytics to operate the game as a service (even if a light one), to finally encompass this pursuit as a Business.

Of course, for each team, considering your proper definitions of the 12 topics and your particular game, the matching can be different, and all the Teams areas of Expertise are involved to different degrees on each Player Concern:

Figure 04: Player Concern / Team Expertise Relationship Matrix.

Entering: The Game/Team Clock

Now, we can map these Player Concerns and Team Expertise areas to regions on a clock for better visualization:

Figure 05: The Game Clock.

For your particular game, each “hour” will demand more or less effort to make it successful. Conversely, depending on the particular shape of your team, you can score competence and expertise in lesser or higher degrees on each of these Concerns. The key is to be conscious about your game’s requirements for success, to be honest about your team’s execution reality, and to make a match between your game and your team, that has the lowest possible gap.

We can even place the game companies that focus on each Team Expertise area on different parts of the clock as well:

Figure 06: The Team Clock and the types of teams they gather.

Successful teams play on their strengths. Since we have now plenty of platforms and the possibility of using quantifiable insights through metrics and analytics, a lot of new game companies are created focused only in the early life cycle, considering aspects such as Monetization, the Unique Value Proposition, Marketing/Distribution and the Platform considerations, usually under the assumption that the next phase is “just” the game part.

Indie Game Developers start right from the Platform, Gameplay and Content aspects before exploring the other areas, because their strength lies in the game development part, considering that the Unique Value Proposition, Visibility and Monetization will come naturally from a great game.

In the subsequent region is where we have the divergence and conflict on approaches, because from 6 to 9, we can find scaling, growing startups together with successful indie game developers. So which approach can get you there? It will depend on your particular project and how well it aligns with your team’s strengths.

No matter how much effort you put on the early part of the cycle, if your game is not good enough, it will not take off. No matter how much marketing, monetization, analytics, etc you throw at your game besides great gameplay and high quality content, you will only continue to fool yourself with hope until you run out of money. On the other hand, a unique, great polished game has no chance to survive on a small platform, if it’s complicated or a burden to play in itself, or if it’s pursuing an audience blindly without correcting it to cater better to the people that actually like the game.

In general, we tend to fixate on evaluating the approach of scaling startups or successful indies, disregarding the complementary elements that took them to 6 to 9, and hopefully on the holy path to 12. Startup founders learn all about the business elements of the ones making it, disregarding the importance of having a great game and a great team to execute. Indie developers try to emulate successful Indies that already have strong games, that have become brands of themselves, and don’t pay attention to how the successful Indie started, and which mix of factors made them successful beyond having a great game.

Finally, in the region from 9 to 12 we have the “Unicorns”, the games and their developers who are very, very successful. King’s Candy Crush, Supercell’s Clash of Clans and Hayday, and Riot’s League of Legends. Among the Indies we can consider Mojang’s Minecraft, together with Nimblebit’s Tiny Tower and their subsequent games, among others.

The way to use this framework is to assess your projects needs and your teams strengths, providing a score on each User concern and Area of expertise, to look for potential gaps.

Figure 07: Example Game/Product Needs and Team Expertise.

When we have a slightly higher competence for something required on our game, we have a competitive advantage; conversely, lacking the expertise to address needed concerns for a game or product to be successful pose Execution Risk. A considerably higher expertise over a Game/Product need is untapped potential, and a good alignment is Execution Feasibility.

Figure 08: Game/Product Needs versus Team’s Expertise comparison.

It’s important to note that even though this framework is conceived for free-to-play games, it can be extended to premium games as well, to study how to make the most of your team’s key areas of expertise, and how your work fits in the larger scope of other teams and their games. This is, for example, the reasoning to include Mojang as an example of a successful indie game developer: it doesn’t operate Minecraft as a service (not heavily at least), but it has a brand so strong that its operations can be roughly described as “Continue catering to your (large and established) audience”.

Conclusion

This framework is a practical way to ask questions about your game and your team to make the decisions that effectively contribute to your game’s success. The questions, the Player Concerns, the importance of each element may vary greatly among platforms, game genres and your team’s motivations. My hope is that this can be an effective starting point.

(Originally published at Mobile Dev Memo and my blog on June 2014).