Hyomoto
Member
The journey continues. Anyone who has followed this project will know it's been ongoing for a while. So let's get the ugly stuff out of the way first, yes: I am doing a rewrite. I'm really not going to beat around the bush with this one: GMS2.3 gives us tools to write code in sensible ways, and many tools I wrote in 2.2 were just pale imitators of modern features. It's just not an option for me. I can either plow through with half measures or I can write the game the way I want to. That said, this game has long been the breeding ground for a lot of ideas, it's almost more of a technology test bed than an actual project at this point. Probably disappointing for anyone who actually had ambitions of playing this game. I apologize for that, but it turns out I like writing the tech more than the game.
It's not all doom and gloom, because in some ways I'm actually closer to being finished. The thing is, the difficulty of a project is directly proportionate to the quality of the tools being used to make it. The original game had very little tools, it was built using what I thought, at the time, was a good way of doing things. With each iteration I decide, no, this is in fact not a good way to do something. Generally that point comes when I encounter a bug or upkeep becomes a bit cumbersome. It's said that the quality of software is directly proportionate to how much work it takes to maintain. If adding features creates more difficulty, this is considered a bad system. I can say that I have written some bad systems.
But I've also written some good systems, things that actually make writing things easier, faster, more flexible and therefore more fun. I have a library of tools I call FAST that I've been tinkering with for years, and FF has always been built on some variation of those tools. If you want to know more about them I have made them available on GitHub, but the general idea is they don't do anything by themselves. You won't find any dialogue systems, or inventory systems, or physics systems here. Instead it provides simple, extensible frameworks that are designed to make programming games easier. One such feature I would like to demonstrate today. I've been writing a scripting language for FAST, the idea being that I can port all of FF's interfaces, main menu, inventory, etc... over to these scripts. People familiar with scripting languages like Lua or Yarn (the two languages I took inspiration from) will recognize the benefits. The benefit here is that this is pure GML, it should port to any system that GM will, but frankly I just wanted an easier way to write interfaces. FF was already making use of around three scripting systems in combat, shops and loading files so this also just consolidates that all into one nice neat package. Enough ramblings, here's a boring video demonstrating me write an interface for the game in real time purely using scripts!
It's not all doom and gloom, because in some ways I'm actually closer to being finished. The thing is, the difficulty of a project is directly proportionate to the quality of the tools being used to make it. The original game had very little tools, it was built using what I thought, at the time, was a good way of doing things. With each iteration I decide, no, this is in fact not a good way to do something. Generally that point comes when I encounter a bug or upkeep becomes a bit cumbersome. It's said that the quality of software is directly proportionate to how much work it takes to maintain. If adding features creates more difficulty, this is considered a bad system. I can say that I have written some bad systems.
But I've also written some good systems, things that actually make writing things easier, faster, more flexible and therefore more fun. I have a library of tools I call FAST that I've been tinkering with for years, and FF has always been built on some variation of those tools. If you want to know more about them I have made them available on GitHub, but the general idea is they don't do anything by themselves. You won't find any dialogue systems, or inventory systems, or physics systems here. Instead it provides simple, extensible frameworks that are designed to make programming games easier. One such feature I would like to demonstrate today. I've been writing a scripting language for FAST, the idea being that I can port all of FF's interfaces, main menu, inventory, etc... over to these scripts. People familiar with scripting languages like Lua or Yarn (the two languages I took inspiration from) will recognize the benefits. The benefit here is that this is pure GML, it should port to any system that GM will, but frankly I just wanted an easier way to write interfaces. FF was already making use of around three scripting systems in combat, shops and loading files so this also just consolidates that all into one nice neat package. Enough ramblings, here's a boring video demonstrating me write an interface for the game in real time purely using scripts!
Last edited: