Beta Final Fantasy for NES [PC Beta Available]

Hyomoto

Member
@tetherline - I'll admit it's more ambitious than I thought when I started :p

@Red_Wing - I looked into the old code recently seeing if I could clean it up a bit and I didn't hit that bug. I don't want to expend too much energy on it since it's a problem in the old engine, but at the same time it bugs me knowing the demo doesn't put it's best foot forwards. If you can help me track it down with the whole error message I'll see if I can't at least fix that.

@stenol - Then you are in the right place! It's not available yet, but there's another person working on a similar project to mine but they are using Unity. You aren't alone!
 
R

Red_Wing

Guest
___________________________________________
############################################################################################
FATAL ERROR in
action number 1
of Draw Event
for object parent_battle_actor:

I64 argument is unset
############################################################################################
--------------------------------------------------------------------------------------------
called from - gml_Object_parent_battle_actor_Draw_0 (line 9)
called from - gml_Object_obj_system_render_Draw_0 (line 21)
called from - gml_Object_obj_render_Draw_77 (line 108)


I didn't post the full error because it's the exact same error someone else mentioned. Happens right before the battle screen.
 

Bentley

Member
very region has something or someone who is contributing to this problem, and defeating them will also reduce the threat level of the whole area. As an example, the Kingdom of Elfland is being terrorized by Astos. As fight in that area you thin out the monsters, but once you've defeated him the whole area becomes safer. Thus there is a benefit to fighting. Trying to grind your way to the Marsh Cave may be quite difficult before you've taken down some of rabble around the city. In this way, running also comes with a sort of penalty. Yes, you avoid combat: but the threat level remains unchanged
Sounds very cool. Making my favorite game of all time even better : )
 

Hyomoto

Member
I hate to leave things dangling so it's probably a good time for an update. While rebuilding the engine I did some really great work concerning how the rendering pipeline works, it's some of my best work to date. So much so that I've been refining and iterating on it in a lot of ways. However, as for the rest of the project, I'm just not finding that I'm really happy with the results. What it really comes down to is some of the systems I want to create, I'm finding that my results aren't quite what I want them to be. What it comes down to is there are some systems I'm good at, and some systems I'm not and I don't want to build the game using half-designed building blocks. I know well enough that 'perfection' is a silly goal, and I don't mean to imply that I'm chasing some mythical standard. Heck, others have warned against that exact problem in this very thread when I announced I was rewriting the engine. But something that may come to no surprise to anyone is I'm completely self-taught. I've never taken a programming course in my life, and besides the manual for various languages I haven't even read a book on the subject. And while I do have more than twenty years of experience in coding, absolutely all of my knowledge comes from personal projects and observation.

Recently I decided to change that and picked up two books, "Game Programming Patterns" and "Procedural Content Generation in Games". The first is all about how to structure tasks in coding, and the latter is pretty self-explanatory. So what I've been doing recently is not so different to the Tetrix project I did a few months ago: prototyping smaller projects with an emphasis on trying out new ideas in systems.

So where does this leave this project? Right now, out in the cold. I do hate to leave a post like this, it's easy to read it as a death knell in a digital world obsessed with short term results. So the reason I am writing it is not to convince anyone I'm still working on it, I've literally just said I'm not, but rather explain why I'm not. This is a project I want to accomplish. It's a personal goal if you like, but it's not a short-term one or one I can satisfactorily finish. Instead I'd like to build up more knowledge and try out some concepts that have been bubbling in the back of my mind. I'll probably push a few smaller prototypes, enjoy some Stellaris (for reasons I'll probably never adequately understand), and let this one simmer a bit.

To those of you who have posted that annoying bug, @Red_Wing and @Roa, I uploaded a fix to that particular bug (should work, tests fine). It should be playable but as I've said before, I don't want to invest too much time fixing an engine I'm not going to use. Not to mention it's a bit... well, it's not total spaghetti but it's not terribly easy to pick at either.
 
When you're making a big game - especially when alone or in a very small team - even chasing good code is usually a pipe dream. As long as you release a product, nobody cares. The original Binding of Isaac, the recent Celeste, and heck, the original FF on NES are proof of that. Granted, I completely understand abandoning this project. It's a passion project, it's someone else's IP, and it seems like almost all code is unrecyclable. Others might be disappointed with your decision, but in the end, it's your decision. I'm certainly not going to criticize it.
 

Hyomoto

Member
@nacho_chicken - Rather than abandoning, I'd prefer to describe it as putting it aside. It's something I want to do, it's just not something I want to do right now. But, I'm not wholly against your description either since again, my goal isn't to leave some door open or convince people it's somewhere it isn't.

But, I will address one thing. A lot of the code I've written is quite good, at least from my perspective. I've come up with a number of novel ways to handle various tasks, and I've been really happy with how much I've improved in the time I've spent working on this engine. I came up with a useful approach to handling inputs, found ways to reliably implement frame skips, how to decouple the render size from the window size, gotten better at decoupling game systems in general, and a whole lot about how to handle the queuing and execution of tasks both in a single frame, and over time. I don't have to tell you this, but games are big. It isn't enough to write a battle system, or a map system, or a save system, or a controller system, or a music system, or a data system, or a render system, or any other word you could put before system: it's about tying them all together. And that is where I'm unhappy with the results, so my goal is to work on some smaller prototypes and experiment with some different styles. I'll return to this project eventually, whether publicly or privately, when I feel it's a size I'm better suited to handle.

But thank you for the words of support as well. A lot of people have spoken highly of the project, and I hate to put up a gravestone.
 

Field Magic

Member
I know exactly how you feel and have been there many times also. Its unfortunate because what you had managed to achieve was outstanding, I can't imagine how much work had gone into it. Looking forward to seeing what you do in the future.
 
A

Alexandrowich

Guest
this looks promissing, i'd like to wish you power on reviving a good retro game, keep it up, m8
 
J

Jafman

Guest
@Hyomoto After playing your Castlevania game I just had to give this one a try but the link is broken. Am I too late to the party? No pun intended, least not at first. Looks very good!
 

Hyomoto

Member
@Jafman I dug into this the other day and even though I updated the link it gives me the same issue. I'll figure out what's wrong, but for now I wanted you to know I looked at the problem and it seems Dropbox is misbehaving.

That said, you can try again, I did update the link, but it didn't work for me here.
 

Hyomoto

Member
@Jafman - While I can't say for certain, it seems to be a copyright thing. Perhaps someone thought I was distributing the ROM or something, which is a bit flattering though it's more likely a drive-by DMCA takedown. That seems to be the issue, however. It might be possible to subvert that but I'd rather not get my dropbox suspended, so until I can unblock the link it is, unfortunately unavailable.
 
J

Jafman

Guest
@Hyomoto Haha yikes I hope that's not the case! I guess a clone give or take is harder nowadays with modern day data recognition, it's easier to spot duplicate work on the net. The engine looks tight, are you thinking of using it in other projects if this is a stickup..I mean takedown?
 

Hyomoto

Member
@Jafman I'm writing/written (it's a living thing!) a different engine but some of it is definitely based on what I learned here. It'll end up a topic here eventually but if you are interested I post to the Gamemaker Mentors Discord, so that's one way to get a peek. But right now I'm using it in a small ARPG, I'll also be using it for the jam later this month.
 

Hyomoto

