Category: News

An important part of any template or prefab system is that if you make changes to a prefab, those changes are automatically reflected to all placed instances of that prefab. Prefab systems let you start building levels with placeholder entities and then later update the template with the real graphics.

Advanced prefab systems can support mixing and matching templates in various ways. For example, maybe you can create an “advanced enemy” template which is identical to the “basic enemy” template, except it is tinted red and has 50 % more hitpoints. Changes made to the basic enemy would automatically carry over to the advanced enemy and its instances. For example, if you changed the hit points of the basic enemy to 100, all the instances of the advanced enemy would get 150 hitpoints.

Or, you might be able to create a house template with windows and doors and then, in one placed house instance, swap the default wooden door for a brass one. If you later changed the windows of the template, this instance would get the new windows but keep its brass door.

In The Machinery, we call our templates prototypes and in this blog post, I’ll describe how our prototype system works and try to explain why we made the choices we did.

The trouble with templates

Designing a template system can be difficult because it requires you to manage your data at a higher level of abstraction. The user needs a way to edit, not just the data itself, but also the rules for how that data relates to other data.

There are no fixed rules for how this should work. A template system can be anything you can dream up. The Slide Master concept in Powerpoint/Keynote and the reusable page layouts and text styles in InDesign are simple template systems, while the class or prototype hierarchy in object-oriented languages can be seen as an advanced template system.

When you design a template system for a game engine, you have a bit of a dilemma.

On the one hand, you want the template system to be as powerful as possible. “Powerful”, in this context, means that the users can express complicated data relationships and use that to automate as much of the workflow as possible.

On the other hand, you want a simple and easy-to-use UI.

There is an inherent conflict between these two goals. The more powerful the abstractions are, the harder it is to create a UI for them (other than a basic text editor).

Let’s see how this plays out in a few examples, and then we’ll look at the path we took in The Machinery.

1. Source code

The most powerful way of expressing data relationships is with code I.e. the “configuration file” is just a program, written in some general-purpose programming language, that you “run” in order to generate the data for the project.

Since the “configuration file” in this case is a program, written in a Turing-complete programming language, it can automate anything that is possible to automate.

Creating the “advanced enemy” template could look something like this (in pseudocode):

advanced_enemy = basic_enemy advanced_enemy.hitpoints *= 1.5 advanced_enemy.meshes.torso.tint = rgb(255,0,0) 

But the automation could go much further than this. We could write a function that placed lamp posts along a road. We could procedurally generate stairs based on the step width, step height, etc. Since it’s general purpose code, anything is possible.

As you can see, this approach is super powerful. The drawback is that since the data is code, only programmers will be able to edit it. And even for programmers, writing code is not the most natural way to edit visual things, such as meshes and levels.

For some applications, this can still make sense. For example, the Premake build system (which we use to build The Machinery) uses regular Lua programs as its configuration files. In this case, the lack of a UI is not a big deal, since only programmers are interested in build systems (in fact, even programmers are not that fond of them).

A way of making the data-is-code approach accessible to more users would be to use a visual scripting language, instead of a textual one, but this comes with its own set of compromises. To programmers, visual scripting tends to be more tedious than just writing code. To non-programmers, visual scripting is more complicated and less visual than a regular GUI. While it makes sense for advanced tasks, such as gameplay scripting or rendering, it’s typically not something they would want to use for the majority of their data, such as building levels.

Another drawback of this approach is that if your data is a program written in a general-purpose, Turing-complete language, you can run into things like the halting problem. I.e., you can’t reason about the data in any way without first running the code that generates it. This can be problematic if it takes long for the program to run. Or, if the program has a bug and never completes — now you have no data at all, just an empty scene, until the error is fixed.

But again, there are ways of making this approach work. For example, you could argue that Houdini is essentially a visual scripting language that you “run” in order to generate your scenes, just more high-level than your typical visual scripting language. Note that the immediate visual feedback that Houdini gives when you edit the graph is key to making it usable.

2. Markup language

The next step in expressive power below code is a “markup language”, such as CSS or HTML. Markup languages are parsed, not run, and can express complicated relationships, without being Turing-complete.

A markup language implementation of the example above might look something like this:

advanced_enemy : basic_enemy { .hitpoints = calc(base.hitpoints * 1.5) .meshes.torso.tint = (255, 0, 0) } 

I’m making up both the syntax and the object model here.

Markup languages come in many shapes with varying degrees of expressive power. For example, in the code above, I’m assuming that (similar to CSS) the language can calculate expressions such as base.hitpoints * 1.5. In a more basic language, this might not be possible, and we would instead have to set the hitpoints as a hard number:

advanced_enemy : basic_enemy { .hitpoints = 45, .meshes.torso.tint = (255, 0, 0), } 

