 Okay. So hello everyone, my name is Justin Jacobs and I'm the lead developer for Flare. Flare is an acronym which stands for the Free Libre Action Role Playing Engine. For those of you unfamiliar with action role playing games, here's my rough definition. The movement and combat which are core to the sort of game happened in real time. So this is in contrast to a game like chess where the players take turns performing their actions. Though as the player progresses through the game they'll earn some form of experience points in order to strengthen their character and their abilities. They'll also collect a loot in the form of items which they can wear and use to further empower their character. And lastly, they'll need some sort of reason to want to get stronger. So that's why they're a quest to complete in order to give the player some sort of broader goals. Flare is actually broken up into two components, what we call the engine in the game. Flare as an engine is responsible for all the functionality in the game. This includes all the level necessities such as handling input and drawing to the screen. And it also includes all the core functions such as how entities move in the world and the AI behavior of enemies. Technically, the engine is quite simple as far as modern video games are concerned. It's only about 46,000 lines of C++ and only uses the SDL2 libraries as dependencies. So this keeps it fairly welcoming to hack on and makes it easy to support a bunch of different platforms. We directly support the three major OSs, Windows, Mac and Linux, as well as a mobile version on Android and a version that runs in a web browser. What's pretty cool is that we've also seen other people port the game to more obscure OSs like Kaikou and Amigo OS 4. But the engine isn't much by itself, which is why we ship our own game alongside of it. One thing I should mention up front is that we use the terms game and mod interchangeably a lot. A game in this context is essentially one big mod. So the game that we ship as a mod made up of the text files and art resources that the engine can parse and turn to something that the player can actually interact with. So our game is called the Imperium Campaign. It has a fantasy theme, so thank Dungeons and Dragons, swords, skeletons, magic, that sort of thing. When creating a new character, players can pick one of three different classes. These fall into the familiar archetypes of warrior, archer and mage. Each class has its own set of abilities, which we call powers that are unique to that class. There's one main quest that spans the entire game as well as several side quests. So completing the game takes about three to five hours for most players. So what I like to do now is go through players past of it and give you an idea of how we got to where we are today. The original concept was created by a guy named Clint Belanger and was pretty different to what it is today. The concept was more similar to a game like chess where that it was turn-based and instead of real-time and the movement was fixed to a grid. It was also written in Java. But Clint moved away from that concept pretty quickly and transformed the project into an action RPG written in C++. Clint released the first public version of the game, OSARE, or open-source action role-playing engine at the beginning of 2010. You can see what that looks like in the screenshot on the right there. So near the end of 2010, Clint renamed the project from OSARE to Flare after a suggestion from Richard Stallman. I think most agree that Flare is a better name for the project. So jumping ahead a bit, March of 2012 is when I joined the project. I don't remember exactly how I found out about Flare, but I was no doubt looking for games to play on Linux. Back in 2012, gaming on Linux was much less established than it is today. There was no steam and the only real options were a small handful of preparatory games, a smaller selection of free software games, and console emulation. Flare stood out because it was a genre of games that I already liked and was well-made despite being in an alpha state at that point. It also ran pretty well on low-end hardware like the ASUS netbook I was using at the time. I enjoyed Flare so much that I wanted to try my hand at contributing. I was teaching myself to see programming at the time and it seemed like a good way to improve my skills. My first contribution was to make it so that the engine would not crash when the game couldn't start the sound system. It wasn't something particularly useful for me, but the actual code that needed to be written was trivial, so it was a good introductory task to get acquainted with the engine. After that point, I was now part of the team which consisted of Clint, myself, and about three to four other regular contributors. So development continued as normal through 2012 and 2013. The game content during that time was what we call the Alpha demo, which was a loose collection of areas designed to demonstrate the engine's capabilities. But it wasn't a cohesive game with a proper start and end. But then in 2014, some things started to happen. Clint was brainstorming ideas to create a complete game as a replacement for the Alpha demo. It was also at that point that we began to talk about the engine being featured complete and releasing a version 1.0. And there was also this idea that we needed to split the engine into two versions to support STL 1.2 and STL 2. And somewhere in the midst of all this, I ended up getting nominated as lead developer. But 1.0 didn't happen as quickly as we thought. In fact, version 0.19 would be the last public release for the next four years. Some of you might have heard this before, but there's the phrase that the last 10% of our project takes 90% of the time to complete, and that was certainly true in our case. But it turned out that taking our time solved one of our problems for us. STL 2 had become the standard over STL 1.2, so we didn't have to worry anymore about splitting the engine. Now the focus could be on developing the 1.0 game and doing any necessary engine work required to make that happen. During this, I was the only person working on game content and almost the only person working on the engine. We definitely had some great occasional contributors working on engine stuff, but it wasn't the more regular team like we had in 2012. But in my opinion, this type of philosophy works well for game development. Game development involves a lot of subjective decisions, and it can be hampered if too many people are trying to insert their ideas. The Alpha demo had quite a bit of this sort of design by community mentality, and it felt as jointed as a result. I wanted to avoid that for this new game. I was also very lucky. I don't have much artistic talent, which is why it was great that we had a very good collection of resources to work with. All the 3D art, the 2D art, the music, and the sound effects, all of it was already there and ready to be used. So I owe a huge thanks to all of the artists that had contributed over the years. Finally, six years after I joined the project and four years after the last version, Flare 1.0 was released in March of 2018. The engine was successfully migrated to STL 2, which made the Android and web browser ports a reality. Flare 1.0 was a big release with a long changelog, so I've highlighted a few of my favorite additions here. Not having the engine locked to 30 frames per second was an important one, at least to me. When it comes to action games, gamers want things to feel smooth, so being locked to 30 FPS was a big no-no. Vent scripts were also an important addition. When we're designing maps, there are what we call vents, which can be placed anywhere on the map. So what these will do is when the player triggers them, some sort of action, such as dropping loot or changing some of the map tiles will execute. So what we did was we pulled that functionality out so that these sorts of actions could be triggered in other places. It opened up a lot of creative possibilities for us where we now had access to all this functionality for items, powers, and NPC dialogue. Books were another feature that led us to be more creative. They started off as something simple in 1.0 and were only capable of showing some static text and images. As we'll see in a bit, books get the ability to utilize event scripts, which gave them all the functionality that event scripts have. And lastly, the changes that we made to the Monic system helped provide a better future-proofing for us. There was now some light dependency checking that tried to keep players from enabling a bunch of incompatible mods. For modders, we made it possible to change some of the text files without having to completely replace them. So it made it a lot easier for modders to make changes on top of the existing game. So at the release of 1.0, we gained a lot more players and we started to get a lot more feedback, which kept development very active for the next year or so. You can see here that one of the things we implemented was an alchemy crafting system. This was made using the book and event script systems, so it became a nice proof of concept for the types of interfaces that modders would be able to create without having to add any additional code to the engine. But then in 2019, things started to slow down again. Version 1.11 would mark the beginning of another hiatus for us. Version 1.12 took two years to finish and the change log was similar in length to 1.0's change log. There were a large quantity of changes to the engine, but many of them were pretty minor. So I picked two things from the game data side of things that I felt were worth talking about here. So we had three quests in the game that involved trapping the player in a portion of the map. They would have to work their way out and depending on the map, this could mean defeating a boss or navigating through maze. The problem with this is that we also have an item in the game that lets the player warp back to the hub area. So if the player started one of these quests, warped out, and then returned, we would have to awkwardly reset the quest for them. So I redesigned these quests in such a way that the players can now freely come and go as they please. And since the gimmick was gone, I tried to add a little to each quest to keep them interesting. My favorite might be the middle one. The quest description tells the player to travel a long ways back to an NBC to progress, but there's a faster way if the player has the right items in the inventory and a little intuition. The second thing I want to talk about is the new potions we added in 1.12. Clint had already made these really great icons for the health and mana potions. For the new potions I was adding, it was suggested to me to simply recolor the existing potions. But I wanted the new potions to have their own silhouette so the players could easily tell them apart regardless of their color. Now here's what I love that we have freely licensed artwork. Clint released the source files for his potions under the same Creative Commons license as the rest of our game data. So it was trivial to modify Clint's files in order to make my own designs all while retaining the camera, lighting, and materials he used. The end result is something that looks cohesive. Without knowing you might even say they all look like they were done by the same artist. Okay, maybe Clint's look a little bit better than mine. So that brings us to today. The current version is 1.13, which we released just a few weeks ago. I spent most of my time on improving gamepad behavior. It was an area that needed a lot of attention and it'll be important for stuff like the Steam Deck where the primary input method is a gamepad. So because I was focused on that, it was nice that another contributor was able to work on equipment loadouts and fog of war support as additional features. I also want to touch on the text rendering fix. I'm glad I wrote this talk because it gave me a reason to look back at some old screenshots. In doing so, I noticed that the text rendering looked much better in the old alpha versions of the game. Something broke with how text was being blended with the image behind it and it caused the text to look more thin and that was supposed to be. The effect was subtle enough that it went unnoticed for a long time. So while I was writing this talk, I made a last minute patch for 1.13. The fix itself was stupidly simple. We just draw the same text twice so it effectively blends with the copy of itself. If you get the chance, I recommend looking at the blog post for 1.13. There are some before and after animations on there that illustrate the improvements pretty well. Unfortunately, 1.13 also had some game breaking bugs. So the current version is actually 1.13.04. One of the bugs in question was something that happened when the player died in the game. Well, when you play testing your own game, you're usually pretty good at it. So I hadn't encountered it at all when I was play testing. But because there are now players with a wider range of skill levels playing the new version, it didn't take long for the bug to get reported. So there are a couple of lessons to be learned here. Number one is the bugs that are inevitable. No matter how much time you spend trying to be perfect. Number two is that you can't make good games without play testers, but you also can't get play testers out making a good game first. So what's next for Flare? Everything we have planned at the moment for 1.14 revolves around one of the core elements of any RPG, the stat sheets. In our game, all entities have stats that are used in combat. Some examples are the entity's hit points, the weapon damage, their accuracy rating, and their elemental resistances. We want to make some aspects of these stats more flexible, and we hope by doing so, modders will have an easier time making their ideas a reality when designing their games. That being said, our modding community has done a great job of exercising their creativity. There's games like Collimorphal and the Ghost Lore demo, which have their own unique design styles. And then there's stuff like Heresy, which builds on our art, as well as using stuff from the open game art community. We attribute this variety to Flare being relatively easy to mod. No programming knowledge is needed, and all the tools we use regularly are free software. Tiled in particular is a great piece of software. They've always been super supportive of our project, and the export plugin for Flare maps is bundled right in. I've also written my own plugin that helps perform some additional Flare-specific tasks, so I can't recommend Tiled enough, even if you're making a game that's not using Flare. So just to give an example of what modding is like in Flare, here's how you add a weapon to the game. On the left side is the definition that we added to the item's text file, and the in-game result is shown there on the right. Most of this should be pretty self-explanatory. The include statement might be a little mysterious, but all that's doing is taking the contents of another text file and inserting it at that position. We have a bunch of templates for various things, so in this case, we're using the template for a battle axe item. The template defines things like the icon, the sound effect, and the animations, so that we don't need to do that every time we want to create a battle axe. So if you're interested in modding or just want to try playing Flare, you can check us out at FlareRPG.org. I want to thank the FSFE for having me today. I also want to thank everyone who's worked on Flare over the years. If you want to follow me, I'm primarily on Twitter at J.A.J. Dorxter, and I'm also on Mastodon at Dorxter. The Mastodon account is pretty much just repost for my Twitter, but if you prefer the Fediverse over Twitter, I'm on there as well. So now I think we can turn it over to questions, if anyone has any. Yeah, it was a great talk. Oh, there's already a question in the chat. How do you test new features on modifications and requests? Is there some testing framework or another cheat to alter the game state? So we don't really have anything formal. It's mostly, I mean, we try our best to be forward compatible so that we don't introduce any major breaking changes with new versions. So even if we change the syntax for some of the mod stuff, we'll keep the old syntax in there and we'll just, in the game log, we'll display like a warning message saying like, hey, this is a deprecated feature. We might not support this in the future. So you might want to change it, but we try to keep things working. If there is a bug, whatever, we just kind of rely on people reporting them to our bug tracker either on the engine's bug tracker or even our game's bug tracker. All right, I hope this answers the question. Are there any more questions from, if not, I do have some. Okay, I will just, too, because I'm also doing the translator, the translations in the FSFE. And I was wondering, do you have any translations and if yes, how do you manage them? So yes, we absolutely do. I think I get how many languages we have. I mentioned on one of these slides. Okay, so yeah, we have 29 different languages. And before we would manage them manually by having people send in their translation files that you could just add it with a plain text editor, but we switched to using trans effects as a service. So, yeah, someone in the chat just posted the link to the translation page on our wiki. So, yeah, there's instructions on there for how to get into it if you're interested in translating Flare to your language or making some of the existing translations better. Thank you very much. There are multiple users typing right now. Is it possible that Flare will become available for iOS in the future? So we had considered it at one point. I think there's actually still an iOS platform file in the source files. But I don't think anyone's actually worked on it since that was introduced. We don't generally want to support iOS because Apple's App Store is so closed off that we don't feel well, like, supporting that ecosystem. I mean, one thing we'd like to do is get Flare on FDroid for Android devices as well, because right now you have to download the APK and install it manually. I mean, maybe iOS will come one day, but it's not something immediately in the plans. Thank you for the answer. What challenges did you come up against when initially setting up your development environment back in 2012? So, I don't remember the specifics, but Flare has always been very easy to set up. If you download the source for Flare, there's an install.ngin.md file, and that has pretty good instructions for a bunch of different OSes. So getting set up on Linux is very easy because usually you have all the tools that you need. All you need is Git, CMake, GCC or C-Lang, whichever compiler you prefer, and that's about it. And the SDL2 libraries in most distributions provide those. Recently, we made getting it built on Windows easier too, thanks to M-Sys2, which is a great piece of software. Before, people were trying to use Microsoft Visual Studio, and that was kind of a mess, so it's nice to have an over-source solution for that. But yeah, I think getting set up is pretty simple. I mean, I'm more than happy to answer any questions if people have them, like trying to get, if they want to start developing for Flare. How many developers do you have? So, I mean, I think it's been a lot, but right now it's mostly just me. Like I said, we had one of the contributors working on engine features for 1.13, so people come and go. That's the nice thing about free software, like there's no real commitment, so whatever you feel like working on, you can work on. Usually we're pretty open about new features. We do like it if people run it by us first so that they don't do any unnecessary work. But yeah, like you're free to kind of do whatever you want. All right. Regarding this, I do have another question if that's okay. Sure. What would you say are the challenges of developing a free software game, and what would you also say are the main advantages? I mean, I don't think there's any real challenges that are different than developing proprietary software. I mean, probably the biggest thing would be that if you're developing a small project or if there aren't a lot of developers, you end up kind of playing multiple roles. So all the time I'm not, I don't spend my coding or even working on the game. It's usually just like answering emails or questions on the issue tracker or the forums or anything. So kind of like being community manager is part of it. Unless you have like a really big team where you can have someone like dedicated to that. Yeah, you do sometimes have to play like multiple roles and that's probably the hardest thing. But the nicest thing is that sometimes unexpectedly people will step up and fill in things that you don't want to do, which is nice. That sounds very nice. Yes. Okay, there's not a last question in the chat and then I would say we close the questions after this one. If that's all right. I see you support AmigaOS 4. Are there any plans to support older Amiga platforms? So we don't manage the Amiga port that was actually done just by a fan. So I guess that would be up to them. I don't know how well Flare would run with Amiga, like all the versions of AmigaOS. I mean, it might be okay. It might not. I don't have an Amiga to test it on. That would be interesting to actually see in action. Okay. Thank you very much. Yeah, thank you for this interesting talk. Yeah, thank you for having me. Chris of the Games world.