Member
It's been a while since I've updated here, and in many ways, it would be understandable to consider the project dead. This isn't entirely true. If you read back over this thread, you can see little omens of what was to come, as I spent time reconfiguring and rejiggering the codebase. The mistake that I ultimately ended up making is I didn't really keep good backups of the code as things progressed and after a while, I had a lot of clashing codebases with no way to return to earlier versions. This is why the final release build ended up with a crashing bug during battles that I really ended up being unable to figure out. Going down that rabbit hole, I ended up finding entire blocks of logic that seemingly went nowhere or did nothing. Probably remnants from an earlier time. Bad stuff, and in need of a clean start. However, starting over is never fun, and anyone who does it too much will likely never complete their project. It's just the way of things it seems. However, this still is a passion project, and despite having not really worked on this project directly, I have been hard at work on something else that I've talked about before.

For the past few years, I've been trying to write a useful toolkit that would help with the making of games. I don't want to dive into the nitty-gritty here; the short version is I see a lot of extensions and things people create as solutions. Solutions are all well and fine if you happen to have that specific problem, but what I want is more baseline and less rigid. I can code a platformer, or an RPG or a puzzle game. That's all well and good. Regardless of the type of game I make, however, there are some things I do over, and over again. Data storage and retrieval, controller inputs, scene transitions, etc... things that aren't really tied to a specific game but are generally helpful in any project. So, after five rewrites and a lot of feedback I've finally gotten them into a shape that I feel confident about. So what's the litmus test? Why porting someone else's project to my codebase and see how well they work. Next on my list is to reboot progress on my FF remake. It's too early to show off anything super concrete because I suppose, "I'm being more careful about how it is structured" is a fair enough description. That said, using those tools I was able to put together a few pieces fairly quickly and painlessly. Work has progressed from there. When I first started this project, I thought I would have a playable build in two weeks and probably be about finished in a month. Assuming that I had done a better job, it would have taken three times as long (or more, honestly) but it would have been finished. Given that I'm more than two years late, you can see where a lousy decision can get you off track.

So, I'll start updating this post as things progress, and I'll start talking about some of the underlying tools that will hopefully make this a more successful attempt. What I can say, having had two years to mull it over and one failed attempt to back it up, I am going to scale my ambitions back. At least initially. I want to aim for my original goal: a mostly faithful recreation of the original game with changes here or there to my personal taste. Once that is done, well, perhaps the sky is the limit. For now, this remains what it always was: a passion project. I don't expect most people are genuinely excited about a reasonably faithful adaptation of an NES game, but ultimately I do these things because I find it fun and I want to. For the few people out there who might enjoy it, well then it's for you too. Until next time, here are some images of things that are currently working. I'm still insisting on the dynamic color palette; it's something I decided I wanted to do day one and that much hasn't changed.

test_gif2.gif test_gif2 (1).gif
 
Last edited:

Hyomoto

Member
I'm not going to write a nice long post or anything, but I did reach another milestone I wanted to share. This time around, I am a bit lazier about how I handle things. When I started this project, I was coming off of GMS1.4. I didn't fully appreciate some of the new tools that are available in GM2, tools I am leveraging this time around. Namely, the room editor in GM2 is vastly more powerful and useful. In GMS1.4 and prior, I always built controlled"scenes," which were made up of depth-sorted objects that were self-contained. It works fine, and I still use this technique. For things like complex interfaces, however, it requires intricate control logic for things to happen in a "safe" way. Well, this time around, I'm just making the various interfaces into their own rooms. I don't really have to do it this way, but thanks to the expanded room editor, I can build a sort of WYSIWYG-style editor:
upload_2019-10-9_22-37-35.pngupload_2019-10-9_22-54-24.png
On the left is what I put into the room editor, on the right is what is seen in game.
Looks so pretty! There's still a fair amount of logic necessary to make this work, but it allows me to plan and visually adjust the scene. Behind the scenes, all of these objects provide sizing and other generic identification information that is used to structure the scene internally. I could still do this entirely in code. The room is just used to populate the parameters for these objects, and it could come from anywhere. The room does provide one extra benefit: I can leverage the scene transition logic. I can treat going to a menu exactly like changing a location. Internally it's all the same code. The underlying systems are smart enough to understand what type of scene it is and cull logic as necessary (maps have character-state logic that is ignored in scenes that aren't maps ).

I have actually finished all the vehicles as well. It is now possible to create and traverse every map in the game... if they existed.
That is my update for today. Interface logic has always been a bit of a pain, so having that done makes it easier, but there's still much work to do. I've decided to split the game into roughly two halves, and base my work on it that way. The first half is the world: movement, menus, saving, characters. The other half is combat. That may sound like an uneven division, but it's the type of work that matters here. The world logic, comparatively, is simple. Maps are a simple object to define some parameters, and everything else is procedural or derived somehow. Very little code goes into making a new map, usually two lines. The lion's share of World work is making the maps: the programming is relatively basic. Interfaces are like a middle-tier thing, a lot of their data is derived, but they do all need some custom logic. Battles, on the other hand, are super easy to build: feed them the party and enemy data. However, the actual logic and scene handling for a battle are where things get complicated. Right now, I'm estimating the combat scene will account for half of the overall game code. Right now, there are roughly 7500 lines of code. 4200 of those lines are FAST, the library backend I'm using. All of the interface and world logic takes up 3200 lines with another few hundred expected. Combat should easily rival that. That's my update, so until next time!
 
Last edited:

Hyomoto

Member
Here's a little add-on to what I showed off before. As I said above, the new tools do help out a lot with scene construction, but they do not make it any less tedious. The "editor," if you wish, consists of two pieces, the interface parent, the cursor, and the "placer" objects. The placer objects are boxes, images, and text that are replaced with their functional counterparts when the game starts. There are variations and adjustable parameters to affect, for example, how the text aligns. The rest of the magic happens in the interface parent, which essentially constructs a data tree of the scene elements to make it easier to access them. Now, you would be forgiven for thinking that these boxes contain simple draw calls, but alas, it does not work that way. For some things, like the menu tabs Equip, Trade and Drop, it's as simple as providing the path to that text entry in the string database. For the character name, it requires providing a lookup to the position in the Party tree. Things like the class name require looking up the character's class path in the Party tree, then retrieving the path to the text entry from the string database. Under the hood this is complex, but it's just a single line of code per entry:
GML:
        var _class    = node_get( Database, node_get( Party, menuChar + ".class" ) );
     
        ( node_get( Interface, "char.gfx" ) ).icon            = node_get( _class, "gfx.portrait" );
        ( node_get( Interface, "char.gfx" ) ).palette        = node_get( _class, "gfx.palette" );
        ( node_get( Interface, "char.name" ) ).textPath        = menuChar + ".name";
        ( node_get( Interface, "char.class" ) ).textPath    = node_get( _class, "name" );
Where it get's complicated is these lookups have to be written for every. single. element. There's some other complexities that comes out of how the engine renders different layers but what it amounts to is that building out the interface, let alone the various pieces of necessary logic just takes time. Putting together this one scene took between six and eight hours, with a few more hours for writing back end party logic that is needed here. The tedious part is it's mostly just data entry tasks coupling the various interfaces together. That said, I do think the result was well worth it and I'm pretty damn happy with this scene even though I sincerely hope this ends up being the most sophisticated screen I have to build.

upload_2019-10-13_1-40-46.png

On the left, you can see the overlapping elements. On the right, the results of this long work.
To speak briefly on design, you've probably noticed that the menus have changed profoundly. The thing is, the original interface in Final Fantasy, nostalgia aside, is functional. There are concepts I like about it, but it was the result of both time pressure and hardware limitations. While I am keeping the aesthetic alive, there are some conventions that I feel making adjustments is okay. For example, I've done away with the separate WEAPON and ARMOR screens, and replaced them with one EQUIP screen. The item and equipment limitations are principally the same, except instead of four weapons and four armor, you can carry eight pieces of equipment. This change will impact gameplay, different arrangements of special items are possible now, but the effects should be benign. Overall it is a change for the better and simplifies inventory management. As shown here, you can trade items to the other characters, equip and unequip, and drop items you don't want. It also provides an overview of the change in stats that would result from changing your equipment, a popular feature. That's all I have for today, until next time!
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
I'm all for being inaccurate when it results in a better end product! Go for those interface changes :)
(In today's climate it's kinda a scary prospect to make a fangame in the first place, but considering how retro stuff is as popular as ever, you probably could do a graphics replacement and redo map layouts to not be 100% identical to FF1 to make Original Concept Do Not Steal which could safely be sold and distributed and things)

I notice you're allowing for 5-character character names, which is a nice improvement :3 If you've got enough space to make spell names longer as well, it could help making some of the most illegible spell names a bit more understandable (e.g. instead of LIT, use BOLT, and PURGE could be more legible than HARM for the "turn undead" spell)

Another thing that would be nice would be having High-potions and X-potions, the original game only had the weaksauce potions that healed like 20 HP and you could only carry 99 at a time, so if you wanted to save up on magic you'd buy dozens of them in the endgame (one at a time, because that's how the shop worked) and then chug tons of them after every battle.