In this case, the hitpoints wouldn’t automatically scale if we change the hitpoints of the basic_enemy — they would remain at 45 until we explicitly changed them to something else.

Markup languages have the advantage of being more limited and contained than full programming languages. This makes it easier to create some kind of UI/editor for them and since we don’t “run” the data, we don’t have to worry about “bugs” or infinite loops.

But beware, markup languages are often subject to feature creep — as time goes on, the developers add more and more useful “features” to the language until it approaches the complexity of a general-purpose programming language — just a shitty and haphazardly designed one. I’m looking at you CMAKE!

This is the code/data cycle that I’ve tweeted about before.

What kind of UI can we create for our markup language? Again it depends on the expressiveness. The more expressive the language is, the harder it is to create a sensible UI. Here’s an attempt:

Yay, we’ve made a UI… but actually, it is really just a glorified text editor. To use this UI, the user still has to know that he needs to enter the magic incantation base.hitpoints * 1.5 in the textbox. Not very user friendly and doesn’t seem like a nice way to work, even if autocomplete, syntax highlighting, and drag-and-drop could lessen the burden somewhat.

If you want a markup language to work with a UI, I think you have to carefully design it with that in mind. Otherwise, the text editor will end up being the default (as happened with both HTML and CSS).

An example of the markup language approach is the Universal Scene Descriptor format (USD). USD allows resources to be reused and remixed in lots of powerful ways. But it is hard to imagine what a UI editor for it would look like — it’s predominantly a format geared for text-editors. Nothing inherently wrong with that — but it’s not what we wanted for The Machinery.

3. “User-friendly” UI

Finally, let us imagine what a user-friendly UI might look like:

There are no magic text incantations. The hitpoints are set with a regular slider. The tint color is set with a regular color picker (sorry for my limited ability to draw one).

We have the nice UI that we want, but no way of expressing something like “50 % more hitpoints”. Also, the relationship between the advanced enemy and the basic enemy is unclear. We can’t easily see how the one affects the other.

This approach doesn’t look like it gives us enough expressive power.

In my opinion, making templates work in a graphical UI, and not just a text editor, depends on finding a good “cut”: A more limited set of features — less than what code or a markup language could do, but still powerful enough to handle most of the users’ needs — that we can put together a sensible UI for.

Prototypes in The Machinery

We had three main goals with the prototype system in The Machinery:

• The Prototype System should be a general feature of our Data Model. I.e., it should work for all the data managed in the application, not just entities.

• When working with Prototypes and Instances, you should generally be using the same UI as when working with regular objects. I.e., you should not have to drop into a text editor, a visual scripting language, or any other complicated thing.

• It should be as feature-rich as possible without compromising on the other goals.

Since our template system works on any object, we don’t use the word Prefab, instead, we call our templates Prototypes and the places where they are used Instances.

The Machinery Data Model

Our Data Model is based on Objects with Properties. Objects have property Keys that can be assigned Values. Each object has a Type and the type of the object determines which properties it has:

In addition to basic scalar property types (numbers, strings, booleans, binary blobs) we also support Subobjects, References, and Sets.

A Subobject is an object that is an object that is owned by another object. For example, the Transform Component object type has a Position subobject of type Vector3. The Position subobject has three float properties (X, Y, Z).

A Reference is a link to an object that is not owned by us. As an example, the Animation State Machine stores references to Animation Clips to play. These are references, not subobjects, because we might want to use the same animation clip in different places. An object can only have one owner, but there can be multiple references to the object.

In The Machinery, objects are referenced by their unique IDs, so a reference always points to a specific object. (Another option is to reference objects by name — this allows a reference to point to different objects depending on what “namespace” we are currently in. This looser binding has both advantages and disadvantages — more about that later.)

Sets allow us to build hierarchies of objects. For example, an Entity in The Machinery has a set of Child Entities, as well as a set of Components.

Note that we’ve made the conscious decision to only support unordered collection types (sets). The reason is that operations on sets (Add/Remove) are easy to merge whereas array operations (Reorder) are more complicated. If you want a user sorted set, you have to add an explicit Sort Order property.

At the top of the object hierarchy sits the Asset Root. This object represents the “file system” of the project. The Asset Root has a set of Asset subobjects — the individual resources that make up the project.

Implementation of the Prototype System

Prototypes are implemented with a Prototype reference and an Override bitmask. Any object in our data model can specify another object as its Prototype. The object will inherit all the properties of the Prototype unless a property is specifically overridden. The overridden bitmask keeps track of which properties have been overridden.

Sets are treated a bit differently when it comes to overrides. Instead of overriding the entire set, the instance specifies a set of objects to add to and remove from the parent set. The set of the instance is the prototype set with those modifications applied.

