Lessons learned from game developers
Beres-Deak, Adam
Game development teams have always been cross-functional and had to tackle a wide range of challenges during the development of a new game. They have developed many interesting techniques which also business software developers can use for their jobs. In this talk I would like to share such patterns and techniques with the audience. Some of them are programming techniques, some of them are relevant for teamwork and some are related to user experience.
 So, hi everyone, can you hear me? Ah, yeah, it's fine. So thank you for joining my talk about, so I would like to share with you some thoughts about what I learned from game developers and game development. I myself, I'm not a game developer, I'm a normal business, so I'm on the business side, I'm developing websites at Autoskott24 in Germany. It's Europe's biggest used car portal. So actually, what I will present to you today is what I collected in the last one or two years. It was some kind of hobby research, if I can say so. And I think we can learn many things from game developers, studios, the developers, how they work together, the teams and so on. But first, before we start, just a question. So are here any gamers or anybody who enjoys playing games? So, wow, that's great. What I was hoping for. And is here somebody who tried to develop a game? Wow, that's very nice. And who considered it as a success? So that's whatever success to you means. So I've never succeeded with the game, I have to admit. But maybe anybody of you? Ah, yeah, a few but not that much. Okay, then, so my question was, what would change if I began developing my software like a game? What could I do? And there I found some interesting things which I want to share with you. And here's the agenda that we are going to do today. So first I have a little quiz, so just that we get in the mood. And then we'll talk about success in games, game development, about prototyping, feature creep, game choose, and maybe some programming techniques at the end if we still have enough time. So then let's begin with the quiz. So I'll show you an image. One maybe one, two, three, and then you have to just shout out loudly. But the game, so in this case it's obviously, it stands on the screen, it's Mario Kart. So this one is also quite simple, one, two, three. Yeah. Okay. So this one, I'm also sure almost everybody heard about it. One, two, three. Yeah, Flappy Bird. It is. Yeah, exactly. So this one is maybe a little bit harder, but there were hardcore audience for this game. Actually, it's not a hardcore game, but the audience was really hardcore and spending very, very much time. So one, two, three. Yeah, it's really fun. Okay. So some nostalgic one from early 90s or end of the 80s. Yeah, maybe one more hint. So one, two, three. Wow, you are great. Okay. This one is quite modern, but still a few years old. One, two, three. Yeah. I need first speed, but which one? Okay. It's the most wanted and the better one. So around 10 years ago. Okay. I'm sure you also know this one, one, two, three. Yeah. It's more to combat. Okay. This one is also quite well known. One, two, three. Yeah. And also the real one. So and this one is actually, but I played the most. I have to admit I, so actually many people are playing it around 6 million in the world, but I don't know whether somebody knows this one here. So one, two, three. Yeah. Trackmania. Yeah. Beautiful. Okay. So now we are in the mood. So let's talk about success. What does that mean? So there is a romantic answer, which is if somebody has fun with your game. So like your significant other or your mom and you see them smiling and then you are also quite happy and maybe it's not just the two of them, but around a few thousand people or maybe millions. So yeah, that's actually, as I've heard, a very cool thing. Or when I developed games for, so during the development, I was playing with them a lot and I really enjoyed it. So I can imagine that if somebody else has fun with it, it's even better for you. But there is a financial side. So there are professional software development studios. They have to earn some money somehow. And there is a tough side of game development. So around 10% of them, so professionally created games or maybe 20% so the real percentage doesn't really matter, but only a small amount of them is really successful or can be considered financially successful. And what does it mean for a studio? So if you are a game developer or a game developer studio, it means with one game, you have to earn enough money so that you can cover the costs of the nine other ones which are not successful or not that successful. So yeah, and so then we can see that moderate success is most of the time not enough. And the break even is actually way less than you want to have. So it's really a tough business game development. And you can think of Flappy Bird. I think nobody had ever thought about Flappy Bird being successful. And then it just somehow began or in the software world, there is Wikipedia and Microsoft and Cart around 10 to 15 years ago. Maybe nobody would have invested in Wikipedia where a bunch of volunteers are sharing their knowledge versus against the big software giant Microsoft having content editors, well-paid content editors published on CD-ROMs. You can buy it everywhere where Microsoft is in the store. And still Wikipedia succeeded. Microsoft and Cart just died. So how to deal with it or what can you do to be more sure or produce more successful games? So first thing is feedback is very important. You have to get feedback as early as you can. And if your game fails, then it should fail fast at the beginning. And it's also true for business software. So if your idea is not good enough, then it doesn't matter how much time you invest in it. Invest in it. It just going to fail or the probability of failing is quite high. So if it fails, then kill it early and go on. Otherwise you are just burning your resources. You are burning your mood, actually. So you have to go on. So in the gaming industry, there is, for example, Steam, if you know the logo. There are early access games. So game developers publish their games at an early phase of the development. And you can vote whether you like it. You can give maybe feature requests. You can tell about what you like, what you don't like. And it can also be done for normal software. You can choose out some beta testers or you can maybe ask some customers to take it as early as they can. So you get feedback and you can apply those changes before the release. Prototyping is also something which helps. You have prototyping. The only thing which matters is that you do it cheaply, quickly, so that you can decide it early in the development process, whether you keep it or kill it. You can even do it on paper, like this controller. So on paper, even on paper, you have a little feeling about what is it going to look like or feel like. Is it okay or is it not? And with the prototype, you should ask one question. So concentrate on the main question. What is your core mechanics? For example, in Mario, jumping is the core mechanics. So you have to concentrate on that one, whether jumping is fun enough or you can think of it being fun or it's just the idea was maybe well, but you cannot bring it into life. At Booga Games, there is a so-called heat filter. What they do is they prototype their games. So they create many prototypes, but actually for me, quite surprising, only around 20, 25% goes a stage further from prototyping into the real development. And as you can see on the picture, around 10% of the prototypes gets converted into a real game, which is then published. And then the audience decides whether it's good or not. So from 2D Boy Games, there is this approach. They build a prototype in under seven days because they were researching around this. And what they saw, it doesn't really matter whether you spend seven days or 14 days or maybe much more on your prototype. If in the first seven days, you cannot make it fun, you cannot make it good for your audience, then it just should be killed because the chances that you can do it with more time and more effort are very, very low. And I also think so it really applies for business software as well. So if we have a new idea and we want to bring the product at the website, whatever on the market, we also have to do some prototypes at my company. Actually we do it. So sometimes we even go with some paper prototypes to the nearest petrol station where we ask potential customers, so people who own a car or can drive a car, what do they think? Do they use that feature or that service so we can have a good feeling about what we are going to build or is it worth to build or should it just be killed and should we just go on? I have some famous prototypes for you. So for example, Mario, when Mario turned 25, the designer, game designer, Miyamoto actually told about that Mario was supposed to be a shooter. So like the emphasis was on shooting and not really on jumping. Actually also the button configuration was a little different. The jumping didn't have its own button, it was just the up arrow on the controller. And then they changed it. So they created some kind of prototypes and they saw that jumping is more fun and actually in Mario jumping is really complex. So you can just jump, but there is double jump. Then you are jumping, you can jump on the turtles, you can kill them, you can shoot them, you can stop them again and there are many, many things. You can get into the pipes but also get killed by the plants. So yeah, Mario changed significantly. There is also more to combat. It was supposed to be a Vandam game. So if you know the action from the action movies, Vandam, and Johnny Cage is supposed to be Vandam and he should have killed all the other characters and do all the time the famous kicks from Vandam. But then there were some licensing issues and also it was not that fun as they hoped it to be. So then they changed to have some fictional characters fighting each other. From the business world, actually it's not a software but still we can see an Apple One prototype. So without any casing or so, it's just on a wooden plate, cables bond together, but still you can see whether it makes sense or not. But really surprised me, Apple had an iPhone prototype really, really early. It was actually not mobile but still it had touch screen. There was a phone in it. Actually, I don't think any camera was there but still very interesting. So another technique with game developers, they create a game and it earns some money but they try to republish it on another platform. So like they try to have the code base as the same as possible for as many platforms as they can. So maybe they first use it to Xbox and then a few months later they port it to PlayStation. And with business software, it's also the case. So you can maybe publish your software as a desktop software. But what about if you publish it as a website or a web application like Adobe did it with Photoshop and Photoshop essential element, whatever it's called. Yeah, so or you create a website maybe and then you can package it into a Cordova app and publish it in the Google Play Store or Apple App Store. So you have minimal costs for republishing it and if it's not a really big hit but just a minor success on each platform, it still adds up and at the end you earn as much money or attention or whatever you want to have in some as you would earn with a big hit on just one platform. Another thing is user testing. It's for feedback and early feedback. You can invite the users to your company or maybe you can go to your users and see what they do. At my company, we do a lot of user testing. Usually we invite the users. They bring their smartphones and we can test out how and so but they think about the new feature on their own smartphones. And actually what we also do sometimes, we let us invite from by the users to their homes so that we can see how they behave at home because if you are at home, you sometimes do totally different things as being in the lab. For example, what we have seen, many people at home are sitting at the couch using iPad for browsing for used cars. Then maybe when there is the advertisement block in the film, they just go to the desktop PC or to the laptop. Then they look up again, one or two which they were just browsing on the iPad. Then they send it over and it's totally different when they are constrained to a single computer or a single device. So therefore my advice, if you don't have a user testing lab, you can still ask a game developer studio somewhere near to you because if you are a business developer, they are not your competitor. So it means they are more likely to help you setting it up and they have surely great experience with user testing. I think everybody knows feature creeps or at least every developer. Then new features are coming and it's never going to end and your product is delayed or you are sprint. You cannot commit anymore because you don't know whether you will be done at the end or not because feature keep changing. So I think everyone of us knows it. Great example, Duke Nukem. They changed the game engine many times, they rewrote the whole code base and whatever and they just couldn't reduce it for more than 10 years. What you can do is reduce your scope. If it's just too much, then leave it out and concentrate on the most important things because they are what matter. One example I kept seeing is if you are not sure what you should concentrate on, then you can think of your product. How would you advertise it on a DVD? Because games actually only have a DVD cover. You are in the game store. You are looking at the game. Maybe you haven't heard of it before. So you have a picture on the front side and three, maybe four screenshots at the back side and a few sentences. I have a few examples here. Also with the AAA, so the highest budget games, it's the same. So there is some artistic, so artwork at the front cover and a few screenshots at the back side. Actually, I have two grand theft auto here is just to show that they also do A-B testing, so which cover gets all the best. One more example. You can really see just a small amount of text, a few sentences, a few screenshots and that's it. Maybe an extreme case is where the text is maybe just a little bit too much, but the concept is still the same. And in business world or actually I have here an example from a Kickstarter campaign which can be anything, not just a game, but you can think of it as a, so your GitHub front page or read me file, you only have a sentence, maybe an image. There you have to sell your product, your module or whatever you have. Otherwise, the user just are going to leave. If they scroll further down and are reading all your content, then you can be quite lucky. So some juice, so what is game juice actually? It's, yeah, so every game needs it. So the definition, yeah, so your game feels live, so if you do something, the game responds to you. So camera shakes, explosion sounds, so that you have a better feeling. Actually I have a little demo here which I didn't create myself, but I really liked. I tried to show it. I hope that flash player once shut down because of the demo effect. Okay so quite interesting game I think, everybody wants to play with it, but even if I switch on little juice. Yeah so it's just better feeling and so it won't save your game if it's not fun, but if it's going to help a lot if you build in some kind of juice thingies. So little sound, vibration, explosion, camera shakes or whatever applies the best to the game. So and I think it's something we also can do in normal business software. For example, a very requested feature for Visual Studio 2012 was to bring back the colors because Microsoft somehow at the release forgot about colors and everything was gray and white and really many people were complaining about and they fixed it in a later release. So actually my idea is why shouldn't we use some juice in normal applications like vibration on a mobile app. When the user presses the button you can just vibrate it so you can make him feel better so you can make him want to press your call to action button. Or yeah on a mobile device you can maybe safely play some sounds to the button because if the sound is turned on you won't disturb the user and otherwise it's maybe just a little fun effect or it makes your user want to press that button. But it still applies so colors, maybe some kind of nice animations. You shouldn't overdo it like the example before that was definitely just too much but quite of it wouldn't hurt. So another thing which game developers have to fight against a lot are performance budgets. So games have to run quite fast on many hardware therefore they actually have set many types of budgets. So yeah so it's easier to make a fun game fast than otherwise but still game has to be fast otherwise the user is not going to play with it anymore because they just don't feel well enough. So there are some kind of time based budgets. So like I don't have real numbers because they are all under NDA for most of the consoles but there are some startup time limits. So you put in the disk and you have four seconds to display the first screen. You have limits, how much time it can take from transition to level one to level two and Microsoft, Sony they are measuring those times and if you cannot keep them then they won't give you the permission to publish the game with their logos and so on. So therefore the developers have to really take care of this. There are, it's also a time based budget but per frame. I think most of us know it, 60 frames a second is the refresh rate of most of the consumer monitors. So it means for the work you have at most 16 milliseconds. In a web game, in the browser you only have around eight because the other eight is for repainting the screen and if you want to keep 60 seconds which feels nicely for the user. So users want it although they don't tell you that they want it but otherwise you just feel bad for them. So there are some hardware based memory, network latency, yeah, like over Wi-Fi or 3G you have better vers latency and so on. And the thing is, so why I'm showing it is because it's easy to test against it. So there's a yes or no answer to the question, are you within the budget or outside of the budget? So there's no compla- so you cannot discuss it. If you are out then you have to do something. So for example, there's a new feature which makes your, you cannot hold your budget anymore because of the new feature. And you have to decide what can you leave out or is that feature important enough to be over your budget and maybe, for example, for a frame, if you cannot keep up with 60 frames, then is the feature important enough that in a few scenes it's going to be around 30? Maybe the answer is yes and then you just have to buy the bullet and do it, but quite often not. I have an example from a website here, page load time. So web performance is quite, it has hype right now around it. And here you have a new web font which makes your budget so too tight. And you have to decide do you really need it or you can just replace it with a system font or you can maybe kick out another font. Yeah, it's your decision. I have some programming techniques which I think since I've heard about them again a few years ago, I keep using more often. Actually, the one is the game loop. It's the heart of the game. So almost every game has a game loop or which has to draw something on the screen. Basically, sorry, yeah, the definition of the game loop. And so basically it looks like in every frame you process the inputs, then you update your game objects, whatever your game objects are, and then you render or generate some kind of output with some kind of pseudocode, yeah, process, update, render. And you can make it a little bit more complicated like if you have AI, so artificial intelligence or collision resolution or sounds, sounds as we see, as we have seen, the game juice are very important. Here I have a JavaScript example for many websites. There's request animation frame and it looks a little bit differently than in a C where you have threads and thread sleep and so on. But the idea is still the same. And I think game loop is not just for games. It can be used in every kind of software. Actually, I use it quite often on websites for animations or when the user is scrolling, you have maybe a box which sometimes crawls with the user, sometimes it stops on a prominent position and gives place for another one and then maybe goes on again. So you can just check the position and update your game objects which in this website's case are some boxes. So yeah, if you replace draw and render with some kind of business specific things, then you are there. So maybe an idea just to give you some feeling about it. So real time advertising or like Google AdSense or AdWords, there are every second many ads shown, users click on it and Google just collects all the data. Maybe they can use a game loop as well. So like process all the clicks and ads views and whatever for them matters. Update the earnings and spending because money goes from one side to the other side and the rest or percentage stays at Google. And yeah, then at the end you produce your outputs, you put it to DB or produce some kind of art defense. So it really looks like a job for me. But so it can run many times a second. Maybe it's enough if it runs once a minute, once an hour. But the concept is the same. One more thing I think I would use more often if I was a game developer. I'm using more often since I was doing this research are the state machines. I've known them for so since the university. But what I really like about them is the visualization. It's really easy. So you have states and you have transitions and transitions happen when you have events. So in this example, you have light bulb. It can be on or off. The events are pressing the switch. And so there's your application. In this case, the light bulb must be in a state in every moment of your runtime. Here, I draw myself one as a video player. It also has some states, some state transitions or some kind of events like it's loading. In the loading stage, it begins if it's after it's loaded, it can go directly to playing mode if auto plays active or it can just go to a not started and doing nothing state. And then there are some transitions between playing and post and vice versa. So the thing that I really like about this is so I work in teams in a team and this team is does not just consist of developers but there are QA colleagues, there are product managers, product owners, maybe other stakeholders, whatever you call it at your company. But I think they are quite powerful because the visualization is rather easy. You can show it to other people who maybe don't have a technical background like you. And it's rather easy to reason about or think about. You can just throw it on a whiteboard and you can talk to non-technical people about them. And I tried it out and for me, it really works. So non-technical people after a little coaching, so just telling them what it means. After a few minutes, they are capable to see the states and to understand what happens there and then the team just gets used to it and you can use it in meetings and the whole team is on the same page. Yeah, actually, a sister or brother of state machines are the behavior trees. Game developers use behavior trees quite often, mostly for artificial intelligence. Actually, behavior trees can be converted in state machines, state machines can be converted in behavior trees. Why I like it is also because of the visualization. So it's more complicated. So other colleagues need maybe more coaching from you to understand it, but after a while, they can get used to it. So I have an example here. There is a sequence node in a tree and this, so it means it tries to do the first thing. If it succeeds, then tries to do the other one and so on. But if it fails somewhere in between, then the whole node fails and the execution goes on in the tree. So I have a more complicated tree here. It starts with a sequence node. So first, we try to walk to the door and then there is a selector node. It tries to open the door first. So selector means at least one of them has to succeed to go on. So for this state to succeed. So you open the door. Maybe you do it, then it's fine and then you can go on, walk through the door and so again. But if you don't succeed, then you have another choice. You can unlock the door, open the door and then walk through and so on. But maybe you don't succeed with unlocking the door because the lock is just too good for your skills in the game. Then you just smash in the door and then just go on. Maybe if you fail to smash the door, then the whole tree which we see fail, it bubbles up to the root node and then the AI cannot do any further here. So and the thing I really like about behavior trees is the extendability. So you have nodes and you can replace the nodes with more complicated subtrees or you can just execute the tree or just a sub tree of it as you like or as your situation expects it. So I have a few resources which I collected throughout the preparation process for this talk. It's actually on GitHub, large list of links. You can just grab the link. I will post it afterwards on Twitter. There are some things which I wanted to show. Is first how I got here or actually on Reddit there is a great community around game development. If you are interested in the topic, I really recommend to take a look at there. There are quite interesting articles, questions and answers. It's a really good source for game development topics. So there are two books I read. The first one is from Robert Neistrom. It's called Game Programming Patterns. It's really good written. I can recommend it to you to read it. There are more about game loops, also state machines, how to handle the state in games. There are many things about entity component patterns, also sample code. And there is game programming algorithms and techniques from Sanjay Madhav. It's also very good and also more related to programming. But without the code samples, it's also still worth to read. So what we have seen is that success is not predictable neither in the gaming industry nor in business software. So there are some techniques which we can do against it or to have better success rates. There were, for example, prototyping to collect feedback as early and as often as possible. There were user testing, setting up, test lab. And then I should use some techniques or that little demo about game juice that juice is very important because it makes your game or your software just better, just to feel better. So it won't help you if your software is bad, but if your software is good, it will make it better. I've shown you some examples about feature creep. So Duke Nukem and to reduce the scope, there were those DVD covers and also the feature budgets which help you to decide whether to keep the feature or kill the feature. And then some things like game loop and the state machines. So yeah, that's it, actually, what I wanted to tell you. And I really encourage everybody to look out for other industries, how things work there because there's always a great chance to learn something from them and to import it into your field where you are working, where you feel comfortable, where you are at home. So the slides are also on GitHub pages. I will tweet about it after the talk, but you can find them there. And you can find me on the Internet. I have website, email address, everything. So thank you very much. And I think we still have a few time for questions and lunch is almost there. Thank you. So questions, maybe? Okay. Thanks. Sorry I, I don't know why I need to run myself here.
 So, hi everyone, can you hear me?  Ah, yeah, it's fine.  So thank you for joining my talk about, so I would like to share with you some thoughts  about what I learned from game developers and game development.  I myself, I'm not a game developer, I'm a normal business, so I'm on the business side,  I'm developing websites at Autoskott24 in Germany.  It's Europe's biggest used car portal.  So actually, what I will present to you today is what I collected in the last one or two  years.  It was some kind of hobby research, if I can say so.  And I think we can learn many things from game developers, studios, the developers,  how they work together, the teams and so on.  But first, before we start, just a question.  So are here any gamers or anybody who enjoys playing games?  So, wow, that's great.  What I was hoping for.  And is here somebody who tried to develop a game?  Wow, that's very nice.  And who considered it as a success?  So that's whatever success to you means.  So I've never succeeded with the game, I have to admit.  But maybe anybody of you?  Ah, yeah, a few but not that much.  Okay, then, so my question was, what would change if I began developing my software like  a game?  What could I do?  And there I found some interesting things which I want to share with you.  And here's the agenda that we are going to do today.  So first I have a little quiz, so just that we get in the mood.  And then we'll talk about success in games, game development, about prototyping, feature  creep, game choose, and maybe some programming techniques at the end if we still have enough  time.  So then let's begin with the quiz.  So I'll show you an image.  One maybe one, two, three, and then you have to just shout out loudly.  But the game, so in this case it's obviously, it stands on the screen, it's Mario Kart.  So this one is also quite simple, one, two, three.  Yeah.  Okay.  So this one, I'm also sure almost everybody heard about it.  One, two, three.  Yeah, Flappy Bird.  It is.  Yeah, exactly.  So this one is maybe a little bit harder, but there were hardcore audience for this game.  Actually, it's not a hardcore game, but the audience was really hardcore and spending  very, very much time.  So one, two, three.  Yeah, it's really fun.  Okay.  So some nostalgic one from early 90s or end of the 80s.  Yeah, maybe one more hint.  So one, two, three.  Wow, you are great.  Okay.  This one is quite modern, but still a few years old.  One, two, three.  Yeah.  I need first speed, but which one?  Okay.  It's the most wanted and the better one.  So around 10 years ago.  Okay.  I'm sure you also know this one, one, two, three.  Yeah.  It's more to combat.  Okay.  This one is also quite well known.  One, two, three.  Yeah.  And also the real one.  So and this one is actually, but I played the most.  I have to admit I, so actually many people are playing it around 6 million in the world,  but I don't know whether somebody knows this one here.  So one, two, three.  Yeah.  Trackmania.  Yeah.  Beautiful.  Okay.  So now we are in the mood.  So let's talk about success.  What does that mean?  So there is a romantic answer, which is if somebody has fun with your game.  So like your significant other or your mom and you see them smiling and then you are  also quite happy and maybe it's not just the two of them, but around a few thousand people  or maybe millions.  So yeah, that's actually, as I've heard, a very cool thing.  Or when I developed games for, so during the development, I was playing with them a lot  and I really enjoyed it.  So I can imagine that if somebody else has fun with it, it's even better for you.  But there is a financial side.  So there are professional software development studios.  They have to earn some money somehow.  And there is a tough side of game development.  So around 10% of them, so professionally created games or maybe 20% so the real percentage  doesn't really matter, but only a small amount of them is really successful or can be considered  financially successful.  And what does it mean for a studio?  So if you are a game developer or a game developer studio, it means with one game, you have to  earn enough money so that you can cover the costs of the nine other ones which are not  successful or not that successful.  So yeah, and so then we can see that moderate success is most of the time not enough.  And the break even is actually way less than you want to have.  So it's really a tough business game development.  And you can think of Flappy Bird.  I think nobody had ever thought about Flappy Bird being successful.  And then it just somehow began or in the software world, there is Wikipedia and Microsoft and  Cart around 10 to 15 years ago.  Maybe nobody would have invested in Wikipedia where a bunch of volunteers are sharing their  knowledge versus against the big software giant Microsoft having content editors, well-paid  content editors published on CD-ROMs.  You can buy it everywhere where Microsoft is in the store.  And still Wikipedia succeeded.  Microsoft and Cart just died.  So how to deal with it or what can you do to be more sure or produce more successful  games?  So first thing is feedback is very important.  You have to get feedback as early as you can.  And if your game fails, then it should fail fast at the beginning.  And it's also true for business software.  So if your idea is not good enough, then it doesn't matter how much time you invest in  it.  Invest in it.  It just going to fail or the probability of failing is quite high.  So if it fails, then kill it early and go on.  Otherwise you are just burning your resources.  You are burning your mood, actually.  So you have to go on.  So in the gaming industry, there is, for example, Steam, if you know the logo.  There are early access games.  So game developers publish their games at an early phase of the development.  And you can vote whether you like it.  You can give maybe feature requests.  You can tell about what you like, what you don't like.  And it can also be done for normal software.  You can choose out some beta testers or you can maybe ask some customers to take it as  early as they can.  So you get feedback and you can apply those changes before the release.  Prototyping is also something which helps.  You have prototyping.  The only thing which matters is that you do it cheaply, quickly, so that you can decide  it early in the development process, whether you keep it or kill it.  You can even do it on paper, like this controller.  So on paper, even on paper, you have a little feeling about what is it going to look like  or feel like.  Is it okay or is it not?  And with the prototype, you should ask one question.  So concentrate on the main question.  What is your core mechanics?  For example, in Mario, jumping is the core mechanics.  So you have to concentrate on that one, whether jumping is fun enough or you can think of it  being fun or it's just the idea was maybe well, but you cannot bring it into life.  At Booga Games, there is a so-called heat filter.  What they do is they prototype their games.  So they create many prototypes, but actually for me, quite surprising, only around 20,  25% goes a stage further from prototyping into the real development.  And as you can see on the picture, around 10% of the prototypes gets converted into  a real game, which is then published.  And then the audience decides whether it's good or not.  So from 2D Boy Games, there is this approach.  They build a prototype in under seven days because they were researching around this.  And what they saw, it doesn't really matter whether you spend seven days or 14 days or  maybe much more on your prototype.  If in the first seven days, you cannot make it fun, you cannot make it good for your audience,  then it just should be killed because the chances that you can do it with more time  and more effort are very, very low.  And I also think so it really applies for business software as well.  So if we have a new idea and we want to bring the product at the website, whatever on the  market, we also have to do some prototypes at my company.  Actually we do it.  So sometimes we even go with some paper prototypes to the nearest petrol station where we ask  potential customers, so people who own a car or can drive a car, what do they think?  Do they use that feature or that service so we can have a good feeling about what we are  going to build or is it worth to build or should it just be killed and should we just  go on?  I have some famous prototypes for you.  So for example, Mario, when Mario turned 25, the designer, game designer, Miyamoto actually  told about that Mario was supposed to be a shooter.  So like the emphasis was on shooting and not really on jumping.  Actually also the button configuration was a little different.  The jumping didn't have its own button, it was just the up arrow on the controller.  And then they changed it.  So they created some kind of prototypes and they saw that jumping is more fun and actually  in Mario jumping is really complex.  So you can just jump, but there is double jump.  Then you are jumping, you can jump on the turtles, you can kill them, you can shoot them,  you can stop them again and there are many, many things.  You can get into the pipes but also get killed by the plants.  So yeah, Mario changed significantly.  There is also more to combat.  It was supposed to be a Vandam game.  So if you know the action from the action movies, Vandam, and Johnny Cage is supposed  to be Vandam and he should have killed all the other characters and do all the time the  famous kicks from Vandam.  But then there were some licensing issues and also it was not that fun as they hoped  it to be.  So then they changed to have some fictional characters fighting each other.  From the business world, actually it's not a software but still we can see an Apple One  prototype.  So without any casing or so, it's just on a wooden plate, cables bond together, but still  you can see whether it makes sense or not.  But really surprised me, Apple had an iPhone prototype really, really early.  It was actually not mobile but still it had touch screen.  There was a phone in it.  Actually, I don't think any camera was there but still very interesting.  So another technique with game developers, they create a game and it earns some money  but they try to republish it on another platform.  So like they try to have the code base as the same as possible for as many platforms  as they can.  So maybe they first use it to Xbox and then a few months later they port it to PlayStation.  And with business software, it's also the case.  So you can maybe publish your software as a desktop software.  But what about if you publish it as a website or a web application like Adobe did it with  Photoshop and Photoshop essential element, whatever it's called.  Yeah, so or you create a website maybe and then you can package it into a Cordova app  and publish it in the Google Play Store or Apple App Store.  So you have minimal costs for republishing it and if it's not a really big hit but just  a minor success on each platform, it still adds up and at the end you earn as much money  or attention or whatever you want to have in some as you would earn with a big hit on  just one platform.  Another thing is user testing.  It's for feedback and early feedback.  You can invite the users to your company or maybe you can go to your users and see what  they do.  At my company, we do a lot of user testing.  Usually we invite the users.  They bring their smartphones and we can test out how and so but they think about the new  feature on their own smartphones.  And actually what we also do sometimes, we let us invite from by the users to their homes  so that we can see how they behave at home because if you are at home, you sometimes  do totally different things as being in the lab.  For example, what we have seen, many people at home are sitting at the couch using iPad  for browsing for used cars.  Then maybe when there is the advertisement block in the film, they just go to the desktop  PC or to the laptop.  Then they look up again, one or two which they were just browsing on the iPad.  Then they send it over and it's totally different when they are constrained to a single computer  or a single device.  So therefore my advice, if you don't have a user testing lab, you can still ask a game  developer studio somewhere near to you because if you are a business developer, they are  not your competitor.  So it means they are more likely to help you setting it up and they have surely great  experience with user testing.  I think everybody knows feature creeps or at least every developer.  Then new features are coming and it's never going to end and your product is delayed or  you are sprint.  You cannot commit anymore because you don't know whether you will be done at the end or  not because feature keep changing.  So I think everyone of us knows it.  Great example, Duke Nukem.  They changed the game engine many times, they rewrote the whole code base and whatever  and they just couldn't reduce it for more than 10 years.  What you can do is reduce your scope.  If it's just too much, then leave it out and concentrate on the most important things  because they are what matter.  One example I kept seeing is if you are not sure what you should concentrate on, then  you can think of your product.  How would you advertise it on a DVD?  Because games actually only have a DVD cover.  You are in the game store.  You are looking at the game.  Maybe you haven't heard of it before.  So you have a picture on the front side and three, maybe four screenshots at the back  side and a few sentences.  I have a few examples here.  Also with the AAA, so the highest budget games, it's the same.  So there is some artistic, so artwork at the front cover and a few screenshots at the back  side.  Actually, I have two grand theft auto here is just to show that they also do A-B testing,  so which cover gets all the best.  One more example.  You can really see just a small amount of text, a few sentences, a few screenshots and  that's it.  Maybe an extreme case is where the text is maybe just a little bit too much, but the  concept is still the same.  And in business world or actually I have here an example from a Kickstarter campaign which  can be anything, not just a game, but you can think of it as a, so your GitHub front  page or read me file, you only have a sentence, maybe an image.  There you have to sell your product, your module or whatever you have.  Otherwise, the user just are going to leave.  If they scroll further down and are reading all your content, then you can be quite lucky.  So some juice, so what is game juice actually?  It's, yeah, so every game needs it.  So the definition, yeah, so your game feels live, so if you do something, the game responds  to you.  So camera shakes, explosion sounds, so that you have a better feeling.  Actually I have a little demo here which I didn't create myself, but I really liked.  I tried to show it.  I hope that flash player once shut down because of the demo effect.  Okay so quite interesting game I think, everybody wants to play with it, but even if I switch  on little juice.  Yeah so it's just better feeling and so it won't save your game if it's not fun, but  if it's going to help a lot if you build in some kind of juice thingies.  So little sound, vibration, explosion, camera shakes or whatever applies the best to the  game.  So and I think it's something we also can do in normal business software.  For example, a very requested feature for Visual Studio 2012 was to bring back the colors  because Microsoft somehow at the release forgot about colors and everything was gray and white  and really many people were complaining about and they fixed it in a later release.  So actually my idea is why shouldn't we use some juice in normal applications like vibration  on a mobile app.  When the user presses the button you can just vibrate it so you can make him feel better  so you can make him want to press your call to action button.  Or yeah on a mobile device you can maybe safely play some sounds to the button because if  the sound is turned on you won't disturb the user and otherwise it's maybe just a little  fun effect or it makes your user want to press that button.  But it still applies so colors, maybe some kind of nice animations.  You shouldn't overdo it like the example before that was definitely just too much but quite  of it wouldn't hurt.  So another thing which game developers have to fight against a lot are performance budgets.  So games have to run quite fast on many hardware therefore they actually have set many types  of budgets.  So yeah so it's easier to make a fun game fast than otherwise but still game has to be fast  otherwise the user is not going to play with it anymore because they just don't feel well  enough.  So there are some kind of time based budgets.  So like I don't have real numbers because they are all under NDA for most of the consoles  but there are some startup time limits.  So you put in the disk and you have four seconds to display the first screen.  You have limits, how much time it can take from transition to level one to level two  and Microsoft, Sony they are measuring those times and if you cannot keep them then they  won't give you the permission to publish the game with their logos and so on.  So therefore the developers have to really take care of this.  There are, it's also a time based budget but per frame.  I think most of us know it, 60 frames a second is the refresh rate of most of the consumer  monitors.  So it means for the work you have at most 16 milliseconds.  In a web game, in the browser you only have around eight because the other eight is for  repainting the screen and if you want to keep 60 seconds which feels nicely for the user.  So users want it although they don't tell you that they want it but otherwise you just  feel bad for them.  So there are some hardware based memory, network latency, yeah, like over Wi-Fi or 3G you  have better vers latency and so on.  And the thing is, so why I'm showing it is because it's easy to test against it.  So there's a yes or no answer to the question, are you within the budget or outside of the  budget?  So there's no compla- so you cannot discuss it.  If you are out then you have to do something.  So for example, there's a new feature which makes your, you cannot hold your budget anymore  because of the new feature.  And you have to decide what can you leave out or is that feature important enough to  be over your budget and maybe, for example, for a frame, if you cannot keep up with 60  frames, then is the feature important enough that in a few scenes it's going to be around  30?  Maybe the answer is yes and then you just have to buy the bullet and do it, but quite  often not.  I have an example from a website here, page load time.  So web performance is quite, it has hype right now around it.  And here you have a new web font which makes your budget so too tight.  And you have to decide do you really need it or you can just replace it with a system  font or you can maybe kick out another font.  Yeah, it's your decision.  I have some programming techniques which I think since I've heard about them again a  few years ago, I keep using more often.  Actually, the one is the game loop.  It's the heart of the game.  So almost every game has a game loop or which has to draw something on the screen.  Basically, sorry, yeah, the definition of the game loop.  And so basically it looks like in every frame you process the inputs, then you update your  game objects, whatever your game objects are, and then you render or generate some kind  of output with some kind of pseudocode, yeah, process, update, render.  And you can make it a little bit more complicated like if you have AI, so artificial intelligence  or collision resolution or sounds, sounds as we see, as we have seen, the game juice  are very important.  Here I have a JavaScript example for many websites.  There's request animation frame and it looks a little bit differently than in a C where  you have threads and thread sleep and so on.  But the idea is still the same.  And I think game loop is not just for games.  It can be used in every kind of software.  Actually, I use it quite often on websites for animations or when the user is scrolling,  you have maybe a box which sometimes crawls with the user, sometimes it stops on a prominent  position and gives place for another one and then maybe goes on again.  So you can just check the position and update your game objects which in this website's  case are some boxes.  So yeah, if you replace draw and render with some kind of business specific things, then  you are there.  So maybe an idea just to give you some feeling about it.  So real time advertising or like Google AdSense or AdWords, there are every second many ads  shown, users click on it and Google just collects all the data.  Maybe they can use a game loop as well.  So like process all the clicks and ads views and whatever for them matters.  Update the earnings and spending because money goes from one side to the other side and the  rest or percentage stays at Google.  And yeah, then at the end you produce your outputs, you put it to DB or produce some kind  of art defense.  So it really looks like a job for me.  But so it can run many times a second.  Maybe it's enough if it runs once a minute, once an hour.  But the concept is the same.  One more thing I think I would use more often if I was a game developer.  I'm using more often since I was doing this research are the state machines.  I've known them for so since the university.  But what I really like about them is the visualization.  It's really easy.  So you have states and you have transitions and transitions happen when you have events.  So in this example, you have light bulb.  It can be on or off.  The events are pressing the switch.  And so there's your application.  In this case, the light bulb must be in a state in every moment of your runtime.  Here, I draw myself one as a video player.  It also has some states, some state transitions or some kind of events like it's loading.  In the loading stage, it begins if it's after it's loaded, it can go directly to playing  mode if auto plays active or it can just go to a not started and doing nothing state.  And then there are some transitions between playing and post and vice versa.  So the thing that I really like about this is so I work in teams in a team and this team  is does not just consist of developers but there are QA colleagues, there are product  managers, product owners, maybe other stakeholders, whatever you call it at your company.  But I think they are quite powerful because the visualization is rather easy.  You can show it to other people who maybe don't have a technical background like you.  And it's rather easy to reason about or think about.  You can just throw it on a whiteboard and you can talk to non-technical people about  them.  And I tried it out and for me, it really works.  So non-technical people after a little coaching, so just telling them what it means.  After a few minutes, they are capable to see the states and to understand what happens  there and then the team just gets used to it and you can use it in meetings and the  whole team is on the same page.  Yeah, actually, a sister or brother of state machines are the behavior trees.  Game developers use behavior trees quite often, mostly for artificial intelligence.  Actually, behavior trees can be converted in state machines, state machines can be converted  in behavior trees.  Why I like it is also because of the visualization.  So it's more complicated.  So other colleagues need maybe more coaching from you to understand it, but after a while,  they can get used to it.  So I have an example here.  There is a sequence node in a tree and this, so it means it tries to do the first thing.  If it succeeds, then tries to do the other one and so on.  But if it fails somewhere in between, then the whole node fails and the execution goes  on in the tree.  So I have a more complicated tree here.  It starts with a sequence node.  So first, we try to walk to the door and then there is a selector node.  It tries to open the door first.  So selector means at least one of them has to succeed to go on.  So for this state to succeed.  So you open the door.  Maybe you do it, then it's fine and then you can go on, walk through the door and so again.  But if you don't succeed, then you have another choice.  You can unlock the door, open the door and then walk through and so on.  But maybe you don't succeed with unlocking the door because the lock is just too good  for your skills in the game.  Then you just smash in the door and then just go on.  Maybe if you fail to smash the door, then the whole tree which we see fail, it bubbles  up to the root node and then the AI cannot do any further here.  So and the thing I really like about behavior trees is the extendability.  So you have nodes and you can replace the nodes with more complicated subtrees or you  can just execute the tree or just a sub tree of it as you like or as your situation expects  it.  So I have a few resources which I collected throughout the preparation process for this  talk.  It's actually on GitHub, large list of links.  You can just grab the link.  I will post it afterwards on Twitter.  There are some things which I wanted to show.  Is first how I got here or actually on Reddit there is a great community around game development.  If you are interested in the topic, I really recommend to take a look at there.  There are quite interesting articles, questions and answers.  It's a really good source for game development topics.  So there are two books I read.  The first one is from Robert Neistrom.  It's called Game Programming Patterns.  It's really good written.  I can recommend it to you to read it.  There are more about game loops, also state machines, how to handle the state in games.  There are many things about entity component patterns, also sample code.  And there is game programming algorithms and techniques from Sanjay Madhav.  It's also very good and also more related to programming.  But without the code samples, it's also still worth to read.  So what we have seen is that success is not predictable neither in the gaming industry  nor in business software.  So there are some techniques which we can do against it or to have better success rates.  There were, for example, prototyping to collect feedback as early and as often as possible.  There were user testing, setting up, test lab.  And then I should use some techniques or that little demo about game juice that juice is  very important because it makes your game or your software just better, just to feel  better.  So it won't help you if your software is bad, but if your software is good, it will make  it better.  I've shown you some examples about feature creep.  So Duke Nukem and to reduce the scope, there were those DVD covers and also the feature  budgets which help you to decide whether to keep the feature or kill the feature.  And then some things like game loop and the state machines.  So yeah, that's it, actually, what I wanted to tell you.  And I really encourage everybody to look out for other industries, how things work there  because there's always a great chance to learn something from them and to import it into  your field where you are working, where you feel comfortable, where you are at home.  So the slides are also on GitHub pages.  I will tweet about it after the talk, but you can find them there.  And you can find me on the Internet.  I have website, email address, everything.  So thank you very much.  And I think we still have a few time for questions and lunch is almost there.  Thank you.  So questions, maybe?  Okay.  Thanks.  Sorry I, I don't know why I need to run myself here.