Another thing that always irked me is how the battle menu has this weird design where RUN is on its own and everything else is in the same column, it feels like a bad use of space to make the menu take up twice as much horizontal space just for one more word. But maybe that's iconic GUI design now... :/
 

Hyomoto

Member
@Yal - Hmm. Enter key slipped. Anyways, the nice part about this project is that all of the data is very malleable so when I'm done it will be a fairly decent engine if I want to use it for future projects. As far as names are concerned, they'll still be short but I'm adding space where I can, and as presented if I want to change something I will. Honestly, I really like the original game in a lot of ways that other people consider broken, but there are parts I know have not aged well. Things you mentioned like buying potions one at a time, but also having three button presses to use them.

I'll be talking about it later on I'm sure, but the game is powered by a custom parsing engine which allows new content to be added fairly easily. For someone like yourself this is all pretty rudimentary I'm sure, but since everything in the game is driven by this data, once the various interfaces are built it's possible to change or add content very easily.
GML:
@item.key        = 1
@item.item        = 2
@item.weapon    = 3
@item.armor        = 4

template.item    = {
    base    = { type = @item.key; buy = 0; sell = 0; name = "no.string"; use = 0; flags = 0; }
    $template:template.item.base
    usable    = { type = @item.item; sell = 0.5; effectivity = 0; }
    equip    = { sell = 0.5; equip_on = 0; equip_by = 0; effective = { family = 0; element = 0; }; attack = 0; critical = 0; accuracy = 0; defense = 0; mdef =0; evasion = 0; }
    weapon:template.item.equip     = { type = @item.weapon; equip_on = 0x01; }
    armor:template.item.equip     = { type = @item.armor; }
}
armor    = {
    body.cloth:template.item.armor    = { name = "armor.body.cloth"; buy = 10; defense = 1; evasion = -2; }
    $template:armor.body.cloth
    body.wooden    = { name = "armor.body.wooden"; buy = 50; defense = 4; evasion = -8; }
    body.chain    = { name = "armor.body.chain"; buy = 80; defense = 15; evasion = -15; }
 
    }
It is funny that the "fangame" is in such a strange place right now, but my intention has never been to sell this project. If anything I'm using it to refine a series of tools that I used to create it which I hope maybe will be worth selling. Thank you for your thoughts!

@CombatCalamity - I probably should pull down those links. The old version of the project is no longer available, sorry for the confusion. I'll update the main post.
 
Last edited:
  • Like
Reactions: Yal
C

CombatCalamity

Guest
@Yal - Hmm. Enter key slipped. Anyways, the nice part about this project is that all of the data is very malleable so when I'm done it will be a fairly decent engine if I want to use it for future projects. As far as names are concerned, they'll still be short but I'm adding space where I can, and as presented if I want to change something I will. Honestly, I really like the original game in a lot of ways that other people consider broken, but there are parts I know have not aged well. Things you mentioned like buying potions one at a time, but also having three button presses to use them.

I'll be talking about it later on I'm sure, but the game is powered by a custom parsing engine which allows new content to be added fairly easily. For someone like yourself this is all pretty rudimentary I'm sure, but since everything in the game is driven by this data, once the various interfaces are built it's possible to change or add content very easily.
Code:
@item.key        = 1
@item.item        = 2
@item.weapon    = 3
@item.armor        = 4

template.item    = {
    base    = { type = @item.key; buy = 0; sell = 0; name = "no.string"; use = 0; flags = 0; }
    $template:template.item.base
    usable    = { type = @item.item; sell = 0.5; effectivity = 0; }
    equip    = { sell = 0.5; equip_on = 0; equip_by = 0; effective = { family = 0; element = 0; }; attack = 0; critical = 0; accuracy = 0; defense = 0; mdef =0; evasion = 0; }
    weapon:template.item.equip     = { type = @item.weapon; equip_on = 0x01; }
    armor:template.item.equip     = { type = @item.armor; }
}
armor    = {
    body.cloth:template.item.armor    = { name = "armor.body.cloth"; buy = 10; defense = 1; evasion = -2; }
    $template:armor.body.cloth
    body.wooden    = { name = "armor.body.wooden"; buy = 50; defense = 4; evasion = -8; }
    body.chain    = { name = "armor.body.chain"; buy = 80; defense = 15; evasion = -15; }
 
    }
It is funny that the "fangame" is in such a strange place right now, but my intention has never been to sell this project. If anything I'm using it to refine a series of tools that I used to create it which I hope maybe will be worth selling. Thank you for your thoughts!

@CombatCalamity - I probably should pull down those links. The old version of the project is no longer available, sorry for the confusion. I'll update the main post.
Please do, I really want to try! :D
 

Hyomoto

Member
Progress is still on-going and today I reached a interesting milestone: of the shop code is now complete. Next up are NPCs, which are well underway. I may do a more complex write-up on shops work, but I'll offer a more simplified description today. I had a few goals unwanted to meet. The first is that they had to properly reflect the original shops, something I've wavered on a bunch of times. The second, however, is that it should be possible to write new kinds of shops that the game doesn't have. Final Fantasy has a number of shops: item, weapon, armor, white magic, black magic, clinic, inn and oasis. While the magic and equipment shops are somewhat similar, every shop has quirks and unique behaviors. My first project just hard-coded this behavior in, which works and allows new kinds of shops but is a lot of work to do. I'd have to write a new scene for every shop largely from scratch. Still, my first attempt in this project was somehow worse!