subobject, the instance can choose to Instantiate the parent’s subobject. What this means is that When it comes to subobjects, the instance has a third option. Instead of Adding or Removing the the instance creates its own subobject that uses the parent’s subobject as its prototype. By doing this, the Instance can override, not only the properties of the Prototype, but also the properties of any of its subobjects, or its subobjects’ subobjects.

Prototypes can be chained. A prototype may have its own prototype object, and that object may in turn have another prototype. Properties are inherited through the entire chain of prototypes.

Note that prototypes are not “special objects” in any way. Any object can act as a prototype to any other object of the same type. Because of this, we don’t really make a distinction between “Entities” and “Prefabs” in The Machinery. Any entity can be used as a prefab.

Now that we know how prototypes are implemented, let’s see how they work in the UI.

Property editor

Our main UI for editing objects is the Property Editor. The Property Editor shows the properties of an object and lets the user edit them:

The UI for the property editor is automatically generated, based on the properties of the Object Type. But note that it can still be completely customized, by providing callbacks for specific types or properties. For example, in the screenshot above, the color editor uses a custom UI.

This is what the UI for an object with a prototype looks like:

Properties that are inherited from the prototype are grayed out. If we edit those properties, they become white — indicating that they have been overridden in the instance. Right-clicking an overridden value brings up a context menu with two options:

• Reset: Remove the overridden value and reset the property to the inherited value from the prototype.

• Propagate to Prototype: Make the value we have set for this instance the default value of the prototype. I.e., all instances of the prototype will get this value (unless they have overridden the property).

Since the Property Editor UI is auto-generated, any object type in the application, even user-created types, automatically get the prototype workflow.

If you make a custom UI that draws its own control instead of using one of our standard controls, you have to do a little bit more work. You have to check if the inherited data is overridden or not and if it is, draw a grayed-out version of your control.

Note though, that even if you forget, or don’t bother to do this, your control will still work, you just won’t get any visual indication of whether the data is inherited or overridden.

Tree view

For hierarchical object structures, things become a little bit more complicated, because, in addition to overridden properties, we also have to handle Added, Removed, and Instantiated subobjects.

Hierarchical objects are typically edited in our Tree View, for example here is the Tree View for an entity:

Just as with the Property View, the Tree View is a generic editor that can display any object as a tree, so once we have a good prototype workflow, it will work for any object.

(Side note: for historical reasons, we actually have two separate tree views, the Entity Tree View and the Generic Tree View — we might merge them at some point.)

We use colors to indicate the “prototype relationship” of an object in the Tree View:

Color	Meaning
White	A locally added object.
Yellow	A locally added prototype instance.
Gray	A subobject inherited from the prototype.
Blue	A subobject that has been instantiated for local modifications.
Red	A subobject that has been removed from this instance.

Again, a context menu can be used to perform operations on the inherited subobjects:

• Overriding (instantiating) a subobject to make local modifications.
• Removing an override (instantiation)
• Propagating changes from a subobject back to the prototype.
• Removing a subobject from this particular instance

One thing to note here is that the inherited subobjects (the grayed out ones) cannot be selected or expanded in the tree. To select one of those objects and edit its properties you have to first override/instantiate it.

The reason for this is somewhat complicated, but it is important to understand: Unless you have overridden an inherited subobject, it doesn’t have any separate identity in our Data Model. The only thing that exists is the subobject of the prototype (which our instance has inherited). But we don’t want to edit that object, because that would change the prototype. We just want to change the value of this instance.

Since the subobject of the instance doesn’t exist until it has been Instantiated, there is nothing in the Data Model that we can select and edit. Thus, we must force the user to instantiate the subobject before editing it.

A consequence of this is that if you want to edit the property of some subobject deep in an instance’s hierarchy, you must first “drill down” and instantiate all the subobjects above it in the hierarchy. This “drilling down” can be a bit tedious as shown in this gif:

Graph editor

Another one of our generic editor views is our Graph Editor. It is used both for visual scripting of entities and for setting up rendering jobs. We also have a, similar but distinct, State Graph Editor that is used by the Animation State Machine.

Prototypes in the graph editor work in a similar way as in the tree views. Nodes that are inherited from a prototype graph are shown grayed out and if you want to edit those nodes, you can right-click them to instantiate/override them.

When we resolve connections in the graph, we automatically take overrides into account, so if you have overridden a node in the graph, any connection to that node is redirected to your override node.

Conclusions and future directions

I think it’s hard to fully grasp all the consequences of a complicated prototyping system like the one that we are using in The Machinery before you have actually implemented it and tried working with it. Now that we have logged some time with it, I think that it overall works really well.

We have a pretty powerful system — supporting arbitrary levels of fully hierarchical prototypes for any object type — that still has a pretty sensible and easy-to-use UI with no need to hand-edit text files.

itself. Note: to prevent infinite recursion in this case, we only spawn the child entities that are You can do some pretty mind-bending things with this system, such as adding an entity as a child of explicitly instantiated.