What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_0_227.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_228_2759.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_2760_4067.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_4068_4403.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_4404_5651.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_5652_5819.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_5820_6347.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_6348_6551.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_6552_6731.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_6732_6851.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_6852_7607.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_7608_10583.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_10584_11975.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_11976_13355.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_13356_14615.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_14616_15215.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_15216_15623.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_15624_17603.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_17604_20147.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_20148_21947.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_21948_22991.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_22992_23555.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_23556_24095.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_24096_26651.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_26652_29027.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_29028_30359.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_30360_30707.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_30708_31535.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_31536_32087.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_32088_32447.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_32448_32843.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_32844_33143.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_33144_33431.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_33432_34523.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_34524_34727.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_34728_36215.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_36216_36311.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_36312_36659.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_36660_37139.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_37140_37367.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_37368_37787.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_37788_38351.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_38352_39959.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_39960_40547.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_40548_41087.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_41088_42383.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_42384_43391.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_43392_45551.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_45552_46331.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_46332_46739.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_46740_47267.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_47268_47687.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_47688_51911.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_51912_52559.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_52560_53543.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_53544_56759.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_56760_57611.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_57612_58811.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_58812_60851.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_60852_61655.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_61656_62267.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_62268_63047.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_63048_63827.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_63828_64283.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_64284_66443.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_66444_68135.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_68136_68183.png What_business_software_developers_can_learn_from_game_developers_-_Adam_Beres-Deak_68184_74196.png
So, hi everyone, can you hear me? Ah, yeah, it's fine. So thank you for joining my talk about, so I would like to share with you some thoughts about what I learned from game developers and game development. I myself, I'm not a game developer, I'm a normal business, so I'm on the business side, I'm developing websites at Autoskott24 in Germany. It's Europe's biggest used car portal. So actually, what I will present to you today is what I collected in the last one or two years. It was some kind of hobby research, if I can say so. And I think we can learn many things from game developers, studios, the developers, how they work together, the teams and so on. But first, before we start, just a question. So are here any gamers or anybody who enjoys playing games? So, wow, that's great. What I was hoping for. And is here somebody who tried to develop a game? Wow, that's very nice. And who considered it as a success? So that's whatever success to you means. So I've never succeeded with the game, I have to admit. But maybe anybody of you? Ah, yeah, a few but not that much. Okay, then, so my question was, what would change if I began developing my software like a game? What could I do? And there I found some interesting things which I want to share with you. And here's the agenda that we are going to do today. So first I have a little quiz, so just that we get in the mood. And then we'll talk about success in games, game development, about prototyping, feature creep, game choose, and maybe some programming techniques at the end if we still have enough time. So then let's begin with the quiz. So I'll show you an image. One maybe one, two, three, and then you have to just shout out loudly. But the game, so in this case it's obviously, it stands on the screen, it's Mario Kart. So this one is also quite simple, one, two, three. Yeah. Okay. So this one, I'm also sure almost everybody heard about it. One, two, three. Yeah, Flappy Bird. It is. Yeah, exactly. So this one is maybe a little bit harder, but there were hardcore audience for this game. Actually, it's not a hardcore game, but the audience was really hardcore and spending very, very much time. So one, two, three. Yeah, it's really fun. Okay. So some nostalgic one from early 90s or end of the 80s. Yeah, maybe one more hint. So one, two, three. Wow, you are great. Okay. This one is quite modern, but still a few years old. One, two, three. Yeah. I need first speed, but which one? Okay. It's the most wanted and the better one. So around 10 years ago. Okay. I'm sure you also know this one, one, two, three. Yeah. It's more to combat. Okay. This one is also quite well known. One, two, three. Yeah. And also the real one. So and this one is actually, but I played the most. I have to admit I, so actually many people are playing it around 6 million in the world, but I don't know whether somebody knows this one here. So one, two, three. Yeah. Trackmania. Yeah. Beautiful. Okay. So now we are in the mood. So let's talk about success. What does that mean? So there is a romantic answer, which is if somebody has fun with your game. So like your significant other or your mom and you see them smiling and then you are also quite happy and maybe it's not just the two of them, but around a few thousand people or maybe millions. So yeah, that's actually, as I've heard, a very cool thing. Or when I developed games for, so during the development, I was playing with them a lot and I really enjoyed it. So I can imagine that if somebody else has fun with it, it's even better for you. But there is a financial side. So there are professional software development studios. They have to earn some money somehow. And there is a tough side of game development. So around 10% of them, so professionally created games or maybe 20% so the real percentage doesn't really matter, but only a small amount of them is really successful or can be considered financially successful. And what does it mean for a studio? So if you are a game developer or a game developer studio, it means with one game, you have to earn enough money so that you can cover the costs of the nine other ones which are not successful or not that successful. So yeah, and so then we can see that moderate success is most of the time not enough. And the break even is actually way less than you want to have. So it's really a tough business game development. And you can think of Flappy Bird. I think nobody had ever thought about Flappy Bird being successful. And then it just somehow began or in the software world, there is Wikipedia and Microsoft and Cart around 10 to 15 years ago. Maybe nobody would have invested in Wikipedia where a bunch of volunteers are sharing their knowledge versus against the big software giant Microsoft having content editors, well-paid content editors published on CD-ROMs. You can buy it everywhere where Microsoft is in the store. And still Wikipedia succeeded. Microsoft and Cart just died. So how to deal with it or what can you do to be more sure or produce more successful games? So first thing is feedback is very important. You have to get feedback as early as you can. And if your game fails, then it should fail fast at the beginning. And it's also true for business software. So if your idea is not good enough, then it doesn't matter how much time you invest in it. Invest in it. It just going to fail or the probability of failing is quite high. So if it fails, then kill it early and go on. Otherwise you are just burning your resources. You are burning your mood, actually. So you have to go on. So in the gaming industry, there is, for example, Steam, if you know the logo. There are early access games. So game developers publish their games at an early phase of the development. And you can vote whether you like it. You can give maybe feature requests. You can tell about what you like, what you don't like. And it can also be done for normal software. You can choose out some beta testers or you can maybe ask some customers to take it as early as they can. So you get feedback and you can apply those changes before the release. Prototyping is also something which helps. You have prototyping. The only thing which matters is that you do it cheaply, quickly, so that you can decide it early in the development process, whether you keep it or kill it. You can even do it on paper, like this controller. So on paper, even on paper, you have a little feeling about what is it going to look like or feel like. Is it okay or is it not? And with the prototype, you should ask one question. So concentrate on the main question. What is your core mechanics? For example, in Mario, jumping is the core mechanics. So you have to concentrate on that one, whether jumping is fun enough or you can think of it being fun or it's just the idea was maybe well, but you cannot bring it into life. At Booga Games, there is a so-called heat filter. What they do is they prototype their games. So they create many prototypes, but actually for me, quite surprising, only around 20, 25% goes a stage further from prototyping into the real development. And as you can see on the picture, around 10% of the prototypes gets converted into a real game, which is then published. And then the audience decides whether it's good or not. So from 2D Boy Games, there is this approach. They build a prototype in under seven days because they were researching around this. And what they saw, it doesn't really matter whether you spend seven days or 14 days or maybe much more on your prototype. If in the first seven days, you cannot make it fun, you cannot make it good for your audience, then it just should be killed because the chances that you can do it with more time and more effort are very, very low. And I also think so it really applies for business software as well. So if we have a new idea and we want to bring the product at the website, whatever on the market, we also have to do some prototypes at my company. Actually we do it. So sometimes we even go with some paper prototypes to the nearest petrol station where we ask potential customers, so people who own a car or can drive a car, what do they think? Do they use that feature or that service so we can have a good feeling about what we are going to build or is it worth to build or should it just be killed and should we just go on? I have some famous prototypes for you. So for example, Mario, when Mario turned 25, the designer, game designer, Miyamoto actually told about that Mario was supposed to be a shooter. So like the emphasis was on shooting and not really on jumping. Actually also the button configuration was a little different. The jumping didn't have its own button, it was just the up arrow on the controller. And then they changed it. So they created some kind of prototypes and they saw that jumping is more fun and actually in Mario jumping is really complex. So you can just jump, but there is double jump. Then you are jumping, you can jump on the turtles, you can kill them, you can shoot them, you can stop them again and there are many, many things. You can get into the pipes but also get killed by the plants. So yeah, Mario changed significantly. There is also more to combat. It was supposed to be a Vandam game. So if you know the action from the action movies, Vandam, and Johnny Cage is supposed to be Vandam and he should have killed all the other characters and do all the time the famous kicks from Vandam. But then there were some licensing issues and also it was not that fun as they hoped it to be. So then they changed to have some fictional characters fighting each other. From the business world, actually it's not a software but still we can see an Apple One prototype. So without any casing or so, it's just on a wooden plate, cables bond together, but still you can see whether it makes sense or not. But really surprised me, Apple had an iPhone prototype really, really early. It was actually not mobile but still it had touch screen. There was a phone in it. Actually, I don't think any camera was there but still very interesting. So another technique with game developers, they create a game and it earns some money but they try to republish it on another platform. So like they try to have the code base as the same as possible for as many platforms as they can. So maybe they first use it to Xbox and then a few months later they port it to PlayStation. And with business software, it's also the case. So you can maybe publish your software as a desktop software. But what about if you publish it as a website or a web application like Adobe did it with Photoshop and Photoshop essential element, whatever it's called. Yeah, so or you create a website maybe and then you can package it into a Cordova app and publish it in the Google Play Store or Apple App Store. So you have minimal costs for republishing it and if it's not a really big hit but just a minor success on each platform, it still adds up and at the end you earn as much money or attention or whatever you want to have in some as you would earn with a big hit on just one platform. Another thing is user testing. It's for feedback and early feedback. You can invite the users to your company or maybe you can go to your users and see what they do. At my company, we do a lot of user testing. Usually we invite the users. They bring their smartphones and we can test out how and so but they think about the new feature on their own smartphones. And actually what we also do sometimes, we let us invite from by the users to their homes so that we can see how they behave at home because if you are at home, you sometimes do totally different things as being in the lab. For example, what we have seen, many people at home are sitting at the couch using iPad for browsing for used cars. Then maybe when there is the advertisement block in the film, they just go to the desktop PC or to the laptop. Then they look up again, one or two which they were just browsing on the iPad. Then they send it over and it's totally different when they are constrained to a single computer or a single device. So therefore my advice, if you don't have a user testing lab, you can still ask a game developer studio somewhere near to you because if you are a business developer, they are not your competitor. So it means they are more likely to help you setting it up and they have surely great experience with user testing. I think everybody knows feature creeps or at least every developer. Then new features are coming and it's never going to end and your product is delayed or you are sprint. You cannot commit anymore because you don't know whether you will be done at the end or not because feature keep changing. So I think everyone of us knows it. Great example, Duke Nukem. They changed the game engine many times, they rewrote the whole code base and whatever and they just couldn't reduce it for more than 10 years. What you can do is reduce your scope. If it's just too much, then leave it out and concentrate on the most important things because they are what matter. One example I kept seeing is if you are not sure what you should concentrate on, then you can think of your product. How would you advertise it on a DVD? Because games actually only have a DVD cover. You are in the game store. You are looking at the game. Maybe you haven't heard of it before. So you have a picture on the front side and three, maybe four screenshots at the back side and a few sentences. I have a few examples here. Also with the AAA, so the highest budget games, it's the same. So there is some artistic, so artwork at the front cover and a few screenshots at the back side. Actually, I have two grand theft auto here is just to show that they also do A-B testing, so which cover gets all the best. One more example. You can really see just a small amount of text, a few sentences, a few screenshots and that's it. Maybe an extreme case is where the text is maybe just a little bit too much, but the concept is still the same. And in business world or actually I have here an example from a Kickstarter campaign which can be anything, not just a game, but you can think of it as a, so your GitHub front page or read me file, you only have a sentence, maybe an image. There you have to sell your product, your module or whatever you have. Otherwise, the user just are going to leave. If they scroll further down and are reading all your content, then you can be quite lucky. So some juice, so what is game juice actually? It's, yeah, so every game needs it. So the definition, yeah, so your game feels live, so if you do something, the game responds to you. So camera shakes, explosion sounds, so that you have a better feeling. Actually I have a little demo here which I didn't create myself, but I really liked. I tried to show it. I hope that flash player once shut down because of the demo effect. Okay so quite interesting game I think, everybody wants to play with it, but even if I switch on little juice. Yeah so it's just better feeling and so it won't save your game if it's not fun, but if it's going to help a lot if you build in some kind of juice thingies. So little sound, vibration, explosion, camera shakes or whatever applies the best to the game. So and I think it's something we also can do in normal business software. For example, a very requested feature for Visual Studio 2012 was to bring back the colors because Microsoft somehow at the release forgot about colors and everything was gray and white and really many people were complaining about and they fixed it in a later release. So actually my idea is why shouldn't we use some juice in normal applications like vibration on a mobile app. When the user presses the button you can just vibrate it so you can make him feel better so you can make him want to press your call to action button. Or yeah on a mobile device you can maybe safely play some sounds to the button because if the sound is turned on you won't disturb the user and otherwise it's maybe just a little fun effect or it makes your user want to press that button. But it still applies so colors, maybe some kind of nice animations. You shouldn't overdo it like the example before that was definitely just too much but quite of it wouldn't hurt. So another thing which game developers have to fight against a lot are performance budgets. So games have to run quite fast on many hardware therefore they actually have set many types of budgets. So yeah so it's easier to make a fun game fast than otherwise but still game has to be fast otherwise the user is not going to play with it anymore because they just don't feel well enough. So there are some kind of time based budgets. So like I don't have real numbers because they are all under NDA for most of the consoles but there are some startup time limits. So you put in the disk and you have four seconds to display the first screen. You have limits, how much time it can take from transition to level one to level two and Microsoft, Sony they are measuring those times and if you cannot keep them then they won't give you the permission to publish the game with their logos and so on. So therefore the developers have to really take care of this. There are, it's also a time based budget but per frame. I think most of us know it, 60 frames a second is the refresh rate of most of the consumer monitors. So it means for the work you have at most 16 milliseconds. In a web game, in the browser you only have around eight because the other eight is for repainting the screen and if you want to keep 60 seconds which feels nicely for the user. So users want it although they don't tell you that they want it but otherwise you just feel bad for them. So there are some hardware based memory, network latency, yeah, like over Wi-Fi or 3G you have better vers latency and so on. And the thing is, so why I'm showing it is because it's easy to test against it. So there's a yes or no answer to the question, are you within the budget or outside of the budget? So there's no compla- so you cannot discuss it. If you are out then you have to do something. So for example, there's a new feature which makes your, you cannot hold your budget anymore because of the new feature. And you have to decide what can you leave out or is that feature important enough to be over your budget and maybe, for example, for a frame, if you cannot keep up with 60 frames, then is the feature important enough that in a few scenes it's going to be around 30? Maybe the answer is yes and then you just have to buy the bullet and do it, but quite often not. I have an example from a website here, page load time. So web performance is quite, it has hype right now around it. And here you have a new web font which makes your budget so too tight. And you have to decide do you really need it or you can just replace it with a system font or you can maybe kick out another font. Yeah, it's your decision. I have some programming techniques which I think since I've heard about them again a few years ago, I keep using more often. Actually, the one is the game loop. It's the heart of the game. So almost every game has a game loop or which has to draw something on the screen. Basically, sorry, yeah, the definition of the game loop. And so basically it looks like in every frame you process the inputs, then you update your game objects, whatever your game objects are, and then you render or generate some kind of output with some kind of pseudocode, yeah, process, update, render. And you can make it a little bit more complicated like if you have AI, so artificial intelligence or collision resolution or sounds, sounds as we see, as we have seen, the game juice are very important. Here I have a JavaScript example for many websites. There's request animation frame and it looks a little bit differently than in a C where you have threads and thread sleep and so on. But the idea is still the same. And I think game loop is not just for games. It can be used in every kind of software. Actually, I use it quite often on websites for animations or when the user is scrolling, you have maybe a box which sometimes crawls with the user, sometimes it stops on a prominent position and gives place for another one and then maybe goes on again. So you can just check the position and update your game objects which in this website's case are some boxes. So yeah, if you replace draw and render with some kind of business specific things, then you are there. So maybe an idea just to give you some feeling about it. So real time advertising or like Google AdSense or AdWords, there are every second many ads shown, users click on it and Google just collects all the data. Maybe they can use a game loop as well. So like process all the clicks and ads views and whatever for them matters. Update the earnings and spending because money goes from one side to the other side and the rest or percentage stays at Google. And yeah, then at the end you produce your outputs, you put it to DB or produce some kind of art defense. So it really looks like a job for me. But so it can run many times a second. Maybe it's enough if it runs once a minute, once an hour. But the concept is the same. One more thing I think I would use more often if I was a game developer. I'm using more often since I was doing this research are the state machines. I've known them for so since the university. But what I really like about them is the visualization. It's really easy. So you have states and you have transitions and transitions happen when you have events. So in this example, you have light bulb. It can be on or off. The events are pressing the switch. And so there's your application. In this case, the light bulb must be in a state in every moment of your runtime. Here, I draw myself one as a video player. It also has some states, some state transitions or some kind of events like it's loading. In the loading stage, it begins if it's after it's loaded, it can go directly to playing mode if auto plays active or it can just go to a not started and doing nothing state. And then there are some transitions between playing and post and vice versa. So the thing that I really like about this is so I work in teams in a team and this team is does not just consist of developers but there are QA colleagues, there are product managers, product owners, maybe other stakeholders, whatever you call it at your company. But I think they are quite powerful because the visualization is rather easy. You can show it to other people who maybe don't have a technical background like you. And it's rather easy to reason about or think about. You can just throw it on a whiteboard and you can talk to non-technical people about them. And I tried it out and for me, it really works. So non-technical people after a little coaching, so just telling them what it means. After a few minutes, they are capable to see the states and to understand what happens there and then the team just gets used to it and you can use it in meetings and the whole team is on the same page. Yeah, actually, a sister or brother of state machines are the behavior trees. Game developers use behavior trees quite often, mostly for artificial intelligence. Actually, behavior trees can be converted in state machines, state machines can be converted in behavior trees. Why I like it is also because of the visualization. So it's more complicated. So other colleagues need maybe more coaching from you to understand it, but after a while, they can get used to it. So I have an example here. There is a sequence node in a tree and this, so it means it tries to do the first thing. If it succeeds, then tries to do the other one and so on. But if it fails somewhere in between, then the whole node fails and the execution goes on in the tree. So I have a more complicated tree here. It starts with a sequence node. So first, we try to walk to the door and then there is a selector node. It tries to open the door first. So selector means at least one of them has to succeed to go on. So for this state to succeed. So you open the door. Maybe you do it, then it's fine and then you can go on, walk through the door and so again. But if you don't succeed, then you have another choice. You can unlock the door, open the door and then walk through and so on. But maybe you don't succeed with unlocking the door because the lock is just too good for your skills in the game. Then you just smash in the door and then just go on. Maybe if you fail to smash the door, then the whole tree which we see fail, it bubbles up to the root node and then the AI cannot do any further here. So and the thing I really like about behavior trees is the extendability. So you have nodes and you can replace the nodes with more complicated subtrees or you can just execute the tree or just a sub tree of it as you like or as your situation expects it. So I have a few resources which I collected throughout the preparation process for this talk. It's actually on GitHub, large list of links. You can just grab the link. I will post it afterwards on Twitter. There are some things which I wanted to show. Is first how I got here or actually on Reddit there is a great community around game development. If you are interested in the topic, I really recommend to take a look at there. There are quite interesting articles, questions and answers. It's a really good source for game development topics. So there are two books I read. The first one is from Robert Neistrom. It's called Game Programming Patterns. It's really good written. I can recommend it to you to read it. There are more about game loops, also state machines, how to handle the state in games. There are many things about entity component patterns, also sample code. And there is game programming algorithms and techniques from Sanjay Madhav. It's also very good and also more related to programming. But without the code samples, it's also still worth to read. So what we have seen is that success is not predictable neither in the gaming industry nor in business software. So there are some techniques which we can do against it or to have better success rates. There were, for example, prototyping to collect feedback as early and as often as possible. There were user testing, setting up, test lab. And then I should use some techniques or that little demo about game juice that juice is very important because it makes your game or your software just better, just to feel better. So it won't help you if your software is bad, but if your software is good, it will make it better. I've shown you some examples about feature creep. So Duke Nukem and to reduce the scope, there were those DVD covers and also the feature budgets which help you to decide whether to keep the feature or kill the feature. And then some things like game loop and the state machines. So yeah, that's it, actually, what I wanted to tell you. And I really encourage everybody to look out for other industries, how things work there because there's always a great chance to learn something from them and to import it into your field where you are working, where you feel comfortable, where you are at home. So the slides are also on GitHub pages. I will tweet about it after the talk, but you can find them there. And you can find me on the Internet. I have website, email address, everything. So thank you very much. And I think we still have a few time for questions and lunch is almost there. Thank you. So questions, maybe? Okay. Thanks. Sorry I, I don't know why I need to run myself here.
I would like to share with you some thoughts not a hardcore game, but the audience was really games for, so during the development, I was software development studios. They have to earn game development. So around 10% of them, so again and there are many, many things. You can with business software, it's also the case. So I have some programming techniques which I think your application. In this case, the light bulb behavior trees. Game developers use behavior