To make things easier, I wrote a scene manager that leverages the actor model. Objects queue up recipients and commands: method, notify, wait on, wait for, and write. Then those messages are shipped off and completed by the object in question. The waits suspend the queue to inject natural waits and can be a period of time or until an object reports it has finished its tasks. It really worked great! I quickly adapted all of my menus to use it and it greatly simplified them over all ... except for the shops. If I had gone the hard-coded route again, that would have made it easier. Trying to make a single scene behave like any shop AND be extensible to create new interfaces, on the other hand, ended up being mostly hard-coded while relying on external flags. In short I made it worse: I'd still have to hard-code everything, but now I'd also be stepping over all the code I already wrote writing a bunch of exemptions and overrides. I completed the shop interfaces yet again, but somehow with a worse product. Granted, the scene manager was an excellent idea but it wasn't the solution. What I wanted was to be able to describe a shop experience, just describe what happens, and let the shop handle the background logic. So, I started with the actor model and instead of hard-coding scene progress, I coded in the things that happen: gold is removed, party loses an item, etc... then built a shop scripting system to interpret the order of events. Now it's precisely inverted: most data is now in the definition file for that shop.
GML:
magic = {
    start:shop.menus.start;
    menu    = {
        sequence= "menu:uo,wares:uco,%try:can-use>target@ware,confirm:uo,%write:mode=has,%try:have:not>target@ware,%write:mode=hold,%try:get>target@ware,%go:sold";
        menu    = { pane = "menu"; filter = "alive"; options = "%party>id@target"; cancel = "%go:exit" }
        wares     = { pane = "wares"; options = "%wares>path@ware"; success = "%do:get-cost@ware,%line:confirm"; fail = "%line:cant_learn,%go:menu"; }
        confirm    = { pane = "menu"; options = "confirm:common.yes.long,cancel:common.no.long"; fail = "%go:mode"; cancel = "%line:cancel,%go:menu"; }
    }
    sold    = { sequence = "%do:lose-gold,gold:su,%line:initial,%go:menu"; gold:shop.menus.gold; }
    hold    = { sequence = "%line:too_many,%go:menu"; }
    has        = { sequence = "%line:already_known,%go:menu"; }
    exit:shop.menus.exit;
}
Covering this in detail would be painful at best but I would like to cover some highlights. First off, these scenes have a LOT of data but I have a tool in my database I can leverage for that. Since all items shops are the same, I can simply create a symbolic link in the shop entry to the sequence entry. This means new shops are perfectly feasible to write, but once that's been done the data for them only has to be loaded once. You can see an example of that above: every shop "starts" with the "start" entry. That entry is the same for every shop except the Inn and Clinic, so in this case it just inherits that sequence. Next up: sequences. Menus that open, checking for enough gold, etc... every action is laid out in an list of things to happen. There are hard-coded bits, such as getting the current party or the physical windows you can control and write to, but for the most part all these values are written as part of the shop definition. This is something I may go back and clean up one day, the nomenclature is not as intuitive as I'd like, but you'll notice the values in "%try:can-use" are listed elsewhere. These variables are defined as part of the sequences in which they are used, and are not hard-coded. So, using this system all shop logic is now done, the shop templates are now done, and adding shops is as simple as adding a new entry in the database and declaring the wares or cost of staying. Adding a brand new shop is a bit more work, but requires no engine support. As a proof-of-concept that the system works, I added a much desired feature to the Item shop, the ability to buy multiples, purely through scripting it in:
1583015753293.png
Not too shabby! A shop is still limited to the types of activities found in the base game, but it is possible to write clinics that sell heal potions for example, or write completely new scene flow. Which brings me to another relevant topic: I've played around with how much I wanted to change the game. How much of it should be faithful and how much should be new. The honest truth is the project was always meant to be a faithful recreation with small tweaks and additions first, and new content, balancing later. The truth is it's a big project and even as a strict recreation it is a lot of content. So, just from a pure sanity point it's easier and better to just start there. Adding something like the ability to buy multiples is a nice small QOL tweak, and in this case it fits nicely with how things already work and when it comes down to it: the original shop interface did its job. That's the way I'll continue to go for most things. I have some changes I would like to do later on, but I have to eat the horse in front of me first. I've been working on this project, off and on, for about three years now so it's worthwhile to take stock of what's been done and what needs to be done. Once NPCs and Chests are done, the last major coding project is the battle system. After that, content is the major hurdle and the place I've done very little of since starting over. That's today's update and I'll leave it with one more gif. I used to "fake" the text refresh of the windows in the game, but now I have a much more accurate effect, so here's the results of all the shop work.
test_gif2.gif
 
Last edited:

Hyomoto

Member
Well, it's update time again, and it's because I have something interesting to talk about. I'm sure I've mentioned my database format plenty of times, even if I've never covered it in great deal. It's a series of nested maps with extra data attached for error-handling, features, and management. The more I use it, the more I've come to both rely on and find new ways it can be helpful. In the last post, I talked about how the shop uses a "simple" scripting system to drive the menus and decision making. Well, the last major feature I need to complete is battles.

With the shops, I discovered an interesting pattern: I can store information as entries in the database, but what if the "shape" is arbitrary? Things like swords and classes have specific needs: a name, price, etc... There is a defined shape they have to have, and they inherit templates specifically to ensure they all have this data! Shops don't quite work in this way. While they have some data that is required, such as graphical information and a name, the menus sequences are more flexible. When I write a shop, I create the sequences and variables in those definitions. A shop is whatever I make it. It has rules to follow and limitations, yes, but many entries are a product of their own definition. So, for battle, a similar conundrum exists: the animations. I could hard-code the different casting and attacking animations, but what if I want to add more later? I'd have to crack open the engine, add a new case, add an entry to the database to flag it, etc... Too much work and disturbingly similar to my failed first attempt at shops. I want a new animation, why can't I define one?

Good question. Why not? Animations are defined in the database:
GML:
weapon    = {
    speed        = 4;
    repeat        = 2;
    animation    = "swing0,swing1";
    frames    = {
        $template:template.frame;
        swing0    = { battler = { frame = @frame.attack; } sfx = { x = 22; y = -10; sprite = "weaponSprite"; frame = "weaponIndex"; palette = "weaponPalette"; rotate = 270; } }
        swing1    = { battler = { frame = @frame.walk; } sfx = { x = -14; y = 1; sprite = "weaponSprite"; frame = "weaponIndex"; palette = "weaponPalette"; } }
    }
}
Like shop sequences, the list of frames in an animation is defined by the "animation" entry. And like shops, these frames are looked up in the "frames" table. How many frames are used, what they look like, or what they do is up to the tools available. In this case, each frame consists of two layers: the battler layer and the SFX layer. If a layer is not defined, it isn't drawn. Each layer consists of a sprite index, image index, palette, x, y, and rotate value. In addition to that, values can be hard-coded into the animation itself, or looked up in the battler playing the animation. In the above example, the weapon sprite, index and palette are all retrieved from the cached battler data where as the x and y positions are defined explicitly. And the results?
test_gif2.gif
Coincidentally, the whole reason I started investigating this solution was because of magic. Technically it only has one animation, but I wanted to be able to make new spell-casting animations. Fighting has two animations: with weapons and unarmed, so why does magic have to have only one? Originally only the draw data was stored in an item/spell, and looked up by the animation for display. Why couldn't each weapon and spell define it's own custom animation? Well, like the shops, this opens the door to add new animations that never existed in the game and all without touching the engine. Why not do that?
test_gif2.gif
Well, isn't that wonderful! Now, I don't know if I've ever talked about this specific aspect of it before, but the databases at this point are pretty huge. Originally it was just a convenience thing: an experiment really, and mostly for localization. Strings were the first thing to get looked up in the database, and this makes it possible to inherit a different language file. By writing a new file, the game displays in a different language. Voila! Of course, it also allows me to add new items, enemies, and spells, but it also allows patching. For example, I can define the original animation and sprite in the rapier, then load a patch to have it look like this instead. Why? Well, my goal of maintaining two separate games: one that stays true to the original, and also allowing me the freedom to make little changes I like, is suddenly more accessible. Much like the color palette of the render, the game has much custom potential. It also, however, opens the game up pretty extensively for modding potential. While that was never my intention, it is yet another interesting effect of having taken this approach. So much of the game is in these external databases now it's possible to rewrite chunks of it with nothing more than notepad. While a patch loader is relatively trivial, it's fair to say that a lot of the game is still very hard-coded. It's not possible to add a new dungeon, for example, with just the files, but it's still an interesting side-effect.

It's fairly evident from the picture above, but I feel it's worth addressing: the battle scene, in my opinion, was awful in the original game. Trying to recreate all of its idiosyncrasies is plenty doable, but I have no desire to. Some of this is from watching Free Enterprise. I have developed some new opinions about UX because of it, and the original battle system is clunky, limiting, and slow. Still, there is some precedent: Final Fantasy 2 uses a similar format. As anyone who has followed my progress knows, I waver and struggle with how accurate this can all be, and most people tell me to improve the game as I see fit. Well, this is the single most dramatic departure. It would be possible to add the original scene later on if it starts to bother me, but this is the direction I'm taking right now.
 