We don’t support complicated dependency expressions, such as hitpoints = prototype.hitpoints * 1.5, but I think it is worth sacrificing that to have a simpler UI. In our case, if you change the hitpoints of the basic enemy and want the advanced enemy to still have 50 % more, you just have to go in and edit that manually.

I think there is still some room for improvement though.

Getting rid of the need to “drill down”

I find it pretty annoying that you have to “drill down” when you want to override the property of a subobject deep in the hierarchy. This can be especially annoying when you don’t know exactly where in the hierarchy the subobject that you want to get at resides. You have to speculatively override objects to try to find it and then remove those overrides if you don’t need them.

I think there are two steps needed to fix this. First, inherited objects should be expandable in the tree. This should not have to be too much work, although it requires some refactoring of the tree code. This way, the user could easily drill down and find the object she was looking for. If she then overrides that object, we would override the whole “chain” of objects back to the prototype instance.

The second step would be to allow the user to actually select and edit the inherited objects in the tree without explicitly instancing them first. To do this we would have to put the Property Editor in some kind of special mode where as soon as the user edited any property on the object, we would “lazily” instantiate it. I’m not sure if this is worth doing, it sounds kind of complicated.

But who knows, sometimes when I see a problem like this where I don’t have a good solution, I just sort of let it sit in the back of my mind for a while. Then, one day, a solution pops up. If I can’t find an elegant solution right away, and it’s not super important, I’d rather wait than try to force the issue.

Edit prototype in-place

Another workflow thing that I think would be nice to have is some kind of edit-in-place functionality for the prototype. It’s a bit annoying right now that if you are working on a level that has, say, hundreds of lamp posts in it and you want to do some quick touch-up of the lamp post prototype, you have to context switch and open a new editor window with the prototype in it and then switch back to editing the level.

It would be kind of nice if you could just edit the lamppost prototype “in-place”. I.e., you would something like that, and it would put the actual prototype unit there instead of the instance. You select one of the lamp post instances in the level, right-click it and select Edit as Prototype or could then edit it in the context of the scene and have the changes immediately reflected to all the other lamp posts.

However, I’m not 100 % sure this is worth doing. Modal workflows can be tricky for users and I don’t see a super elegant way of implementing it. Maybe if we fix the “drill down” problem above, it’s easy enough to just edit the instance and then Propagate the changes to the prototype instead of having a separate “edit-prototype-in-place” workflow. I’m going to let this one sit in the back of my head too and see what pops out.

Reference-by-name

The final issue that I keep coming back to in my thoughts is the reference-by-ID vs reference-by-name problem, which I’ve written about before.

The “looser coupling” that you get with a reference-by-name scheme can sometimes be useful. For example, you can refer to whatever the “head” object of the character currently is rather than to a specific “head” object. So even if you “swap heads”, references will still work. Of course, the looser coupling has drawbacks too. You must make up names for everything, references can break more easily, and resolving reference paths can be expensive, so it’s not a clear win for either camp.

Either way, we’re pretty locked-in to using reference-by-ID as the default option in The Machinery now and it’s not likely to change.

The main way reference-by-ID trips us up is in combination with the prototype system. Suppose we have a prototype entity where some subobject refers to the head (by its ID). Now, if we create an instance of that prototype and override the head to replace it, the reference will break, because the new, overridden head will have a different ID and the reference will still point to the old ID (the head from the prototype). To fix this, we would have to find all the objects that referenced the head, override them too, and then repoint the references to the new head. Painful.

This created big problems when we first implemented prototypes for the Graph Editor. Whenever the user would override a node, the new, overridden node would get a different ID, which means all the connections to that node would break. Connections identify nodes by ID and since the new node had a new ID, the connections would no longer point to it.

However, we found a good fix for this. We made it so that when we resolve connections for the graph, we take overridden/instantiated nodes into account. If a connection refers to a node that has been overridden in the current graph, we automatically “redirect” it so that it points to the overridden node instead. With this fix, connections no longer break when nodes are instantiated. The connection still refers to the prototype’s node in the data model, but the way we interpret/resolve that reference in the instance has changed.

I’m now thinking that we could maybe use the same approach for all our references, and most of the problems we have with reference-by-ID would go away.

For example, if we want to replace the head from a prototype, we would override the “head” object in the instance and then modify it to give the character a new head. References in the instance would refer to the old head in the prototype, but when we resolved those references in the context of the instance, we would get the new head, since that new head overrides the old head for this instance.

This still requires a bit of thinking on my part to figure out exactly what it means to resolve a reference in a context and how to do it efficiently (the graph system enumerates all nodes and creates a lookup hash table, which isn’t practical for the general case). But it seems very promising to me. If it works out, it could give us the best of both worlds — solid references that can handle replaced objects.

End

