Aktivitäten

Quo Vadis, a game development conference and part of gamesweekberlin, was hosted in the Kulturbrauerei Berlin, which offered rooms in two levels of the building for the conference. The conference attracted members of the game industry in Germany and worldwide. The main room had exhibitions and booths from different companies, such as Ubisoft and Microsoft (presenting their PlayFab technology), and schools offering game development programs, such as University of Applies Sciences Europe. There were two stages offering different tracks of talks and an extra room on another level of the building for workshops. The first day of Quo Vadis was mostly focused on the business aspects of the game industry, while the second day dived deeper into the technical aspects.

© Jonas Persson / Booster Space

On the first day Tymon Smektala offered a workshop in game design. This focused on the process that helps game designers focus on the mechanics of a game that are most important before they dive into details. He introduced “The Door Problem” as described by Liz England, which shows that even design problems that sound simple can be much more complex than one could think. Tymon then broke up the participants into groups in which each group had to choose an existing game, identify the main emotion and core mechanics of the game, and produce a physical game (like a board game) using the emotion and mechanics that were identified. The teams worked on Pokémon, The Legend of Zelda, and Sim City, producing games that can be played using a mixture of cards and game boards such as chess boards. Because the teams focused on the core mechanics, the results were actually fun to play!

In the talk “Start Lean, Learn Fast, Scale Faster”, Daniel Stammler from Kolibri Games explained the processes used in a company that releases updates to their games on a regular basis. Much of talk was focused on the mobile market, but had some general tips for other developers. Daniel mentioned that in the beginning of a project, it’s much more important to make sure the game works than to focus on profits. He then explained the emphasis of measuring data, such as D1 retention (amount of players returning after one day) and crash reports, to assist in measuring the health of the game and identifying problems. He also explained that his team had good experience with staged roll out, where only a certain amount of players get updates at first, and by doing so it’s easier to see if there are problems before everyone is playing the new version.

Visitors wanting to know how their project could get money from the European Union could also go to the talk by Jari-Pekka Kaleva, from the European Games Developer Federation. He introduced some projects from the EU that can help game developers find funding, such as funding for games with narrative storytelling and the Horizon 2020 programme, which can provide money for companies producing technical innovation. For other opportunities he linked to the website accesstofinance.eu.

Christian Fonnesbech then held a talk about how to make long lasting game titles and how to balance two things with which game develops often struggle: creativity and business. His talk “Who wants to live forever?” communicates the concept that your passion cannot defy the laws of business, and if you want a successful title, you need people in your team that understand creativity and business. If there is no business plan but the game is in development, then it’s already too late. He emphasized that a game that will withstand time must also focus on its intellectual property: it must have notable characters, an emotional journey, and a world that’s built to last. If it does not stand out in the saturated market, it won’t become a series.

© Jonas Persson / Booster Space

On the second day, Dominik Gotojuch from Robot Gentleman presented what could be seen as a contrast to much of what Christian Fonnesbech said: the reason why it’s sometimes better not to make a sequel. He presented the game his company had worked on, 60 Parsecs, and its predecessor 60 Seconds. The cost to develop the sequel was much higher than the first game, but failed to make as much of an impact, despite more marketing. One lesson to learn from this talk was that investing more effort does not always translate to more success.

Later Gregory Janiczek from Ubisoft Blue Byte held a talk on the benefits of diary studies in games and how it helped in the development of Anno 1800. The idea of a diary study is that the player writes his or her experience in some way, such as in a structured fill-in document, performed in the player’s own environment (such as his/her apartment, without the developers being physically there). These studies run over a longer time period and therefore have their own advantages and disadvantages. Some advantages Gregory mentioned include players not being in an artificial lab environment and long-term insight that the developer gets into player behavior, especially in later parts of the game. Disadvantages include the expense of analyzing the data because of the amount that is collected and the difficulty of player selection because it’s hard to find people who will take part in a long-term study. Much of the collected data his team used was objective information from the game (such as telemetry data and game state) and some was subjective related to the player experience. In the end Gregory explained that having less participants, keeping questionnaires short, and using the right tools can make diary studies possible even on a low budget.

Consecutive talks and panel discussions on Amazon Alexa and Google Stadia introduced some new and existing technologies that could change the way games are played. Rafael Miranda from Amazon explained key points to understand to develop applications for Amazon Alexa, and how they can be used to augment games or create entire games in Alexa. Rafael explained the importance of defining many “slots”, which are essentially keywords, and that failing to do so could result in Alexa failing to understand what a user wants. Despite Alexa only being speech, this brings new aesthetic problems. Rafael warns developers to avoid repetitiveness, exit gracefully and explain success and failure events, engage the user and provide fresh content, and finally, add easter eggs to make the experience more enjoyable. The panel talk afterwards about Google Stadia introduced Google’s service, which plans to make streamed gaming available for multiple platforms, and discussed whether and how the participants believe it will change the game industry entirely. The opinions varied.

© Jonas Persson / Booster Space

A technical talk by Gabriel Steinkirch discussed how to create native Unity plugins for Android and iOS. Gabriel gave a live demo in which he wrote the C# code for Unity which connects to native plugins for Android and iOS platforms. He then showed how to create projects in Android Studio and XCode to write the native code, how to call that code from Unity’s C# script, and how to call C# code in Unity from the native code. He emphasized using tests because the boundary between Unity and native code has very little compile-time safety.