Last edited:
KIMG0019.JPG
In fact, I'm willing to go so far as to bet I'll be the only person to play my game with a NES controller.

I'll take that bet... well, I would if I could find a link to play your game.

@SilentxxBunny is getting old and has trouble reading sometimes. 🧐
Regardless, I think that this is really cool. My favorite author Hunter S. Thompson typed out The Great Gatsby and Farewell to Arms word-for-word just to get the feeling of what it's like to write an award-winning novel. Later in life he coined the phrase "copy writing" for this method of learning. Anywho, keep up the hard-work. From what I've seen in this topic: It looks like you're well on your way!
 

Hyomoto

Member
So, thanks to some helpful testers the thing is getting hammered into shape. I need to do another "clean run" to make sure things are working properly, but I'm super excited to share some stuff and hoping maybe to have a new build up this weekend! This is all "out of context", and again just a short post, but things are becoming more stable and coming together neatly.
bikke.pngpc.png
 

Hyomoto

Member
The 2.3 beta dropped, and I received an invite, so my plans were derailed a bit. I've been trying to push on this to get it done before 2.3, but Yoyo won the race! I'd still like to get a demo up and running this weekend, but it is not just the beta getting in the way. I had started a new chunk of content that isn't done yet, and I think it is kind of vital to the pacing. Putting 2.3 between that and me is what has held things up.

I'm working on turning the Temple of Fiends into a proper dungeon where you rescue Princess Sara before confronting Garland (or vice versa if you are utterly mad). This requires some small pieces of code I don't have just yet, speech checks do not allow for multi-conditional comparisons, in addition to finishing the dungeon itself. The problem is that right now, you have to grind out levels before you face Garland, but I want you to level up naturally based on the progression of play. The idea is you will go to TOF, rescue the Princess, and then take your new wealth to outfit yourself before heading back to face Garland. The bridge is then built and you can proceed to Pravoka.

However, I have been dabbling with other significant changes that play into this. I want to open the game up more, which means reducing some of the linearity in the early game. So, with some excellent planning and a little luck, you might be able to rescue the Princess and defeat Garland in the same dive. Later on, there are some even crazier plays. For now, the challenge play is to try and clear it in a single pass.

The content on offer will be TOF and Pravoka, with TOF being a full dungeon as described, and Pravoka now including liberating the town from pirates before tracking down Bikke in a new dungeon and acquiring the ship. All in all it's probably about and hour or two of content depending on play style and should offer some interesting choices for different party compositions.
 

Yal

