Category: News

Valve has kicked off a Steam Spring Cleaning event that encourages players to spend some time with neglected games already in their Steam libraries through unlockable trophies and a Steam profile badge. 

The event itself only runs from May 24 to May 28, but is an interesting way for Valve to encourage Steam users to explore games they might have picked up in a sale or bundle, potentially helping developers connect with new players in the process.

Valve has built the event around three ‘daily tasks’ that nudge players toward less-played games in their libraries by things like suggesting a random game per-day or tasking Steam users with playing a game they already own by have yet to play.

Spring Cleaning also introduces a number of limited-time trophies that reward Steam users for doing things like revisit a game they haven’t played in a while, play a game recommended by a friend, play a game purchased within the last six months, or returning the first game ever activated on their Steam account.

Next week, indie shopkeeping game Moonlighter hits Steam, mixing together the shopkeeping shenanigans of Recettear with procedural dungeon crawling inspired by the older Legend of Zelda games. Made by developer Digital Sun and published by 11Bit Studios, the depth and complexity of this shop-management game has caught our attention at Gamasutra, and inspired us to stream the game while chatting with the lead developer starting at 3PM EDT. 

As always, we’re going to be asking questions about the design and development of Moonlighter, and we invite our readers at home to ask questions of their own in Twitch chat! 

And while you’re at it, be sure to follow the Gamasutra Twitch channel for more developer interviews, editor roundtables and gameplay commentary. 

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.

b r 1 is an attempt to translate a game from one game engine/environment into another. In this case, it is a translation of my own game v r 1 from Unity into Bitsy.

Translations of one form or another are a generative approach to game design and development for me, something I’ve written about before. Translating between engines specifically feels like an opportunity to think about the underlying building blocks of videogames by employing the semi-scientific experimental idea of maintaining the design constant while treating the engine/environment as the controlled variable. b r 1 helps me to ask and explore what the differences between Bitsy and Unity and to look at what Bitsy is like as an engine.

To briefly recap the source material, v r 1 was a game I made as an approach to reproducing/thinking-about the work of Gregor Schneider in a virtual/digital space. Schneider’s masterpiece The Haus u r is a house that he obsessively makes, demakes, and remakes. Within the house there is a room he calls u r 1 which he has reproduced multiple times in different contexts, including in Totes haus u r at the Venice Biennale. It is this room that I tried to recreate in v r 1 and then to manipulate in different ways to explore hopefully related ideas about reproduction, craft, and space. In v r 1 the player encounters a version of Schneider’s u r 1 over and over again in different formats facilitated by the Unity game engine, whether it simply has the light turned off or whether it has been broken into its constituent pieces and left on the ground.

For the remainder of this essay, I want to write about what I found out when I remade v r 1 in Bitsy, focusing on what was revealed about Bitsy as a game engine as well as more general design and development ideas. My objective isn’t to go over these things exhaustively, but just to note what I find interesting. Much fuller documentation and obsessive thinking can be found in the project’s commit historyand process documentation wiki.

Vision versus concept

Bitsy is a 2D game engine, Unity is a 3D game engine. One of the most immediate decisions to make revolved around the basic question of how to represent the room in the Bitsy form. The initial decision was a bird’s-eye view, since this is the most formal way of translating, but it felt flat and uninteresting to look at (c37bd36). I went with a kind of false 2.5D approach, with inaccurate perspectival effects, in order to try to capture the feeling of v r 1 (84047e7). Even though it was less straightforward, it felt important to be able to evoke the Unity version of the game visually to maintain some connection between the very distinct engines. Further, having perspective was the only way to make the window and radiator in v r 1/u r 1 visible in the Bitsy context: seen from the top, they are simply part of the wall. This kind of translation project creates specific tensions of this kind, a need to reconcile a new technology or design framework with pre-existing requirements. These tensions are valuable because they force us to ask both about the technology/framework at hand (the materials of production) and the source design/concept we are attempting to translate.

“What is that?”