I hope this post gave you some interesting thoughts and ideas on how to implement prototypes in your own system. I think this is still an open issue with lots of room for new ideas.

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

 

After about two years playing the game Marvel Strike Force, I finally quit this past week. All-in-all, this is the longest time I’ve spent on a mobile game, and I had the chance to look very closely at the game’s monetization systems and practices. For today, I want to talk about some of the subtler ways mobile games can (and have) hooked players into staying and spending money.

Being a Guppy

As I said, Marvel Strike Force is easily the mobile (and free to play) game I’ve spent the longest with. However, in the span of that time, I spent about $4.65 total on the game. When it comes to valuing time vs. money, as someone who has lived frugally, I do my best not to spend money with in-game purchases. Whenever I see those “great deals” or “best value” offerings, my brain immediately tunes them out.

One of the basic tricks we see mobile developers do these days are “targeted deals”: where the game is set up to generate a limited time deal after a condition has been met. In Marvel Contest of Champions, every time you pull a new hero or get something rare, the game will immediately send you a deal to capitalize on that event.

Everything that we’re going to talk about today is designed around two goals:

1. Keep the consumer playing and hoping they will spend money.
2. Get the consumer to spend money so that they will keep playing.

Truthfully, one of the reasons why I held out so long-playing MSF, was the very fact that I did spend money (the small amount that it was). The other reason is easily the most manipulative thing I can think of that people don’t talk about.

The Friend Trap

Anyone who has played a multiplayer game, MMOG or not, knows the value of having friends to play with. Having a group of like-minded players makes the game more enjoyable and adds to the experience. However, mobile games have found a way to subvert that and turns friends and guilds into player traps.

In a conversation with Ramin Shokrizade, we spoke about retaining players in F2P and mobile games. During that chat, we discussed “player-generated content”, or having the player base generate content by simply existing. This could be due to PvP features, leaderboard ratings, and of course guilds.

Every mobile game these days features a guild system, and they all work the same way. To get you to join a guild, the game will automatically put you into a guild, or offer quests/rewards that are only accessible via a guild. Once you are in, the guild provides additional resources and generally makes the game easier to play. For Marvel Strike Force, you literally cannot make progress without a guild, or spending tons of money, at the end game due to the resources that are earned through guild play.

That comes at a cost, as guild-related events and options will require you to log in more to assist. For games that feature guild vs. guild content, you can easily be peer pressured into spending money to make your characters better in service of the guild. For top-tier guilds, they will often force you to play consistently or keep yourself at a certain power level to aid the guild.

The main reason why I officially stopped playing MSF was that I was kicked out of my guild and lost the motivation to keep playing. In the last few weeks with work picking up about my books and projects, I had to cut back on playing the game, which meant missing daily events that had to be done. Because I wasn’t doing enough for the guild, they kicked me out, which is certainly fair but represents the trap of this design.

As with the other parts of mobile games, the sunk cost fallacy works when it comes to being in a guild. Once you have made friends and participated, now you have to keep playing and helping out your guildmates. This makes it harder for you to quit because then it seems like you are letting your friends down. It’s the same attitude that we saw in MMOGs, and how top-level guilds demand your time and attention, or you will be “cast out.”

Taking one of the best aspects of online games and perverting it like this leaves a bad taste in my mouth because I know there are people who will fall for this trap and let it consume them. For me, I am pledging that I will never join another guild in a F2P or mobile game unless they are with people I already know from somewhere else.

Demanding your time and attention takes us to the final point I want to discuss, and something that I loathe in videogames.

Real-Time

Of all the mechanics and systems, there is one that I hate the most; even beyond pay to win elements. Many games will abstract work into time that the player must wait before a task is completed, but there are games that do not abstract it. Real-timers, for lack of a better term, are when the game sets up tasks or events that occur whether or not the player is actually playing the game, and requires them to “check-in” to perform the task.

This is not the same as having a daily login: something that rewards the player for signing on every 24 hours. These are elements that require the player to actively engage with the game or be penalized. Going back to MSF, near the end of my tenure with it, I had to sign on daily for raids, daily for competitions, daily for PVP, and daily for group PVP battles. Not only that but to get the most energy daily, you must sign on at three specific times during the day or you will miss out.

Compounding these issues is that the timers for them are not controlled by you, but by the game itself. If an event ends at 4:30 in the morning that you want to win, I hope you are a night owl. One of the first mobile games I played was Marvel Puzzle Quest, where they routinely had events end in the early morning and your only way to win was to either play during those times or spend money to protect your team.

I have a strange schedule with all the work that I do, which leaves me with specific times where I can focus on playing a game, and then getting back to my other projects. I outright refuse to play a game that “demands” me to play it at set times. The title State of Decay also made use of real-timers in terms of protecting your base and followers, and no matter how much that series has been praised, I can’t play those games because of that system.