🐧 *penguin noises*
GMC Elder
The problem is that right now, you have to grind out levels before you face Garland, but I want you to level up naturally based on the progression of play. The idea is you will go to TOF, rescue the Princess, and then take your new wealth to outfit yourself before heading back to face Garland. The bridge is then built and you can proceed to Pravoka.
One way you could do this more naturally (and not feel like forced backtracking) could be like this:
  • The door to Garland's secret summoning laboratory is locked
  • You find the princess' prison cell in the basement
  • After you open it (perhaps with a Door Mimic miniboss battle as a way to handwave why the prison cell doesn't need a key?) and get her out, she urges you that you should just run away ASAP before Garland finds out
  • He immediately shows up and shows how powerful he is by summoning lightning bolts to try to hit you, but he's far enough away that you might be able to run away if you just leg it
  • You get a choice "run away" / "fight him" with "run away" being selected by default
  • Fighting him gives you the normal boss battle early, running away makes your party auto-walk through the nearest door (at double speed) and the screen transition takes you back to the entrance to the Corneria Castle (eliminating a bit of backtracking)
  • If you run away with the princess instead of fighting Garland right away, the king gives you a formal request to go and get rid of Garland once and for all (at this point, the laboratory door is open so you can actually go in and fight him)
  • If you manage to beat him early, you'll get some extra praise and get the cumulative rewards for both the "save the princess" and "get rid of garland" quests at once

I'm not quite sure what other tweaks could make the game less linear, it's been ages since I last played FF1 (and my verdict last time basically was "okay it's not aged well") but here's some random ideas:
  • Give most magic shops and weapon shops past the point where you get the ship multiple tiers at once, instead of there being one Lv.3 spell shop, one Lv.4, and so on, and instead bundle the spells and gear together based on the town's speciality (which also gives you a chance to give towns more identity). For instance the town closest to the Peninsula of Power could have multiple tiers of Ice magic because the inhabitants have learned to coexist with those fierce Frost Wolves, but no fire and lightning. This means towns encountered later in the game (in normal FF1 progression) aren't strictly designated as later content, and going there early still lets you find something useful - and affordable - for your trouble that doesn't break the balance completely.
  • Having monsters be level-based instead of having set stats could let you make the four crystal dungeons get tougher each time you clear one (as the Four Fiends get more time to progress their evil plans) so they all start at the same overall difficulty, letting you tackle them in any order. Some puzzles might need tweaks for this to be fully viable, like the fairy costing 50,000 Gil making the water dungeon a bit impractical to tackle first.
  • Bahamut's promotion and the airship might need to have their progression triggered in different ways to maximize openness (going for the Rat Tail as soon as you can to get promoted early could break the balance, and the airship makes the map a lot more open) so perhaps these could be tied to lighting your first X crystals (whichever ones you chose) with Bahamut (and a newly introduced Cid?) showing up more times to help with exposition dumping?
 

Hyomoto

Member
One way you could do this more naturally (and not feel like forced backtracking) could be like this:
  • The door to Garland's secret summoning laboratory is locked
  • You find the princess' prison cell in the basement
  • After you open it (perhaps with a Door Mimic miniboss battle as a way to handwave why the prison cell doesn't need a key?) and get her out, she urges you that you should just run away ASAP before Garland finds out
  • He immediately shows up and shows how powerful he is by summoning lightning bolts to try to hit you, but he's far enough away that you might be able to run away if you just leg it
  • You get a choice "run away" / "fight him" with "run away" being selected by default
  • Fighting him gives you the normal boss battle early, running away makes your party auto-walk through the nearest door (at double speed) and the screen transition takes you back to the entrance to the Corneria Castle (eliminating a bit of backtracking)
  • If you run away with the princess instead of fighting Garland right away, the king gives you a formal request to go and get rid of Garland once and for all (at this point, the laboratory door is open so you can actually go in and fight him)
  • If you manage to beat him early, you'll get some extra praise and get the cumulative rewards for both the "save the princess" and "get rid of garland" quests at once

I'm not quite sure what other tweaks could make the game less linear, it's been ages since I last played FF1 (and my verdict last time basically was "okay it's not aged well") but here's some random ideas:
  • Give most magic shops and weapon shops past the point where you get the ship multiple tiers at once, instead of there being one Lv.3 spell shop, one Lv.4, and so on, and instead bundle the spells and gear together based on the town's speciality (which also gives you a chance to give towns more identity). For instance the town closest to the Peninsula of Power could have multiple tiers of Ice magic because the inhabitants have learned to coexist with those fierce Frost Wolves, but no fire and lightning. This means towns encountered later in the game (in normal FF1 progression) aren't strictly designated as later content, and going there early still lets you find something useful - and affordable - for your trouble that doesn't break the balance completely.
  • Having monsters be level-based instead of having set stats could let you make the four crystal dungeons get tougher each time you clear one (as the Four Fiends get more time to progress their evil plans) so they all start at the same overall difficulty, letting you tackle them in any order. Some puzzles might need tweaks for this to be fully viable, like the fairy costing 50,000 Gil making the water dungeon a bit impractical to tackle first.
  • Bahamut's promotion and the airship might need to have their progression triggered in different ways to maximize openness (going for the Rat Tail as soon as you can to get promoted early could break the balance, and the airship makes the map a lot more open) so perhaps these could be tied to lighting your first X crystals (whichever ones you chose) with Bahamut (and a newly introduced Cid?) showing up more times to help with exposition dumping?
Some of this isn't worth discussing at length just yet, but suffice to say that a) I do have some plans to allow for tackling the Fiends in a more open order, and b) leveled content makes me want to puke on my shoes :p. I often point to Skyrim as the quintessential example of the problems with leveled content: the game actually gets harder the longer you play, and therefore it's technically easiest to beat the game at level 1. There are ways it can be done well, and the concept of pursuing a consistent challenge is novel, but treadmill mechanics are not something I embrace. After all, the reason for the early airship play through Ice Cave is so you can come back and stomp all over Kary later on with higher levels and better equipment. You took on the extra danger in the Ice Cave and Ordeals, that should translate to an easier Kary fight.

That said several of these things are already on the list. I've spent a lot of time tweaking, adding and moving things around between Pravoka and Coneria for these questlines to give the player some interesting choices. You do not have enough money to fully kit out your party before you go to TOF (or as I said, the alternate plays) so making good use of your initial resources is important for saving Sara. If you choose to then face Garland, that's a ridiculous play but it will reward your planning. Otherwise, returning to Coneria allows you to spend new wealth grabbing new spells, armor and weapons to better match the fight. I am tweaking encounter rates, I want fights to be less often but more of a gamble for resources. I've been watching a lot of FF randomizers, and it has adjusted how I think the player should face content. A constant stream of battles you simply run from is decidedly old-school, but if you can get away for free then the battle shouldn't have even been presented. FF already has a lot of punishing fights, so I want there to be more a factor of what you can and should gamble on running from versus constantly throwing you into battles.

I appreciate your thoughts here, I don't know how much what I'm doing will match up with some of them but I'll be interested to hear your feedback if you do give it a go. I'm done with my 2.3 fiddling for now and I am energized to get back to work on it!
 
First off, if any of this has already been mentioned either by you or by someone else, my bad. There's been almost a full page of posts here since last I checked in. Glad to see you're still working on this!

Quick thought on battling the Four Fiends out of order: since each fiend is elemental, with opposing elements, perhaps having already defeated the Fiend of the opposing element will make you stronger in the battle. If you defeat Kraken, for example, the Water Orb is lit, making you stronger against fire fiend Kary.

As for the Garland battle, maybe you could have the king mention outright to the player that if they prove themselves by rescuing the princess they will order the shops in town to let you purchase strong weapons, armor, and spells. Nothing outrageous, since its the start of the game, but enough to give you a little bit of an edge. And perhaps the original mission is just to rescue the princess, with the king only ordering Garland's death once Sara tells him what went on while she was imprisoned.

As a side note, have you given any thought to including elements from other Final Fantasy games that didn't exist yet in the original? Cactuars outside the Mirage Tower, Tonberries… somewhere? Ice Cave, maybe? Chocobos, either ridable by the player or just in towns? Because when I read Yal's comment about the Door Mimic, I immediately thought Demon Wall. Which would of course be insane that early in the game, but still...
 

Hyomoto

Member
The cadence for the Garland section mostly arises from me needing the player to return to Coneria, or more specifically, to have a reason to go back. That's why moving the princess to her own quest works so well, a few good fights will put you well on your way to 3 which is the minimum for beating Garland. Something I haven't mentioned is gold is much tighter in this version, with an emphasis on treasure and certain fights as your major sources of gold. The smaller encounters do not provide nearly as much gold as they used to. That makes it a bit harder to find a balance where the player is aware that their gold is limited and they need to be a little cognizant of what they buy, but not so strict that they feel like they can't spend anything. So, some of that is also providing alternatives. A little peek at Coneria armor:
1587839891536.png
As should be fairly obvious, I am mixing up the gameplay quite a bit. As far as adding things go, there's two new dungeons, a new boss fight as well as a revamped Garland. It's tricky work because I am maintaining a lot of the old school appeal, there are no modern conveniences coming to make the game easier. What I am trying to do, however, is shake up how the game progresses and leverage what I think make the game stand out, namely vicious enemy encounters and chunky combat mechanics. In the end I guess I'm just going to make the game I want to play and maybe someone else will enjoy it too!
 

Hyomoto

Member
And with no fanfare, I've run through today, polished up a few outstanding items and was able to complete an entire play through. I would expect a new player to take about an hour or two to finish the content depending on how thorough they are, and how many wipes they suffer. If you give it a try let me know what you thought and if you run into a bug, let me know that too. Check the main post for the link.
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
I'm noticing you seem to be in a D&D mindset? Digital RPGs have diverged quite a bit from their tabletop roots these days, and that probably colors expectations a bit (even though FF1 is such an early game it maintains a surprising amount of tabletop quirks). I wouldn't think twice about things like grinding for gold if I'm a little short for my latest big purchase (and expecting to eventually end up with more gold than I can actually spend in the endgame, so there's never going to be a reason to save resources for later), random encounters being padding as soon as you're strong enough to tear through them effortlessly, and so on. (I'm more of a person that just mashes A to select "attack" for everyone to harvest any random encounters for extra EXP than try to run away from them, myself)

