 Hi everyone, my name is Aleksandr Gladysh and today I will tell you about rapid back-end prototyping for a geolocation based mobile game with OpenResty, Radis and Docker. I will tell you a little bit about the case, about the technology stack in general and in details about the nuances of this stack. I will tell you about how the game world architecture is laid out. Hopefully I will show you a very brief demo because the time is really short. I will mention a little bit about the client side and after conclusion maybe we will have a little bit of time for the questions, otherwise I will be here. A little bit about me, I am developing software since 2002, most of the time in game development and lots of things beyond the game development now as well. Well, I am a Lua person, Lua programming language, it is my favorite one and we are holding a conference in Moscow this March on Lua. There would be hopefully some topics on the game development, so you are welcome to come here. What are the games with geolocation? Anyone knows what this is? Okay, everyone knows. So those are the games with geolocation. Well, and given the success of that game, we decided to try a little something to prototype a number of ideas on the gameplay we had and to figure out what is fun, what is not, what works out, what doesn't. And well, figure out what are the technical limitations of the thing too. And well, as a result in less than two calendar months and about 100 hours we have a playable prototype, mostly for the service side technology, but with a small client. And it's enough to get us rapidly iterating on the gameplay. Well, what does this talk about? This talk is about technological side, not the game design, not monetization, not something like that. So some of the examples will be silly from the gameplay standpoint. I am talking about technology. And well, right now it's easier than ever, I believe, to develop the geolocation based games. And I believe that there's quite a lot of space for creativity there. Quite a lot of space for new things, not to repeat the other major brands, but just to have fun. Since it's so easy, it's easy to have fun here as a developer too, not only as a player. And well, here's a gameplay for the prototype. It's quite simple really. The player with his phone in his hand walks around and he searches for mobs, monsters, that is, which are placed on the map. If player finds a monster, he can try to collect it. There's a certain chance that the monster will escape. Otherwise, well, a statistics counter gets increased in player's profile, monster vanished, and then it responds after a certain time. And basically that's it. Other than that admin users may add new mobs on the map, new spawn points. For the initial prototype, that's quite enough. You have to start small, but not so small that you don't lay down the foundation for the next new features. So start small, but generic. The stack we choose is something we used earlier on other projects. It's something we are familiar with. You can choose, of course, something else, but I'm talking about what we did. It's Redis as the database. OpenResty as a web server and application server. Docker as a thing to hold it all together. That's for server. And for client, that's a single page web application in a browser. We have HTML5 implementation of the client code. Well, why Redis? For us, it's a reliable proven solution, which, luckily, supports yellow positioning out of the box here to commands for the Redis related to that. You can Google them up. And Redis as well has a nice set of primitives to store the game object data. And well, since we're coding in Lua, our application on the server side, it comes as a nice bonus that Redis has stored procedures in Lua. Never use them, actually, for this project, but there are a few places that can be useful. And why OpenResty? OpenResty, what it is first? OpenResty is an engine X, a web server, distributive, which supports out of the box Lua, Redis, and many other useful things. And Lua there is, you have an option to install plain Lua, but for the fastest performance, not that it's needed for the prototype, of course, but still, you can use LuaJIT, which is much faster. And well, so OpenResty is something very fast, quite friendly, at least to me. And while maintained, there are some large corporations behind it. Let me move the cursor though, sorry. And it's useful for quick prototyping as well as for the production environment. We use it on production on other projects, as we use Redis too. And the Docker is a good thing for us because usually when you have a complicated ecosystem on the server side, it's a pain to set it up for each single developer. Okay, for a prototype, there may be a single one developer, but then you have to deploy it somewhere. And let's do the same thing again. With Docker, you have a reproducible environment, which you just write once the Docker file, and after this, you can set up the Docker containers you need just with a few commands. But the problem with Docker for us is that, okay, it's really good for developers. You don't have to teach every single developer to set your project up. But it is arguable if it is suitable for production because there are certain performance problems, certain reliability problems, which can arise still, unfortunately, on the higher loads, so to say. But that's a prototype that doesn't matter. So you can set up Docker environment on your server really quickly for the prototype and then decide what to do with it. One point though, Docker usually is outdated on Linux, at least on Ubuntu, not to say about Linux. In general, so you have to update it to sufficiently recent version. I don't know, maybe it's changed with the last Ubuntu release. I haven't seen it. And the browser, well, it's for this project we are prototyping the server side first. So the client doesn't matter much, but still the game has to be playable. You can, of course, as a developer, send CURL queries from the common line, but it's not fun. And it's hard to do from the mobile phone while you're working around and playing the game. So some client has to be there. And well, you have to have a map, you have to have a list of game objects. But if you remember this original title we were talking about in the first place, there's certain kind of combat there. You can imagine this in your head. In general, don't implement anything you can imagine at least at first. So you are sure you can implement later. For us, it's not a problem to well do this kind of thing, not tied to girl location. And the girl location is the main topic here. So we skipped the battles. We skipped other frills and the client is pretty basic. And well, another problem here is that girl location data access is rather limited on the browser, but it's okay for our purposes. And well, I will skip some of the slides. You can read them later, given that we have little time. So on the developer machine, Docker is quite simple. The client, which is browser, connects to the local host port. And there, those two square boxes are sitting Docker, OpenResty sells the HTTP request and talks to Redis, which it resides in another Docker container. Here's a configuration for the Redis. It almost works out of the box. And I will not read it to save the time. Here's a configuration for nginx, the interesting parts. Basically, you serve the static here from the index. And you serve the REST-like API for your application at another URL. And well, that's it. One thing to note here, though, is you have to disable the lower code cache for fast reloading. So you change the code on your computer and it's there on a server. It drops the performance a bit, but you don't care that's a prototype. And here's a Docker file for the OpenResty. Basically, it just copies all your code there and launches it. One little trick. So the OpenResty sees another Docker containers. You have to tell it that the DNS server from the Docker resides right here. So you have to adjust Resolvers Conf. Anyway, how the API works, there are only three player calls to get the game real estate, to get the specific game object status a bit redundant because the objects are here as well, and to call the game object action. And there's a few system calls to create a new player to reset everything to the factory state. It's often needed when you're prototyping. And to upgrade the database that's B to the current version, so if you just deployed your code in your version and have to change the data. And we are not implementing any kind of back office UI to save the effort, but we're using the in-game mechanics for in-game, well, game management. So certain users can be made admin and through game actions, sorry, they can change the relative, they have the proper permissions. How much time do I have? Seven minutes. Good. GameObject. Well, for server, GameWorld consists of game objects and game objects only. GameObjects has numeric characteristics and a list of actions. It may have coordinates and if it doesn't, it's either a prototype for another game object or it's inside another game object like an item in inventory. And the prototypes are there to save your work on the setting up the objects in the same way each time. So basically prototypes object includes its properties and actions from its prototypes and a prototype can have a prototype as well. So that's like inheritance in programming. Characteristics. Well, this slide talks about how they derive from the prototype doesn't matter. GameObject actions as well. So here's an object. It's a green torot monster. Well, here it is the torot itself. It has a unique ID, sorry. It has a position and it has a reference to a prototype. Here's its prototype, which is a specific prototype for this kind of monster. It sets the escape chains for it and it has a prototype in itself and that prototype, well, it sets the respawn time. And here's the implementation of the action that catches them up. We'll skip it. One interesting thing in Redis that you can, using the sorted ranges, you can implement the delayed action execution. You don't need any kind of cron. You just add each query to your server. Check if there are any actions to be executed by this time and execute them. In production you will have to limit this by the number of actions to execute right now, but for the prototype it works. And here's player. Here's an interesting item. It makes anyone who wears it administrator. It grants user admin rights. Here's how we give the admin hat to player and, well, here's how the stored inventory items work. Here's how the objects attach to another object work. Sorry for skipping this. No time. Here's a spawn point. Well, what else? A demo. Let me show you the demo quickly. As I said, it's quite basic. You can open it yourself and play a little bit on a mobile phone. Don't forget to change the user ID, otherwise you will be jumping around. As you see, no authorization. It doesn't matter because it's a prototype. Only people who know it played. And there will be link later in slides. As you can see, there's a map. Here's a green tot and me underneath it. And here's another green tot I placed yesterday. There's me. I have an admin hat. I removed it. Let's don it if the internet works. Ah, no problem. And there's a green tot. Its name is Bradley Perry. The names are randomly generated by a JavaScript library based on this as a seed. It's very useful because this seed, you can't remember it. And here's another user nearby. Anyway, what else? Here's how the client worked. Not interesting. You will read the slide. No problem. Here's a trick how to launch the Google Maps. I found that all the examples in the internet lock, one line or another. So I have to compile it together. And, well, the problems. The problem here is noisy deposition data from client and extremely low precision of geolocation in buildings. But there's no other problems. Actually, that's technical limitations you have to adjust your gameplay for. Well, what's missing? The event system is solely missing. It has to be added to the engine. And lots of small functions like pedometer, the number of steps you take and the meters you walk. So you can tie some gameplay mechanics to it. Well, that's a prototype. After you're done with the prototype, after you understand how it should work, throw everything away. Well, it doesn't work. But okay, at least start over and thoughtfully move parts, good parts of the code there. Not just reuse and hack around. Because in the end, close to release, it would not work at all. And thank you. That's it. Sorry for skip slides. We have a moment for questions. Yes, your comments. Oh, good. Anyone? Please? Can you detect if I am in the city, in the forest or in the sea? Depending on what date. Sorry. Can you figure out beyond the coordinates if I'm in the city, the player in the sea or somewhere else? Yes, you can. But you have to get the coordinates to the zone data somewhere. There's OpenStreetMap project, which I believe does something like this. So if you will tie this to this, that will work. Please? So there were three parts here, Redis, Docker, I'm sorry, I didn't understand what the third part is for. I'm sorry? What are the technologies mentioned here? Is Redis, Docker, and Sonya? OpenResty. There are three parts of technologies here. Redis, Docker, and OpenResty. OpenResty is there, the application code is. The code and law that defines your server-side game logic. Next question, please. No questions? Yes? Is this a game you're trying to... The goal of the prototype is to experiment with the technologies? Are you going to make an open-source game that you go to release afterwards? What's the goal of the prototype? The question? Well, for us, the goal of the prototype is to understand how the games, the girl-location games work. We have like a list of ideas for several pages, which try this, try this, try this stuff. And without something easy with which we can rapidly iterate, we cannot try those ideas, of course. The technology is second, and that's important only because you have to filter those ideas by the technology limitations, but that's it. This... No, I'm sorry. I don't have the URL on my... Or do I? I probably called all the... Come on. That's a pity. Everyone write down this URL, geo.logic editor.com, if you want sources or talk slides, they are there. I will publish the English language talk slides there today, and the game there as well, it's available for everyone to play. So it's a little small open-source game, patches and contributions are welcome, I will publish them as well. Well, so another question. Are we done? No, we have time. I think there's a question. Yes? You mentioned this is not a pretty secure authentication part. No authentication at all. We trust that you are the one... I may ask what would be a good start for implementing this? Can you do anything out of the box with Redis? It depends on the platform... Sorry, how to do the authentication properly in this game? It depends on the platform you're targeting, because users don't like to type in passwords. You have to type into Facebook or Google+, sorry, or whatever. So basically, the proper client would not be just a patient browser. It will be an application. It can stay in HTML, no problem, if the technology suits you, but you will have some framework, and you will tie the authentication from this framework to this game. If you worry about this prototype being secure, just add basic half there at your engine X config and that's it. Well, in Servit and HTTPS, as I did because the Chrome limits the geolocation data on plain HTTP. Another question, please? Yes, please. How can you be sure that the coordinates, the client send you are correct? It doesn't matter. Can you be sure that the coordinates client send you are correct? Like I said, it doesn't matter much because, well, it will be probably a problem for the final game, but then you will have the proper application where it would be harder to hack. Right here, it's easy to hack, but you're just trying it out. So if you worry about hacking this, first the people have to start to care about your game enough. And as long as you don't pay money to people who come to a certain place, you can forget about this until release, or until better at least. Thank you so much. Thank you.