Bitsy uses a tile-based representation of the world. A single ‘room’ (or scene) is 16×16 tiles and each tiles is 8×8 pixels. This limitation, especially at the tile level, is hugely restrictive on what can be represented, or at least how that can be done. Given that the avatar in Bitsy is one tile in size, a scale is effectively set for the rest of the world, not dissimilar to Unity’s unit grid in relation to the avatar height in that system. The obvious outcome of this is the challenge of re-representing 3D objects and forms from v r 1 in Bitsy’s low-resolution, and the risk that they will become unintelligible through that translation (Thursday, 10 May 2018, 13:57). This situation is partially resolved through careful use of the restricted pixels, partially through creating some multi-tile objects where scale permits (such as the bed), and partially through the additional Bitsy affordance of dialog boxes. The dialog boxes allow for descriptive (or other) texts to be attached to specific objects in a scene, meaning that texts can further clarify the low-resolution image and creating a cooperation of text/image that can approximate the high resolution detail of Unity (See commit 8066d3b and Saturday, 19 May 2018, 14:44 and Sunday, 20 May 2018, 18:07).

I am not a camera

A drastic change from v r 1 to b r 1 is the use of a third person ‘camera’. Where v r 1used a first-person character controller, allowing the player to be ‘immersed’ in the world and adopt a (relatively) naturalistic view based on perspective, proximity, etc., Bitsy lends itself to a third-person view in which the entire scene is visible at all times and the avatar moves around it with tile-based movements. This leads to different understandings of ‘visibility’ in b r 1. In v r 1, for instance, if you stand outside the window and look into the room you can see the bed, tube, and trunk, but not the radiator because it is recessed beneath the window (757f18a). We end up with a “total information” view of the scene in which you can see into a room before you even enter it, a strange perceptual trick that is actually fairly common in many games, but raises the question “who am I?” This is complicated even further in a scenario such as the “door down” room, in which the character cannot enter the room, nor look through the window, yet can see everything inside it (8066d3b). The fact that the ‘camera’ is situated high above the world being experience further complicates matters and ultimately necessitated odd decisions around how to represent walls and objects’ spatial relationship to those walls (dd47dd8).

Me and Gregor Schneider

At its heart, v r 1 was about grappling with how to work with Unity in ways that might stay somewhat true to Gregor Schneider’s practice. Schneider’s work is very much focused on obsessive crafting and duplication of space, and so v r 1 changed this idea to reconfiguration of space (as duplication is all too easy in digital spaces). As such, b r 1 has to be situated in relation to Schneider’s work too. At many points in its development, I was pleased to find quirks of Bitsy that seemed “more authentic”, such as the fact sprites are unique in Bitsy, meaning I had to create, for instance, a new radiator every time I needed one for a new room, a very Schneider-esque activity (984beb9). I became sufficiently interested in this idea that I even began to worry whether my underlying process was “honest” enough if I duplicated not the original radiator but a different copy (0e084ae). Ultimately, working in the new game environment felt like a continuation of the v r 1 project to reimagine his process in this new digital context. “His work is about spatiality and the seen and unseen and spatial composition. … He struggles with imperfect materials to make things identical, perfect, I’m struggling with a perfect materials to make things legible, humanised, real.” (Thursday, 10 May 2018, 13:57).

A frozen world

Another major contrast between the Unity and Bitsy versions of this work is the presence of physics in Unity but not in Bitsy (beyond basic collisions that prevent movement through solid objects). This is relevant to the above meditation on Schneider’s work especially because of its highly physical nature. In v r 1 I relied on the physics engine to create appropriate configurations of objects when the room was rotated in various ways, with the bed etc. falling realistically and settling. In Bitsy this kind of physics had to be simulated in drawings and dialogs in order to create facsimiles of the v r 1 tableaux (ad168b3). Another approach to this idea of physics was, in fact, to have the player act as the simulation, as with the scene in which the player falls through the floor, enacting their falling by moving the avatar downward on the screen (9c69163). In the end, I wonder whether the extremely static nature of the Bitsy world is actually more true to Schneider’s creations which, after all, you are only meant to view and never touch, and which tend to represent timeless, endless scenarios that repeat their minimalist scenes indefinitely.

Going with the grain