Some thoughts:
  • If you don't want to allow the player to run away from every encounter, you could always just remove the "RUN" option from the menu entirely (and adjust encounter rate accordingly).
  • Instead of random encounters, you could go the Chrono Trigger route and have NPCs that trigger battles if they spot you (which is more in line with D&D too). More work to set up, but every battle would be more memorable. For instance, in Earth Cave B1F you usually have an encounter with a lot of zombies, you could make this a setpiece by having an invisible trigger partway through the corridor that makes a horde of zombies crawl up from underground using a lovely two-sprite animation, surrounding you completely (and giving you a reason why running isn't an option). More intelligent enemies might patrol an area (allowing you to sneak past) and only trigger an encounter if you walk into their line of sight (which is a literal line in the direction they're facing, until the first wall). Guards and bosses might work the same way, but be stationed so that it's impossible to sneak past them.
  • Another benefit of having the static encounter model instead of random encounters is that it's much harder to grind, some battles might be once-ever and others only reset if you leave the dungeon, so if you don't want the player to grind you could use this approach to limit encounters and make them seek out every scripted encounter (with better rewards) instead of just running in circles near a rest point.
  • If you're worried about the new lack of gold meaning players might softlock themselves without realizing, you could have enemies occasionally drop armor/weapons as a crutch. (E.g. wolves drop [Shirt]W.Pelt armor, ogres [Hammer]OgClub, imps [knife]Rusty and so on). Always worse than what you can buy at that point, always in such bad shape it sells for a pittance (so farming it isn't viable), but it works as a stat stopgap if you spent your allowance really poorly. (This approach also lets you have bosses drop items that are useful, like the items that cast spells when USE'd)
 

Hyomoto

Member
The original was based heavily on D&D and is one of many reasons why it stands out. As for static fights, the pirates, Bikke, and Garland are all static. The player can see and attempt when ready (or avoid in some cases). It's not that I don't want the player to run, the random fights are important to the game and aren't going away. They represent risk and a tax on player resources that games like Chrono Trigger do not have. That said, I don't want to waste is the player's time running. That's what I'm concerned with. The player is going to run from fights, and probably a lot of them, but I want those fights to at least engage the player with a sense of relief, not a sense of annoyance. It's not possible right now, but I might also look into some system where the encounter rate is also lessened in areas as a result of completing content or perhaps party level. Right now enemies will run from you. But like I said, if the battle is just going to be everyone fleeing perhaps no one needs to see it.

Still, some stuff has already been done. The encounter rate, Ambush and Preemptive chances are affected by the attributes of your party leader. The Thief the best at avoiding encounters outright and reducing ambushes. However, they are not the best at tanking hits. Since the party leader is the most likely to be targeted in combat, a Thief is a great party leader when travelling to reduce encounters. However, for static encounters, you can rearrange your party composition to put, say, the Fighter up front. Those are the kinds of decisions I want the player to be able to make when they think of party composition and how to outfit their characters.

As for the gold, it's going to be a contentious debate. I don't want the player to grind for gold, but I'm not going to prevent them from doing it. The thing is, a battle of 5 Imps gives something like 4 gold. Staying at the Inn costs 20. These numbers telegraph where the player should be putting their efforts. It does discourage it, but only for seeking greener pastures and taking on more risks. RPGs have always had "the problem" that you could grind out the game overnight and wake up level 100 ready to roll. What I want is to make sure the player is more engaged by the aspects I like, exploration and taking on risks, than simply holding down the A button to clear out another group of Imps.

And yeah, a bunch of the stuff you mentioned is on the table if not already present. Rather than drop garbage to sell, another form of wasting the player's time in my opinion, I've just dropped the price on basic services. The clinic in Coneria is 10 gold now in case you do need to grind it out. Other changes might come but the thing is, the tax on the player is returning to town to revive a dead character. I'm not also then going to punish them by making it prohibitively expensive. It can't be free because that would diminish the value of proper planning and later towns are more expensive, but having to grind the gold of shame is plenty of punishment. The stuff that is expensive are things that allow you to avoid returning to town such as tents and heal potions, as well as higher tier gear. The goal is to push the player into exploring to find gold and resources, and thereby take on risk, rather than try to convince them to grind out 500 gold worth of IMPs. If you do fight every formation you come across, and I doubt anyone would: that's a LOT of danger, you would certainly hit all your gold and experience milestones.
 
Last edited:
@Hyomoto: I've never considered grinding in RPGs much of a problem. If a player wants to psychotically kill twenty thousand slimes to level up and make all the other fights easier, then that's their prerogative, as far as I care, hahah. Like you said, the trick is to just make grinding less appealing than actually playing the game. If an RPG can't do that, it's in big trouble anyway, hahah.

Congrats on finally getting the game playable from start to finish. This is a really cool project you've been working on for a few years now. I'm really impressed you actually managed to finish it instead of losing steam halfway through. That's some dedication/willpower! O:
 

Hyomoto

Member
Thank you very much! That said, it still has quite a ways to go in terms of content. Still, the engine is back up and running and the game is playable up to a point. Plus a lot of the tools are in really great shape and new content is mostly the fun stuff: designing. I'm fortunate that this project is just a passion project, something I work on for fun, but as you've said: it's been a few years. I'm happy to finally say it's in beta, and is now in the content design and polish stage.
 

Hyomoto

Member
That Garland fight is incredible.
Thank you! A lot of feedback went into it. It always bothered me that Garland's weakness is being jumped by four people. It's like, oh, Garland has the same weakness as every other human. You'd think the king might have figured that out and saved his daughter.

I wanted to lessen the prominence of certain "cheese" strategies, and make him a proper boss fight. So, he gets a new bad ass sprite, and some more ruthless attacks. If you feel like sharing, I'd be interested to hear what level/party composition you used.
 

Bentley

Member
If you feel like sharing, I'd be interested to hear what level/party composition you used.
I have not played the game since I was little, so I'm not sure what strategy I used (but it surely was a dumb one). FF1 just sticks out in my mind as the best game of all time. It was so hard to beat. My NES machine would constantly lose my saved game. I finally got one lucky streak where my game didn't reset and I beat the game. So you can imagine how a little kid, with no help, was trying to survive through that beast of a game. It was just awesome. It's so great to see it being remade.

I love that finger wag by the way. It makes it look like he's cooking up the spell rather than just waiting for his turn. Little things like that you've filled the fight with add so much to the playing experience.
 
Last edited:
Hey @Hyomoto,

Duane and Brando's Final Fantasy Rap just came on my YouTube Radio and it reminded me of your game.

Have you heard it? If not, you might get a kick out of this.


PS: Video Contains Strong Language (and spoilers.)

PS: Sounds like you've made some good changes so far.

I'm still following this topic, and eager to see what you decide to do next. May the wind stay to your back.
 
Last edited:

Hyomoto

Member
This is so cool! My YouTube channel is dedicated to recreating old games and making tutorials on how to replicate the levels/mechanics. This thread makes my soul smile
I see you are a man of cloning as well! If you haven't seen it, I also did a clone of Castlevania for the NES, which is a much stricter clone, and have been working on a NES-style GML engine for a while now. This project is made with the latest version of it, but it's being largely rewritten for 2.3 thanks to the powerful new tools it affords. (Not for anyone anyone who reads this comment, my intention is NOT to port FF over because the workload would be insane.) I often recommend to new users that they pick some simple game they like and try to recreate it. There's a ton to be learned from it. NES games are just where my heart lies, but it's also very easy to get the music, sfx and graphics for them, and they are usually simple enough that it's not an overwhelming project. Supposedly, Nasir Gebelli wrote the entire engine for FF in just a few months, which is pretty good for a full-fledged RPG!

Thank you for sharing your channel, I will definitely swing by to have a further look at your videos.
 

Let's Clone

Member
I see you are a man of cloning as well! If you haven't seen it, I also did a clone of Castlevania for the NES, which is a much stricter clone, and have been working on a NES-style GML engine for a while now. This project is made with the latest version of it, but it's being largely rewritten for 2.3 thanks to the powerful new tools it affords. (Not for anyone anyone who reads this comment, my intention is NOT to port FF over because the workload would be insane.) I often recommend to new users that they pick some simple game they like and try to recreate it. There's a ton to be learned from it. NES games are just where my heart lies, but it's also very easy to get the music, sfx and graphics for them, and they are usually simple enough that it's not an overwhelming project. Supposedly, Nasir Gebelli wrote the entire engine for FF in just a few months, which is pretty good for a full-fledged RPG!

Thank you for sharing your channel, I will definitely swing by to have a further look at your videos.
Cloning was the first thing that came to my mind after my first programming class haha. It's been an honor to re-create my childhood, haha.
Castlevania is certainly on my list. And I REALLY want to make Super Ghould n Ghosts =P
 

Hyomoto

Member
Small update here, just to let people know what I've been up to. As I mentioned before I've been playing with the GM2.3 beta and that's been pretty much my focus as far as programming goes. Learning the ins and outs, reporting bugs, etc... Well, they just launched beta 10 the other day and put out a stability update just before the weekend so yesterday I thought I would give porting it over a try. For those of you interested in porting your projects over to 2.3 one day, I was actually able to get it working after a handful of hours, so that's promising. That said, I wouldn't consider it stable in the slightest. The new resource tree absolutely *hates* having resources moved around. Holy crap is that thing broken. I had to use Sahaun's excellent YYP Maker to essentially piece the program back together. There are also the litany of bugs to work around, but basically I wrote big ass patches over the top of those problems and it seems to have sealed up the worst problems.

For those that want a few technical details, there were three major issues I encountered. Two were array-based, and one is due to a change in a behavior in resource inclusion. The first one is that the copy-on-write behavior of 2.2 is broken in 2.3, which means that all array operations in functions behave as though you were using the @ accessor. This is a bug and needs to be fixed. However, the other issue is that GMS2 has always had a fairly inconsistent attitude about whether it passes arrays by value or reference. The developers will argue otherwise, but I really don't care: there's no way to know if you are operating on a new array or a reference and that's frustrating. Well, it would seem that this has either gotten better or worse in 2.3 depending on how you want to look at it. Now it seems to always pass by reference, leading to the above bug, but also inverting 2.2 array passing behaviors. Namely, arrays were always passed by value before, except when they weren't, and now they are always passed by reference, except when they aren't. In short, it's like an inversion of the previous problem. The last major issue was due to taking advantage of undocumented behaviors in GML, which you should not ;). In this case, in 2.2 your scripts and objects are loaded in the order that they are present in the resource tree. Because of this, you can move things to the top that you want to be loaded first. I won't say this is completely broken in 2.3, but it has changed. If the behavior hasn't changed, the new resource tree does not make it clear what order things are going to be loaded in. I haven't played with it to see if it's still possible to manipulate it, but I can say that FAST, the backend I use to make all of my games, relies on that behavior. While I have written a new version for 2.3 that does not, FF uses an older version and it is not a 1:1 replacement. So, I had to band-aid that version into loading in 2.3 using some messy singletons and goofy hacks. This was a problem of my own making, but if you are the type of person to rely on quirks and edge cases in GML like I tend to, 2.3 is going to throw you some curve balls.

