 I thought of this, yeah, starting over, I forgot to unmute the microphone, so yeah, story up, adventure game framework in Drogdo. This is funny, and let's do that again. Does this work? Yeah. Okay, so starting over from scratch, this adventure game framework in Drogdo. So adventure games anatomy at first. I will focus on what adventure game creators actually need, what do they require in order to create the game, and what do they actually don't want when they are focusing on creating the game itself. Then I'll talk more about this career, introduce it a little bit more, talk about its current status, and what we can do to make it actually better and complete it. So what's an adventure game? Basically, a few elements that you will find in every, in every adventure game, pointing to the adventure games of course. Well, there were a lot of adventure games in the history, so I'll mostly focus on those you can see here. Most of the time you will be playing an animated character, the main player that can move around over a scene, change, go from room to room, et cetera. So basically walks. You can find also items, NPCs to talk with. Those NPCs are of course reacting to actions, actions that you can find here on certain UIs. Sometimes on certain UIs you won't find them, depending on the game, you will find them under the right click to change the actual action to perform on the game objects, such as talking, give up, use, give, et cetera. Other elements that you will find in almost every adventure games, mostly 2D, of course here. Puzzles, using all the items that you will be able to find in the rooms, which means of course having an inventory to keep all these items into your pockets, which is funny because usually your pockets are that big and you could put a whole ship into it. Dialogues of course, as I said, you will meet a lot of people, NPCs to talk with into the games in order to follow the whole history. Which is interesting and it's totally part of the story that you want to tell the player. And also in order to tell a story you will need cutscenes that reward the player as he advances the story of the game, that's what the player is looking for when he advances the game. So first of all, we are talking video games here and it is mostly commonly accepted that video games are no kind of an artistic thing. So we are talking with art, we are working with artists here. What do artists actually need to work on video games like this? First of all, they need to be responsible of the lifetime of the assets. They are actually creating for the game. From the beginning, from the black canvas to the sprite that will be in the actual game. They need no dependency on the programmers. They just want to draw their art, put it in the game and don't ask any programmers. Please can you program update this sprite with the new asset I just created and update it again which needs recompiling all the time. Boring stuff for the artist. They just wanted to be in the game and do not require anything. And of course that's the most important thing. Since they are video game artists, their medium is the video game itself. Of course they will draw all their assets in the dedicated software such as games, such as creators, such as Photoshop, whatever. But they will then export them and put them in the video game directly. Otherwise it stays on their blank page and they are PNG artists. Now that was for the game artists. Now what do game designers need? Those are not the same. These persons are the one who actually write the story and turn it as scripts that make the game work as those scripts are processed and as the scripts are used according to the actions of the player, make the game advance, change the game state and all this kind of stuff. So game designers basically create their story by building rooms using the backgrounds from the artists and they put on this navigable areas to know where the player is able to walk or not. Hot spot areas. This is more some kind of UI stuff but it can serve the story as well since you want to be able to define these areas to be focussable so the player can just look at them but maybe not pick them, use items on them but still not pick them, not push them, et cetera. Items of course, trigger areas. Sometimes in your stories you want to be able to have the player walking in an area and trigger another event and for example, start a cut in NPCs as well. So basically this is accessing the access and influence the game logic but not too much because if you give the game designer too much freedom then first it will be more difficult for him because he will have to manage so many things and he wants to focus on the game logic only, only his story. But still complex enough for him to be able to create and write interesting stories and focus on this. So now, what do game creators in general don't want to mess with? First of all, I believe that they don't want you to care about the UI. You know, I mean they need to care about the UI because they want to know what it will look like. They want to change the theme, they want to place it on the screen, they want to define its basic behavior but in an adventure game you have the inventory, you have all the dialogues, the verbs actions that you can find on the UI. But they should be already done and the game designer should only define their look, not their actual behavior, what it does behind the scenes. It's not interesting for him. So only define their appearance, even truly special behaviors, rest it's too technical. So they want to care about how characters actually move. Movement of the characters is some kinds that can, it's a very specific task to be managed in the game engine. Nowadays, game engines can deal with this pretty easily with a lot of techniques. You can have path findings, stuff, navigation, whatsoever. So the easiest manner for the game designer to do this is to just define the areas, the walkable areas and that's all. Also the same for the animations. They want to define the animations and forget about them. Create them, name them, call them, call them by scripts of course, but don't manage the way the animations are actually started in the engine. Don't manage their timings. This is creating the animation but don't manage this between the timing of the animation and the timing of all the management of all the events of the game and so on. There are a lot of stuff like this I didn't talk about sound, for example. So we are talking about a Godot framework here. So Godot doesn't provide, doesn't Godot provide already all the stuff you require to do this? Like sprites, animated sprites, animation player to do the animations. So everything's okay. JD script, which allows you to create your scripts, scripts your game, manage the inputs of the player. Everything's fine, but it's already too low level for the creators so we need more simplicity. And that's the purpose of Ischoria. So what is Ischoria? Ischoria is currently in its current state a set of tools and script, mostly scripts that are built on top of Godot and they define a basic workflow. That means the scripts are here and you will, as a game creator, we just have to put them on your nodes and that's all. And after that you will have to use another way to script your game logic. It's meant to be a tool for teams, artists in one hand, game designers in the other hand and it's built on top of it in order to forget about the programmation stuff. It's already done for you. So it's a collection of scripts, as I said, to apply Godot scenes and nodes. Then about the scripting part that allows you to, I actually make your action, the actions that you will see, the dialogues as well. These kind of things that you can have here, those are the actions, look, use. This would be a script that you could put on a red bed. I put a commentary, item red bed, for example. So the action look basically makes the player to say, oh, a nice red bed, fine. And also another action, if you want to action verb use on this red bed, the player would just say something else. In the same way, you will have a lot of commands in this scripting language to allow you to add the object in your inventory, use the object on another object and manage this using states. This is not exactly the purpose of this presentation because that's the way it works. And this is not meant to be changed. It already works. The nice thing about Xcoria is that it already cares about all the stuff I said before. The game's elements are, the game's elements and the managers, everything works, items, navigations, animations. You can already forget it because it basically already works. Just to show you a game that's already using Xcoria, a professional game that was out in 2016. This game is the Interactive Adventures of the Mendoza and Pizzaboy, which started development in May 2012. It's a classic point-and-click gameplay, basically, so it just fits the purpose of the other framework. It was made by only six person, then 12 in total, so Xcoria was actually created during the development of this game in particular. It was a Kickstarter and the game was signed to the publisher. The idea was to release Xcoria as free software under MIT license after the game was actually released, which it was. So that's good, but that's not enough. We have to know that Xcoria was written already a long time ago. It was written under Godot Engine 1.X, if I'm not wrong, and now Godot is just version 3.2 since two or three days. And a lot of things happened in this period of time. A lot of features made their appearance in the engine, such as editor plugins and just to name one, but not only this. Problem is that Xcoria's maintenance is not very easy because the backend scripts that make the whole framework work are very big. It's a whole load of script, and it's not easy for someone like me who arrived after the development of this game. I wasn't the developer of neither Xcoria nor Documentosa game. I arrived just after when the framework was released, and it's really difficult to dive into this base of code. So actually you can run some music, run animations, modify game states, but it's made of hacks almost everywhere to just tweak some problems that you can find because of some Godot bugs. You can have this in labels, for example. It's very difficult to use. In my opinion, I need more flexibility. Currently, if you want to make an actual scene, this is a scene which you would call a room in another tool, for example. So basically a background with the wall cable areas. You have the background here, you have the terrain, and this terrain node is actually the wall cable area. And all the other elements here are basically sprites, other game elements. The players here, you put everything in this way, but certain elements such as the background and the terrain are mandatory. And the fact is those names need to be in the right order in the century, so background needs to be in first, terrain just after. They need to have this very name. This is not very flexible, so this must change in order to let the creator make all the things the way he wants it to be. Because of this, it's hard to add new features. Some new features have been added in the past few months such as the shadows under the characters. We're speaking 2D shadows here. You can also have lights in your backgrounds and one of our users wanted a feature so that lights actually had an impact on the shadows under the player. Usually shadows are just part of the sprites and that's all. He wanted something to be more dynamic, which was difficult so we just had to find something, but again, this is very hacky to me. So what are my goals in order to evolve this Korea in its current state? First of all, simplify the usability. It's already very easy to use, but you basically have to read the manual. A great manual has already been written by Floss Manuals, which you can find on the internet for free. It's a great example of a game, of a point-and-click game that you're able to do with it. Keep it as simple as possible and maintain in order to appeal more people to add new features, fixed bugs, because there are bugs, not only Godot bugs, but also Scoria bugs. But also, of course, don't make it a new adventure game studio or a visionary under Godot. In order to make this, the idea is to make Scoria an editor plugin. Making this will enable us to integrate Scoria directly into the editor, and also enable us to create new tools, such as an Scoria scripting editor, so you will be able to write your Scoria scripts directly into Godot, which is not possible currently, and also all sorts of ideas that you can have here, for example. Also, another idea I had, a custom user script to add new functionality without having to edit the actual Scoria source code. This is Scoria, a whole bunch of scripts in one folder named Global. As you can imagine, this is a pain. So I wanted to look more like this, more homogene with the different folders. Basically, it's sorting all the source code, but it also means reorganizing the functions into the scripts, which is a lot of works. This has impacts on the relationship between the user scene and the Scoria. So basically, I need to make them a little bit more smarter and try to guess what the game creator wanted to do when he created his scene. I'm trying to go a little bit faster because I took a little too much time, but to be very simple, I only want the user nodes, the scenes that the user created to have two tasks only. Receive user inputs and emit them to Scoria. Scoria manages them, does his stuff, and gives back those nodes actual actions to perform, such as move the node, play animation on the node, and that's all. Currently, you can see some game logic... Yeah, you can see some game logic inside the scripts that are currently in those scripts, which is not something we want. And to finish on this, the example scenes. Currently, Scoria comes with a few example scenes, which are crappy. Actually, this is the only one. I started something over, but yeah, we want definitely something different. So in order to do this, well, basically we'll make it from scratch. This means make multiple demo scenes showing different features of Scoria. That can be animation in the background, one scene, side scrolling, another scene. This way, if one room, one example room is able to showcase only one feature at the time, it's easier for the users to dive into Scoria and use it. And of course, make it a little bit more beautiful, because if I see this for the first time, I'd run away. So yeah, that's the basic idea. Of course, this is a lot of work. That's a lot of work, and it has just started. I should have started this a few times ago, but yeah, life, open source, this kind of stuff. So there is no working branch yet. It will happen soon. If you already have used Scoria, if you're already using Scoria, expect some competitive breakage everywhere, because it will basically change completely. But in this time, by starting from scratch, I'm reintegrating all the existing source code, cleaning it, removing all bugs, all hacks, portion by portion in order to have it working the exact same way as before. So it's transparent, but it will be totally changed behind the scenes. So of course, no estimated date of delivery. So for those of you who are already working, waiting for Godot, that's one more thing to wait for. So what you can do currently, just to finish on this, you can drop by an IRC. I'm usually idling on Godot Engine Scoria. There are some people who are idling there as well. So you can share your ideas and suggestions. This is the Scoria repository. It's on the official Godot Engine account, since it was related in a certain fashion with Godot. And if you have any IDE suggestions, you can also drop them on a filing issue in there. That's it. Thanks for listening. If you have any questions. So do we have plans for HTML5 exports? Actually, this is not exactly related with Scoria itself. This is more a Godot question to be honest. There are plans about HTML if I'm not wrong. We have a paid contributor who's currently working on WebExports. I'm not really aware of the current status of this, but this will change since we have some people working on this. Yeah, about the threads and management in the web browsers. Again, the same answer, unfortunately, I'm sorry. This is not exactly the purpose of Scoria itself, even though it's, of course, obviously it's using threads, but this will have to be tested. I don't know the current status of WebExports right now with Scoria nor with Godot Engine itself because I'm not using it myself yet. So I have difficulties to answer your questions. But if you drop by at the Godot stance, maybe somebody will be more able to answer your question. Yes? Yeah, so about the Android compatibility and all the widgets that you can use on Android applications, that's something I have in mind, indeed, to make it work with Android and mobile devices as well. That's important because in my opinion, indeed, that's a platform that suits very well these kind of adventure games. So, yeah, that's something I have in mind and I will try to work on Android experts as well to make it work and also ease the game developer work to provide him with already, since already made for him so that they fit for mobile platforms. Yeah, other questions? All right, thanks a lot.