To end on a point of Schönian joyfulness about the conversation with materials, working with Bitsy did have these moments of feeling like I was in synch with the software. This was especially true when creating versions of the v r 1 spaces could be reimagined in terms of the “Bitsy reality”. The ‘organised’ scene is an example of that (b56a96c). In Unity the elements of the 3D models are arranges by height in a line, in Bitsy the corresponding scene is arranged in a grid, tile by tile in a way that’s visually pleasing and makes sense as a translation of that idea. Similarly the scene in which the room is collapsed into pieces on the ground as if it has fallen down in Bitsy is represented with the tiles that make up the room being jumbled but still taking up the same space on the screen (ad168b3). This idea of “going with the grain” (4b7e96f) was a recurring feeling with the work, from choosing to represent the title in a dialog box, to using the dialog system to describe what is seen through windows (19d7a75), to selecting the order of rooms by hand since Bitsy is not predisposed to random generation (9c69163). Perhaps most emblematic of this process was toward the end of the project where I needed to replace a set of three scenes from v r 1 that simply made no sense in Bitsy (generally these relied very specifically on having a real third dimension, such as one room leaning on the other. Needing three new rooms to feel fulfilled, I ended up turning to Bitsy-specific affordance to manipulate the space: a new colourful palette, animated tiles, and an ‘items’ based room in which you can pick up the objects (Saturday, 19 May 2018, 16:58).

The end

In the end, b r 1 served both as an intriguing reengagement with v r 1 and Schneider’s work, and a way of thinking closely about the representational and experiential properties of both Unity and Bitsy as creative tools. I have every intention of carrying this particular project forward with presumably b r 2 and b r 3and all the struggle and learning that will entail.

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.

Tech Support: Error Unknown is a rapid paced puzzle game in the vein of Papers Please. Presented entirely through a computer interface, the player is contacted by customers through a chat dialogue interface where they try to establish what the customer’s problem is and offer solutions relevant to the situation. The genre blends quick execution with detective work to interrogate customers and understand situations properly.

Over the course of a game, a player will interact with 200 to 350 different customers, many of which will have similar problems such as their phone not turning on, a broken screen or simply trying to change the wallpaper. Interactions generally involve between 10 to 20 lines of dialogue on the customer’s side.

Because of the fast paced nature of the game, I avoided using a text parser in favor of a macro system offering a series of questions and solutions. New options gradually unlock over the course of the game, but every unlocked option is available to the player at all times during a conversation, meaning the customer must be able to account for every comment and react accordingly.

Having such a wide range of dialogue options pushed me to create a system that would merge various tricks to make conversations flow naturally and as uniquely as possible. I also purposefully limited the choices available to the player, to ensure that most responses would be applicable to more than problem, even if they’re not always the correct answer. Towards the end of the game, the player access to over 25 replies, to which customers must be able to react in a natural and unique fashion.

Dialogue is always presented as the customer reacting to something the player is saying or doing, so the the first step was to write basic dialogue for each of those situations. In some cases, lines are reused for similar situations, like when the player is offering a solution which is inconsequential to the problem. However, even wrong paths often lead to unique dialogue options, like the customer asking why the player wants to track their phone through GPS when all they want is to change the wallpaper.

Once all the situations were established, I added multiple lines of dialogue for each case, to avoid having the same replies from happening when the same problem occurs. A customer calling concerning their phone being corrupted might answer “When I tried to start my phone, it gave me a garbled mess.” or “My phone won’t start, and it says something about corruption”. Some customers might dodge giving a specific answer altogether and simply respond “My phone doesn’t work correctly”. This variety also keeps the player on their toes and rather than simply memorizing the solutions to a series of replies.

Problems may also be re-contextualized to provide a wider range of replies. If a phone got wet, the customer might explain that they’re clumsy and dropped it in the pool, or that it was raining really hard. In some cases, the customer may not fully understand what the solution presented means, leading down a different solution free for the player.

All of the dialogue lines are listed in a Open Office spreadsheet, which I then convert to a JSON file loaded by the game. Statements can have several dozens of replies to choose from as a baseline, ranging from a single sentence to a small monologue, and changed on the fly as the customer becomes more irritated or the player asks the same questions again.

Once a line is selected, the system determines what variance to add to it. Sentences are broken into chunks which are interchangeable, allowing for different expressions to be used. In the case of “I already told you, I cracked the screen on my phone”, the customer could instead start the sentence with different expressions: “Like I told you”, “I just mentioned it! Once again,” or “Are you even listening? I already said that”.

Customers also have individual traits which influences their speech patterns. Emojis might be added to the responses to add some flair, or the customer might use shorthand for quick dialogue, where forget becomes 4get, you’re becomes ur, and so on. Some may even add typoes to their dialogue, with the frequency varying between different customers.

All of these variations not only serve to make sentences feel distinct, but also add a lot of personality to the customers themselves. The procedurally generated insults allow for memorable quotes like “you contemptuous piece of trash” or “worthless donkey”. They can even use more common swear words if the option is toggled on.

Tech Support also employs a series of unique characters with their own dedicated dialogue to spice up the conversations. These are split between story characters and specifically crafted customers, who blend in among the procedural characters until a dialogue is established.

These characters will always appear on the same days and have the same problems, which allows for more carefully crafted dialogue and requiring less variation. It also allows me to craft a story around these characters which makes them pop more and adds credibility to the dialogue system.

Having about 10-15% of conversations be unique characters makes the entire dialogue system feel more fresh,

A substantial amount of time was spent crafting the dialogue and breaking them down to make them go a longer way. Because the dialogue system and investigation was a pillar of the game’s design, making conversations flow naturally is a priority.

Locking the player’s reactions to dialogue macros helped limit the scope of the game but also allows for faster and more intense game play. The pacing also makes it easier for responses which do sound very similar to be mostly ignored as the player becomes doesn’t have time to break down how the reply is made, only focusing on the meaning itself.

The rate of a new conversation for every play minute was always going to be a challenge to make every response unique, but by virtue of a few tricks, a few thousand lines of dialogue were pushed to become a lot more.

Two weeks after announcing it would release a Steam streaming app for Android and iOS, Valve stated today that the iOS version is being blocked from release by Apple due to previously unnoticed “business conflicts with app guidelines.”

This is significant because it locks down Valve’s ability to reach iOS users, and according to Valve it was done retroactively after the Steam Link app had been approved by Apple.

“On Monday, May 7th, Apple approved the Steam Link app for release. On Weds, May 9th, Valve released news of the app,” reads a press release sent out today by Valve. “The following morning, Apple revoked its approval citing business conflicts with app guidelines that had allegedly not been realized by the original review team.”

It goes on to state that Valve attempted to appeal the decision, adding that many similar remote desktop streaming apps exist on the App Store, to no avail.

“Ultimately, that appeal was denied leaving the Steam Link app for iOS blocked from release,” the release continues. “The team here spent many hours on this project and the approval process, so we’re clearly disappointed. But we hope Apple will reconsider in the future.”

Gamasutra has reached out to Apple for further clarification and comment. In the meantime, the Android version of the Steam Link app has already debuted (at least in beta form) on the Google Play Store.

In this GDC 2018 talk, designers Raph Koster, Dave Mark, Richard Lemarchand, Laralyn McWilliams, Noah Falstein and Robin Hunicke go over what problems they wish artificial intelligence could solve for them when developing games.

The panelists discuss concepts like character AI, procedural content, animation, speech, and “director”-style pacing and content delivery.

While the talk doesn’t necessarily focus on the practical of “what can we do,” it focuses instead on exploring “what COULD we do.” It’s an informative session that provides AI programmers with ideas for what could be implemented in game design.

Programmers interested in AI programming may appreciate that they can now watch the talk for free over on the official GDC YouTube channel!

In addition to this presentation, the GDC Vault and its new 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, GDC Europe, and GDC Next 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. Finally, current subscribers with access issues can contact GDC Vault technical support.

Gamasutra and GDC are sibling organizations under parent UBM Americas

“I’d like to think our return rate is so low because we’re very clear about the experience the player should expect.”

– Developer on Quarantine Circular Mike Bithell on why the game has a two percent refund rate. 

Steam can be a tricky platform for developers looking to market short, narrative-driven games. After all, if players aren’t satisfied with their purchase they can request a refund, so long as they’ve played less than two hours of it. 

Bithell Games’ newest title, Quarantine Circular, has a fairly short runtime of about one to two hours with only a two percent refund rate. 96 percent of its 718 reviews are positive, and Bithell credits honesty as the reason for 98 percent players not refunding the game after finishing it.

“I think we’ve been very upfront about the short duration of the game, and we’ve done similar with Quarantine Circular,” he explains. “We try to be very clear this is a text adventure and what that entails, but the majority of returns are people who were expecting a very different game than the one described on the store page or in the trailer.”

Another factor which may have played into the low refund rate of Quarantine Circular is the non-existent marketing of the game, which seemed to appear out of the blue. “We are terrified of people getting the wrong idea from a screenshot of the game,” Bithell admits.

“What better way to control expectation than to not allow time for it to build? Here’s our game. This is what it is. We put a lot of work into it.”

Make sure to check out the entire piece over at Kotaku, which goes into more detail about how Bithell could get away with dropping a game with little public hype before release.