 I have the financial help for having him coming here. Else he would have come and certainly he would have spoken for sure. He would be glad to do so, but unfortunately it was not possible. Maybe next year, hopefully. Okay, so thank you everyone for coming to the open game room. This is the last talk of the day, running with the Godot engine. Thank you so much. Hello everyone and welcome to this presentation. I will be talking today about Escoria framework, which is a Libre point and click framework using Godot engine. That allows you to make adventure point and click games. So, first of all, what is Escoria? Escoria is basically a set of tools and scripts built on top of Godot engine. Godot engine, I will be talking about it in the next slide. This framework aims at providing a basic workflow for a whole team to build an adventure graphic game based on top of it. To do so, it provides multiple tools such as the ESC scripting language that I will be talking a bit later too. And just know that it's meant to be a tool for either for teams to adapt and build on top of it, or for indie developers, indie and also alone. So, what is Scoria is not? First of all, it's not an all-in-one product such as you can know with Visionaire or Adventures Game Studio, which is a complete solution that allows you to create such games. This is not exactly the idea. So, it's not exactly a user-friendly product. You'll have to adapt and know the framework, know Godot engine because you will be using Godot engine extensively. It's also not a make-your-game-without-programming solution. So, it's not like RPG maker stuff that allows you to put your assets and just move them by clicking and dragging them the way you want. It's not exactly that. Godot engine allows you to do so, but this is not exactly the purpose of Escoria framework. It's built on top of Godot engine, which some of you may already know, and if not, you're welcome to our booth in the H building, which is a full-featured engine, 2D and 3D that allows you to create your games. It's not a library because it takes over your entry point, main loop, inputs, shaders. It allows you to create the whole stuff that you put into your game and organize your stuff in nodes into the scene-tree model that you have in illustration here by their team Sweeney from Epic and Rio, who had a little comparison between the way the scene is organized in other engines and the one in Godot. As you can see here, in other engines, you put all your assets in the biggest scene and organize them inside. In Godot, you just create your scene and you split them in sub-scenes, which you split up again in even smaller sub-scenes that you can use in other scenes. So you have scenes reusable and easier to maintain. That's the basic idea. And of course, Godot engine is fully open source and MIT licensed. So back to Escoria framework again. There is already one professional game that uses Escoria framework. It began with the development of the demo in 2012, showing a classic point-and-click gameplay. And just to say that most of the team, for most of the members of the development team, it was the first time making a game. They had six core members and there were 12 in total. Finally, the game was kick-started in November 2014 and it barely made that 30k. And the game was finally published and it's now shipped since about one year on Steam. Just to worry about tools in game development. Every game, whatever the genre or the type, when it comes to a certain complexity, will have its custom tools. That's the case with adventure games. But when it comes to professional teams making a game, you generally distinguish two main groups of people, first the artists and then the game designers. So we need in this case a tool that allows both groups to work together. So we need a tool that allows specialization for the artists and for the game designers and also assigning tasks away from the programmer. So you don't have bottlenecks having programmers and artists or game designers needing some specific tools waiting for the programmers to program them and having to wait for the programmers to finish the job before they can at last start the work. So the programmers have to build the framework first, which is the purpose of his career. Programmers solve their problems with the code and the code has bugs. So we want to avoid having to create code as much as possible during the game development process. Also programmers are 25% more expensive according to Game Acetra, which means it may be interesting to avoid using them as much as possible. As an example, Dr. Mendoza has 15k assets, which means there is a real need in this kind of game, adventure games, for artists to put their assets and creation in the game. So what artists need exactly? They need to be responsible for the creation and the usage of their assets from the beginning, from the blank page to the ending game until the game is completely finished. So they need to have the control of the use of their assets into the game engine. That's the purpose of Godot Engine, which loves that. They have no dependency on programmers, almost. In the case of video game artists, they are not simple artists on blank pages. They, of course, draw their images and textures and 3D models, but not just for the beauty of it, they have to use it in the video game. That's their medium. So they can express themselves on the medium of a video game. If they can, and if the environment allows them to do so, then you get a better product in the end. In the case of game designers, their needs are a bit unclear. They need to access the influence of the game logic, but not too much, because they will add much, much thing, and even more, and the game development will never end. But they need a tool that is complex enough to allow us to surprise us and be able to make things that we don't think the framework or the game engine would be able to do. Basically, they need level design tools to allow them to build the scenes, the rooms, and stuff like that. Also, dialogue writing in the form of dialogue trees and cut scenes for scripting, not as movie script, not as computer script, that is no source code. We want them to write a story and make the game play upon it. In the case of level design, we can use a game engine with Scoria to do so. It's a bit similar to the artist, because they can put the assets together to create and organize the elements of the map or the room by creating a technical specification and keep it flexible. The engine tools allow that. They are forced to learn the tool and it allows them later to keep the edit and test cycle very fast. About the ESC language, this is a language that is provided by a Scoria framework that is used for cut scenes scripting. It's made mostly for the dialogues and the reactions of the NPCs to some actions of the player. It's generally the translation of the game's history. It's completely independent of the engine frames. We don't want the game designer to take care about the technical stuff and take care about how it shows, does it take time, do we have the time, how many frames per second, etc. We don't care about that and they just have to do their job and the technical part is the programmer's part. This language allows the description of complex dialectries. In that, it's simply a basic logic workflow. Since it's not Turing complete, it does not provide any operator, no for loops, no if statement, and so on. It only manages boolean values to do the job and it's sufficient. It's enough easy for them to be able to write what they need and powerful enough to do this kind of adventure game. Just for the story, Mr. Tim Schaefer, a creator well known for the day of the tentacle games and also Green Fandango in the LucasArts games, visited the team members of the Dokman Dozer game and when he was presented with the ESC language had these words while it looks just like scum. So, again about the ESC language, it is really meant for non-programmers. Game designers are not always programmers. They need to control the game logic in complex ways, just to push the limits and allow them for better creation. But not too complex because if you add more complexity, then you can add more bugs. And if you need such complexity, then you should give this task to the programmer itself and let him do the job. But in that way the programmer should just keep his eye on the project and be just a frame around the creators, not be an obstacle. And what everyone needs in the task of creation of adventure games here is always to keep a version of the data runnable at all times. You don't want to have the game created in the editor then start with the compilation, testing, remark the bugs, correct, recompile and so on multiple times until the job is done. So, that's the purpose here of Godo Engine again because there is no such compilation process. Another advantage of the Godo Engine here with ESC Korea is that the scenes are independent with each other. That is, you can run one scene alone. So the team can be split up to work on different scenes and each scene is meant to be a little game in itself and the whole set of scenes put together gives the final game at the end. Just a word about user friendly versus productive question. This framework here was made for a professional team. It has been released in the MIT license very recently but it was meant for a professional team which get paid money of course and they absolutely don't care about having a pretty UI and a magnificent tool that are shiny and so easy to use or steep learning curve and if they do they get paid money to not care. So it's up to you, the programmer, to make it easy for them to use your framework so they can be productive and you don't have to convince them to use it. In such a aesthetics and UI do have a value but the value of the team that creates the game is productivity and not user friendliness. That's why they focused on the creation of the framework using Godel engine and not having a whole solution all in one. To conclude, the tools are very important to allow all the programmers to work and contribute to the game together during the whole process. The programmer has to be just a frame around the core team. It's not the entry point for any task of the whole team because in this case it would act as a bottleneck which we want to avoid. The tools for artists are generally straightforward and most engine provides them so you want to make artists firstly use them and then make programmers out of their way only help them when they need it not having the artist go to the programmer. Finally the tools for the game designers are a bit trickier. They can use the same but it's effectively a middle ground between the programmer and the artist. So you have to find a good balance and that's the idea between the use of Godel engine. Thank you. I just wanted to add that tomorrow and the day after we will be having the first Godel con here in Brussels which will take place at the hacker space near the center of Brussels. So you are all welcome. If you want to join us we will be talking about Godel. Add contributions, talk about the new documentation, crash courses maybe. So you are all welcome if you want. If you have any questions now. Yes? The logic and interactions are very well defined so the programmer being a bottleneck kind of a scope situation like maybe a special scene in the game. Well you don't have to worry about the interaction because they are all managed directly by the framework first that goes into the Godel engine which is the second layer. So you absolutely don't have to worry about it. Left click for example manages the movements of the characters. The actions are already managed also and you just have to take care about the elements that you put on the screen and the actions are connected very easily using the framework. You just have to connect the scripts, the correct scripts into your object elements in your scene and the framework does the rest. My question was actually like if you have any advice on how to avoid this bottleneck in other type games not only when I think about it. Well if you need an extension about the framework right? Sorry can you repeat the questions because the microphone came from the arms? Can you just repeat what the question is? Oh well you're talking about the interaction and the fact that you need to manage more things that the framework could actually do. In this case you can extend the Escoria framework very easily because it's developed in GD script which is the inner scripting language of Goddard Engine. So you simply, you can of course adapt the scripts included in the Escoria framework to fit your needs if it's needed of course. Yes? When you design features against designers in terms of custom behavior or conditions how do we define them for complex immigrants and does it have an impact on the design? No, it has no impact because it's decided concerning the decision of, sorry I'll ask you to repeat again because I almost forgot the question. I focused on the answer sorry. When you add features for the game designers so they can determine custom behavior or custom conditions how do we decide on the complexity and do you have an impact on game design? So does the need of adding the design has an impact on the other member of the team maybe? Do you have to make some systems more simple so the designers can pass with that in a more constructive way? Not really, actually in this kind of problem to make things simpler in the framework the framework is designed to be as simple as possible so you don't generally have to make things different. You can use it as is and you generally will fit the needs of basic adventure point and click games. So if you really have new designing needs it's not a problem, you can add new scripts if it's needed. Yes? So looking at the Scoria kit have a repo it looks like there was this massive first comment five months ago and there's a bunch more four months ago and then really there's not much activity after that so I guess it's kind of stable at the moment So concerning the current state of the Scoria framework on the GitHub repo effectively the Scoria framework was developed first for the dogman-dosa game just at the beginning of the development then it was released and freed open source very recently. So for now no one is working on it to maintain it I intend to work on it and maintain it and add some new features in it I worked personally on a little framework on my own before Scoria was out so I mean I need to add some of the features I created to simplify some of the stuff that Scoria provides for example if you want to define the area of the clickable items you have for the moment in Scoria you have to use mask images Godot engine provides a simple way to avoid this and do everything directly in Godot so you can avoid having to create image masks of your scene to allow the user to select an area of the item plus if this area is incorrect you have to modify this image if you select and define the area directly in the editor then you don't need to remake the image one more time that's the idea of things I want to simplify and other stuff I have ideas on especially for the creation of Scoria scripts ESC scripts which are currently text based I think I'm able to create a tool that allows you to make your dialectries like graph based I created the start of a work from my own project which is not finished yet but I intend to make it and put it into a Scoria framework that was a question the system requirements I think you need a pretty fast graphical workstation to run Godot doesn't need a very big workstation as an example the main developer of Godot engine works on a very low end computer so depending on the complexity and the need of graphics of your production then you won't need a very important configuration it runs perfectly well on very low end PCs so no need for a high end NVIDIA question? not specifically except you're doing very important graphics shading and this kind of stuff, no some of the people who make games for Godot have like Intel HD 3000 graphics on their line oh this is on port graphics? yeah a lot of people are using very low end graphics and almost non-existent graphic cards to make their games it's simply Intel internal chipset works very well okay that is accessible yes? in most or in a lot of adventure games you have a story that goes from point A to point B and you have like a single ending and not like branching paths is this supported in your framework? that's up to you because you are the game designer so you have to design the game the way you want that's the idea behind the ESC language that allows you to create multiple endings if you want depending on the actions of the player say if he finds an item or not he gets one ending or the other that's up to you to design this when you're designing the game at the first time okay yes? that means that if you have those tools in the engine that allows the ability to write some kind of branching scripts you can do visual novels yeah you can do this kind of branching using the ESC language branching like in certain games that came out very recently and visual novels it's absolutely possible to make with the ESC language yes okay guys we're gonna have to stop there thank you so much and thanks very much