Quo Vadis, a game development conference and part of gamesweekberlin, was hosted in the Kulturbrauerei Berlin, which offered rooms in two levels of the building for the conference. The conference attracted members of the game industry in Germany and worldwide. The main room had exhibitions and booths from different companies, such as Ubisoft and Microsoft (presenting their PlayFab technology), and schools offering game development programs, such as University of Applies Sciences Europe. There were two stages offering different tracks of talks and an extra room on another level of the building for workshops. The first day of Quo Vadis was mostly focused on the business aspects of the game industry, while the second day dived deeper into the technical aspects.

© Jonas Persson / Booster Space

On the first day Tymon Smektala offered a workshop in game design. This focused on the process that helps game designers focus on the mechanics of a game that are most important before they dive into details. He introduced “The Door Problem” as described by Liz England, which shows that even design problems that sound simple can be much more complex than one could think. Tymon then broke up the participants into groups in which each group had to choose an existing game, identify the main emotion and core mechanics of the game, and produce a physical game (like a board game) using the emotion and mechanics that were identified. The teams worked on Pokémon, The Legend of Zelda, and Sim City, producing games that can be played using a mixture of cards and game boards such as chess boards. Because the teams focused on the core mechanics, the results were actually fun to play!

In the talk “Start Lean, Learn Fast, Scale Faster”, Daniel Stammler from Kolibri Games explained the processes used in a company that releases updates to their games on a regular basis. Much of talk was focused on the mobile market, but had some general tips for other developers. Daniel mentioned that in the beginning of a project, it’s much more important to make sure the game works than to focus on profits. He then explained the emphasis of measuring data, such as D1 retention (amount of players returning after one day) and crash reports, to assist in measuring the health of the game and identifying problems. He also explained that his team had good experience with staged roll out, where only a certain amount of players get updates at first, and by doing so it’s easier to see if there are problems before everyone is playing the new version.

Visitors wanting to know how their project could get money from the European Union could also go to the talk by Jari-Pekka Kaleva, from the European Games Developer Federation. He introduced some projects from the EU that can help game developers find funding, such as funding for games with narrative storytelling and the Horizon 2020 programme, which can provide money for companies producing technical innovation. For other opportunities he linked to the website accesstofinance.eu.

Christian Fonnesbech then held a talk about how to make long lasting game titles and how to balance two things with which game develops often struggle: creativity and business. His talk “Who wants to live forever?” communicates the concept that your passion cannot defy the laws of business, and if you want a successful title, you need people in your team that understand creativity and business. If there is no business plan but the game is in development, then it’s already too late. He emphasized that a game that will withstand time must also focus on its intellectual property: it must have notable characters, an emotional journey, and a world that’s built to last. If it does not stand out in the saturated market, it won’t become a series.

© Jonas Persson / Booster Space

On the second day, Dominik Gotojuch from Robot Gentleman presented what could be seen as a contrast to much of what Christian Fonnesbech said: the reason why it’s sometimes better not to make a sequel. He presented the game his company had worked on, 60 Parsecs, and its predecessor 60 Seconds. The cost to develop the sequel was much higher than the first game, but failed to make as much of an impact, despite more marketing. One lesson to learn from this talk was that investing more effort does not always translate to more success.

Later Gregory Janiczek from Ubisoft Blue Byte held a talk on the benefits of diary studies in games and how it helped in the development of Anno 1800. The idea of a diary study is that the player writes his or her experience in some way, such as in a structured fill-in document, performed in the player’s own environment (such as his/her apartment, without the developers being physically there). These studies run over a longer time period and therefore have their own advantages and disadvantages. Some advantages Gregory mentioned include players not being in an artificial lab environment and long-term insight that the developer gets into player behavior, especially in later parts of the game. Disadvantages include the expense of analyzing the data because of the amount that is collected and the difficulty of player selection because it’s hard to find people who will take part in a long-term study. Much of the collected data his team used was objective information from the game (such as telemetry data and game state) and some was subjective related to the player experience. In the end Gregory explained that having less participants, keeping questionnaires short, and using the right tools can make diary studies possible even on a low budget.

Consecutive talks and panel discussions on Amazon Alexa and Google Stadia introduced some new and existing technologies that could change the way games are played. Rafael Miranda from Amazon explained key points to understand to develop applications for Amazon Alexa, and how they can be used to augment games or create entire games in Alexa. Rafael explained the importance of defining many “slots”, which are essentially keywords, and that failing to do so could result in Alexa failing to understand what a user wants. Despite Alexa only being speech, this brings new aesthetic problems. Rafael warns developers to avoid repetitiveness, exit gracefully and explain success and failure events, engage the user and provide fresh content, and finally, add easter eggs to make the experience more enjoyable. The panel talk afterwards about Google Stadia introduced Google’s service, which plans to make streamed gaming available for multiple platforms, and discussed whether and how the participants believe it will change the game industry entirely. The opinions varied.

© Jonas Persson / Booster Space

A technical talk by Gabriel Steinkirch discussed how to create native Unity plugins for Android and iOS. Gabriel gave a live demo in which he wrote the C# code for Unity which connects to native plugins for Android and iOS platforms. He then showed how to create projects in Android Studio and XCode to write the native code, how to call that code from Unity’s C# script, and how to call C# code in Unity from the native code. He emphasized using tests because the boundary between Unity and native code has very little compile-time safety.