Incidentally, this is also why I cannot play MMOGs with lengthy raids that require forced groupings. There is no way with my schedule that I could just stop what I’m doing and agree to do something for two to four hours.

I am fine with seasonal play, which has events set up for weeks or even months; or let me set the time span that I can join for something.

Held Hostage

People like to talk about elements like loot boxes, “fun pain”, pay to win, and so on, as the worse parts of mobile and free to play design. Despite how anti-consumer those systems are, I would argue that the points discussed today are worse.

The reason is that they develop and cultivate a mindset of addiction: that the player is conditioned to have to play these games, and failure to do so will be punished in some way. The sad part about this piece, is that systems like season play and guilds do work and can be done in a fashion that does not hurt the consumer. But as I am sure every one of you reading this knows: that does not bring in as much money.

To end on: Can you think of other mechanics and systems that hurt the consumer that people don’t often talk about in F2P and mobile games?

If you enjoyed my post, consider joining the Game-Wisdom discord channel open to everyone.

Take-Two Interactive has opened up pre-orders for its multi-generational release NBA 2K21, highlighting one possible feature we might see more of with next-generation games: a MSRP higher than the industry-standard $59.99.

Those looking to pick up NBA 2K21 on either the Xbox Series X or PlayStation 5 are met with a $69.99 price tag for the standard edition of the game, $10 more than what the game is retailing for on the Xbox One, PlayStation 4, PC, or Switch.

It’s too early to tell if this new MSRP is an outlier or a next-generation norm, but Take-Two defended the price hike in a statement to Kotaku today saying the price “fairly represents the value of what’s being offered: power, speed and technology that is only possible on new hardware.”

The cost of game development has certainly increased over the past few console generations while game prices have remained largely the same, so the idea that we can expect a higher price tag for next-generation titles doesn’t feel like it’s coming out of left field.

Despite that, upping the price of individual games is an interesting way to cover for those pricier development cycles after considering the heads of triple-A companies like, for example, Activision Blizzard tend to grossly out-earn the developers directly involved in making those studios’ games. 

The Gamasutra Job Board is the most diverse, active and established board of its kind for the video game industry!

Here is just one of the many, many positions being advertised right now.

Location: Helsinki, Finland

Futureplay is a five-year-old independent Finnish mobile game studio located in Helsinki. We’re a small, experienced, and committed group of just over 30 people working together to create several exciting new titles – as well as maintain our existing portfolio, which includes the Idle Empire series and Battlelands Royale. 

We’re now on the lookout for a Senior Game Animator to join our team and help us build on the top quality animations Futureplay is already known for.

We expect a minimum of 5 years of experience in creating animations for casual and/or mobile games. Our ideal candidate is a detail oriented, versatile artist who shows excellent drawing skills and can employ a variety of styles and techniques. You are able to visualize and communicate abstract concepts and have a strong interest in visual and interaction design. Eye for quality animation and special effects are skills you’ll need in your work, as well as creating, evolving and executing on your artistic vision. 

You will be one of the Futureplayers bringing our game characters, environments and interactions to life. This means that you know your way around character animation VFX and UI motion graphics. You are familiar with 2D animation tools, e.g. Spine, and 3D software, such as Blender. 

Previous experience in, or understanding what it takes to, work in a minimum hierarchy environment and the ability to independently manage your tasks and responsibilities are a must. Having an agile mindset and love for experimentation are needed. You should also have great team working skills combined with the ability to provide and receive candid feedback.

We offer:

• True ownership and responsibility for the games you work on

• Competitive salary and benefits, flexible working hours

• Great, caring community working in an agile environment 

• Strong focus on employee wellbeing

• Space to grow and learn

• Low hierarchy and support in learning to navigate within it
• Work in Helsinki, one of the most relevant game development capitals in Europe

Interested? Find out more here.

Whether you’re just starting out, looking for something new, or just seeing what’s out there, the Gamasutra Job Board is the place where game developers move ahead in their careers.

Gamasutra’s Job Board is the most diverse, most active, and most established board of its kind in the video game industry, serving companies of all sizes, from indie to triple-A.

Looking for a new job? Get started here. Are you a recruiter looking for talent? Post jobs here.

Ubisoft’s response to a week of allegations of sexual, physical, and emotional abuse at the company continues to roll out. Today, CEO Yves Guillemot sent an e-mail to Ubisoft employees establishing a series of next steps for the company with the subject line “Change starts today.”

The e-mail, which Ubisoft posted on its website, details a number of actions the company says it’s taking to address prior allegations of abuse, and address future ones. It announces a shake-up of the editorial department (which saw the suspension of two executives last week), the appointment of Lidwine Sauer as head of workplace culture, a series of employee listening locations, a global employee survey, and more. 