That said, 2.3 is shaping up fairly nicely. Given that it's mostly ported over at this point anyways, I might just continue with 2.3 on FF. While I'm not going to rewrite it to make use of the 2.3 features, having them going forwards is desirable. There are still some random crashes and odd behaviors but I'm hoping that those will clear up as 2.3 becomes more stable. Here's a plug for that tool I mentioned, and a picture of my first attempt at getting the battle scene working alongside a gif of it working to show the oddities.

YYP Maker by Sohom Sahaun

1593961848787.pngtest_gif2.gif
 

Yal

🐧 *penguin noises*
GMC Elder
In this case, in 2.2 your scripts and objects are loaded in the order that they are present in the resource tree. Because of this, you can move things to the top that you want to be loaded first. I won't say this is completely broken in 2.3, but it has changed.
I'm really curious what sort of behavior you had that was dependent on the load order, I had the impression the room creation order (which you can customize) was the only thing that could affect creation dependencies. Was it based off of the "run this globally before the game really starts" pragmas?

Namely, arrays were always passed by value before, except when they weren't, and now they are always passed by reference, except when they aren't.
I think this has been there since 2.2, it's just the edge cases that has changed. I had a weird bug in my 3D engine which was caused by me assuming arrays were always copied when you assigned a variable to an array value, but it turns out the variable was assigned an array reference by value instead, so rather than copying the data and then changing part of it (which was my intention), I changed the original and the copy at once since I was operating on an array reference. It's probably safer to always pass entire arrays around as if they were immutable and read them to new variables / overwrite an entire array at once than trying to edit them in-place. (When you use small arrays as a sort of shorthand for tuple data types, at least)

This is a bug and needs to be fixed.
Make sure to report it through the official channels if you haven't already, I don't think Yoyo checks this thread regularly :p

And yeah, the rampant instability is a big reason I've not moved over to 2.3 yet... everybody assumes I've done so since I'm a long-time GM user, but I'm having enough issues dealing with my own bugs 🦈
 

Hyomoto

Member
I'm really curious what sort of behavior you had that was dependent on the load order, I had the impression the room creation order (which you can customize) was the only thing that could affect creation dependencies. Was it based off of the "run this globally before the game really starts" pragmas?
Short answer: yes. It took the form of defining foundations that other code could then expand upon. We didn't really have proper singletons in 2.2, and we have a lot of interesting flexibility in terms of on-demand inclusion in 2.3. While all scripts are essentially run as though they had global pragma, the new resource tree doesn't necessarily reflect the order things will be loaded. I haven't toyed with it to figure out if there is a filter mode in which it does, but it was risky to rely on before, and now just a bad practice :D
I think this has been there since 2.2, it's just the edge cases that has changed. I had a weird bug in my 3D engine which was caused by me assuming arrays were always copied when you assigned a variable to an array value, but it turns out the variable was assigned an array reference by value instead, so rather than copying the data and then changing part of it (which was my intention), I changed the original and the copy at once since I was operating on an array reference. It's probably safer to always pass entire arrays around as if they were immutable and read them to new variables / overwrite an entire array at once than trying to edit them in-place. (When you use small arrays as a sort of shorthand for tuple data types, at least)
Indeed. The problem isn't entirely new, it just seems to have inverted. Before you could generally rely on the copy-on-write behavior, and that your array was being passed by value. While the copy-on-write behavior is definitely broken and definitely needs to be fixed, the other one is more subjective. Was it, as above, a quirk of the engine I relying on? Or was it just a bad coding practice? I reported and discussed this at length with Mike and Russell during the original GMS2 beta, but they insisted that its no big deal. So, like most people I just used it as it behaved but that behavior is just different enough to cause problems now. Personally I'd like it to be passed by reference and give us an easy way to dupe an array, that way we can always know whether we're operating on a reference or copy.
Make sure to report it through the official channels if you haven't already, I don't think Yoyo checks this thread regularly :p

And yeah, the rampant instability is a big reason I've not moved over to 2.3 yet... everybody assumes I've done so since I'm a long-time GM user, but I'm having enough issues dealing with my own bugs 🦈
I think there's only one bug I'm sitting on, I'll probably get around to reporting it after typing this, but all of those bugs have been written up and replied to except for the copy-on-write bug. Which, arguably, is the worst ;P Small addendum there, it's actually kind of worse/better. The copy-on-write fails in a really specific scenario, not just all the time.
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
Personally I'd like it to be passed by reference and give us an easy way to dupe an array, that way we can always know whether we're operating on a reference or copy.
You could always write a script with these contents?
GML:
///array_dupe(sourcearr)
var ret = array_create(array_length_1d(argument0));
array_copy(ret,0,argument0,0,array_length_1d(argument0));
return ret;
(written in GMS2 flavor GML since I've opted out of the beta)


Whenever it's possible to eliminate redundant boiler-plate work with a script, it's always a your time gain to go for it, even if it's not a CPU time gain. Your time is more valuable.
 

Hyomoto

Member
Not what I mean. The issue has always been we don't know because it's always true... except when it isn't. Those edge cases could be considered bugs, fair enough. But, I would prefer that arrays always be passed by reference, rather than value. Making boilerplate to handle copying an array isn't the issue there. I mean the simplest example is

array2 = array1

Does this make a new array or pass a reference? Historically, it would copy the array. Usually. But I would rather have to explicitly call for a copy, since passing an array reference around rather than a copy could be useful. That said, we can now wrap the array up in a struct and pass that around, so at least we do have a better option than we used to. In fact, now there's no easy way to copy a struct, they are always passed by reference.
 

Hyomoto

Member
Another small update. With beta 11 and another pass to correct bugs it looks like FF successfully ported over to 2.3. The last major bug I encountered had to do with the changes to arrays. Seeing a pattern? Anyways, this last bug was something I hadn't noticed: I was apparently treating 1d arrays like 2d arrays in one very specific scenario. In 2.2, all arrays are secretly 2d arrays, and you can perform 2d operations on them. This is not the case in 2.3 and I hadn't realized a bug in my code was relying on this quirk. Once I figured that out it was fairly simple to workaround and fix it. In this case it really wasn't even 2.3's fault, it just made that problem noticeable. However, I was able to play through a large chunk of content and encountered no issues so while I hesitate to call it fully stable, I think I can start working on it again using 2.3

Right now I'd still like to avoid rewriting code but honestly a lot of methods I was employing were because of how GML in 2.2 is structured. With 2.3 I can improve some of these systems, but we'll see.
 
Top