A reshuffling of the editorial department is apparently a response to criticism that’s been growing inside the company since January. According to Kotaku, the group was reorganized to be entirely comprised of a team of entirely white men, a strange decision for a company that placed the phrase “This game was designed, developed, and produced by a multicultural team of various religious faiths and beliefs” in front of its games. 

The announcement also details the creation of a new position: Head of Diversity and Inclusion, that will report directly to Guillemot. No person has been named to this position as of yet. Ubisoft made no comment as to why it’s taken a series of abuse allegations to create such a department.

Guillemot’s e-mail reads as sincere, but it has an uncomfortable echo of some stories we’ve heard in our reporting about conditions at Ubisoft. Notably, several employees told Gamasutra that the company has a history of papering over reports filed to HR about alleged abuse, and there’s a worry that reactions to these allegations will be short-lived and mostly for show. 

“Very few trust our processes or the people in charge of solving the issues,” sources told Gamasutra’s Chris Kerr. “I guess we will see after the weekend, a lot of us are still reeling. Both Tommy and Maxime were open secrets, and there are so many yet to be outed,” they explained, referring to the recently suspended editorial vice presidents Maxime Beland and Tommy Francois.

Another frustration developers may find with Guillemot’s e-mail: it is strange to see a relatively pat and familiar set of responses to crises over diversity in hiring in response to the allegations the company faces. Can a head of workplace culture address employees who take their predatory behaviors outside the company? Why is change starting in July of 2020 when developers were reporting these incidents over the last decade and beyond?

If you have a story of your time at Ubisoft or other game developers you wish to share with Gamasutra, you can do so via e-mail.
 

Newsbrief: Zynga has closed a $1.85 billion deal to acquire mobile game developer Peak, though a press release notes that the studio will keep its “unique creative culture and brand identity” following the acquisition.

The deal, made half in cash and half in Zynga shares, brings both the Istanbul-based development team and its popular match-3 franchises Toon Blast and Toy Blast into Zynga, though its HQ will remain in Istanbul with founder Sidar Sahin at its head.

In a press release, Zynga notes that the acquisition will bolster its international reach while also boosting its average mobile daily active users by more than 60 percent. 

“We are delighted to welcome Sidar and Peak’s extraordinarily talented team to Zynga,” reads a statement from Zynga CEO Frank Gibeau. “With the addition of Toon Blast and Toy Blast, we are expanding our live services portfolio to eight forever franchises, meaningfully increasing our global audience base, and adding to our exciting new game pipeline. As a combined team, we are well positioned to grow faster together.”

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

Ever since I hot-taked way too hard about Crystal Dynamics’ Tomb Raider in my pre-Gamasutra days, I have a new personal rule: I won’t criticize a game until I’ve gotten to play it. Sometimes as a writer, I’m lucky enough to play games before they release, and a complicated web of embargos will influence how and when my articles debut. 

With The Last of Us Part II, I had to wait a couple of weeks while I played the game after its proper release to organize my thoughts, meaning my experience with the game was informed by an array of interesting writing and peeks into what was coming down the pipe thanks to reviews and critiques from other outlets. But as I proceeded through the Seattle wasteland, another voice barged into the critical space for Naughty Dog’s newest game—its creators. 

Or rather, a specific subset of its creators, and in a limited case, Sony PR. While a great deal of Naughty Dog developers took to Twitter to celebrate players finding all the neat secrets and wonders the game has to offer, a select group of The Last of Us Part II developers began criticizing the criticism. Game director Neil Druckmann sent messages to journalists riffing on criticism of the game (one notable incident has been removed from Twitter, so I can’t link to it), and Troy Baker responded to an off-handed comment by Bloomberg’s Jason Schreier about the length of video games with a noxious quote from Theodore Roosevelt. 

This prickliness over criticism seems to not be isolated to a few team members. A few writers mentioned that after their reviews went up, Sony PR sent polite e-mails with brief questions about the nature of their reviews, an unusual step in the review process that’s normally reserved for correcting factual errors that would be relevant to good-faith journalists. 

Baker’s invocation of America’s bear-loving, warmongering 26th president may have what tipped me over the edge. I have a particular dislike for this quote since it rewards creatives (or athletes; I saw it hanging in a gym in college) for centering themselves over the world around them. 

It’s true that no one outside of the game-making process can properly evaluate what it was like to work on a particular game. But a damnation of critics like this not only ignores the work that goes into good criticism, it creates a defensiveness that tarnishes any relationship with even the mildest criticism, while simultaneously propping up an industry that loves to talk about how ideas should never be treated as sacrosanct, and always open to criticism in the creative process. 

If we’re being honest, in the world separating creative work from noxious or awful behavior from its creators, this is a mild case. It’s far more difficult to even rewatch say, the Transformers films, knowing how one of its lead actors was sexualized and mistreated on set. But as I rolled into the final hours of The Last of Us Part II, every major dramatic beat of Ellie’s journey felt tainted by that defensiveness. I can clock the last moment that I felt satisfied with the game, and from there to the last minutes, I could only see Druckmann and Baker’s words in my head, even while the game demanded my full attention. (To Druckmann’s credit, he has sought out some criticism of the game from writers like Carolyn Petit)

There’s a pair of reasons for this. The first is that the back end The Last of Us Part II deals with vulnerability, trauma, and PTSD, as Ellie’s long journey after surviving the events of the first game winds to a close. It’s a heavy emotional lift, asking the player to empathize with Ellie and the people around her begging her to stop this revenge-fueled quest. It is controversial by design, an experience that will have some players nodding along and others bursting with anger. 

When creators interject themselves in a space that sensitive, it poisons the experience for players trying to navigate their own relationship with violence and trauma. The violence of The Last of Us series has long been a subject for debate, and every reaction to it, positive or negative, has been a totally fair one. 

But that leads into the second reason: when creators lash out in response to criticism, a new dynamic is established: one kind of response to a game is the ‘acceptable’ one, and will earn you praise, and in some case, exclusive access, from a developer. Another kind will see verbal abuse sent your way, with maybe some fan anger as well, especially if you’re of a marginalized gender or are a writer of color (I am neither, and will likely endure little barrage for it).

Under that dynamic, even writing this piece feels mildly nerve-wracking. Will it influence my relationship with Sony PR? Will I be able to interview Druckmann or Baker on other projects they’re involved in once it’s safe to return to live events? The Last of Us Part II sells itself as a prestige game with prestige marketing, and a message is being sent that if you make even the mildest comments impinging on that status, retaliation may be in order.

It’s already been tough to figure out how to write about The Last of Us Part II, with so much other reporting detailing working conditions at the company. If I dive into the amazingly detailed rope physics, am I obligated to interrogate the reported crunch that may have birthed it? If I marvel at the detailed animation, do I need to comment on a former animator who spoke up about his negative experience at the company? 

That’s a particularly thorny subject because once again, Druckmann’s comments poison the well. After said animator spoke up, Druckmann specifically tweeted out praise for the company’s animation team, a tweet with very big “everything is fine, nothing to see here” energy. 

At Gamasutra, we have an unusual role as journalists. Our primary audience is people invested in the art and business of making games, and that primarily includes game developers and their adjacent colleagues. We don’t often feel pressure to buy into hype, because we’re waiting for a chance to dig into fascinating mechanical or technical details. We haven’t built a site that relies on day-one reviews, but we still rely on close relationships with developers to tell these kinds of stories. 

Ours is a different path, and when we write criticism on this site, we try to do so explicitly with the goal of helping developers create better experiences for their audience. If Naughty Dog were the only developer I’d seen this behavior with, I might have reserved these thoughts for private conversation with folks from the studio. But it isn’t, and more conventional journalists have made that clear. 

Game journalism has spent the last decade going through an emotional growth spurt, putting in the work to try and tackle more sensitive issues, and to make game criticism sound less like car or technology reviews. That shift can create divides between the folks who make games and the folks who cover them. 

I hope that the people who make games take a moment to re-evalulate their response to external criticism. That isn’t an ask to brush it all off–every creator needs space to vent about players or journalists who don’t understand what they went through in making a game. And with the abuse hurled at devs every second from toxic players, they deserve the ability to remove themselves from the conversation if it’s beyond their threshold. 

But I can definitively say that watching developer backlash to criticism tainted my time with The Last of Us Part II. In a game where characters grapple with who they are and how they feel about their terrible, beautiful world, I felt less agency to explore that journey with them.

I felt encouraged to only accept what the game handed to me, to not question it, to not be curious about its implications or underlying premises. 

In this 2018 GDC talk Criterion Games’ Matthew Harris explore good principles for video game vehicle design that can apply to everything from racecars and X-Wings.

It was presented as something of a masterclass in video game vehicles, and Harris touched on everything from input choices to camera design as he walked through examples from Criterion’s work on games like Star Wars Battlefront II.

If you’ve ever enjoyed the feeling of driving a virtual vehicle and want to better understand why, this was a great talk to watch, and now it’s freely available on the official GDC YouTube channel!

In addition to this presentation, the GDC Vault and its accompanying YouTube channel offers numerous other free videos, audio recordings, and slides from many of the recent Game Developers Conference events, and the service offers even more members-only content for GDC Vault subscribers.

Those who purchased All Access passes to recent events like GDC or VRDC already have full access to GDC Vault, and interested parties can apply for the individual subscription via a GDC Vault subscription page. Group subscriptions are also available: game-related schools and development studios who sign up for GDC Vault Studio Subscriptions can receive access for their entire office or company by contacting staff via the GDC Vault group subscription page.