Beta Final Fantasy for NES [PC Beta Available]

Hyomoto

Member


Final Fantasy NES Remake
by Hyomoto
The original Final Fantasy on NES is still one of my favorite RPGs of all time, and it's something that I like to return to every so often. The mechanics may seem relatively simple by modern standards, but this game was less about min-maxing and more about gathering up your swords, your spells and your items. Preparation was how you survived the journey, one both hard and rewarding. In some ways old RPGs like this boasted true freedom. The worlds may not be quite as huge, but where pacing is rigidly controlled in modern games, here the world is laid bare for you. Gather up your party and head out, go where the winds take you and experience an epic journey. It is a classic that to this day informs what an RPG should be and, unlike the NES original, this version comes packed with QoL features and bug fixes. Never has it been so playable!


Why?
If you check out @Mike's YouTube channel you'll find a lot of videos about faithfully recreating old games using GameMaker, and watching these inspired me to try it myself. Not only is Final Fantasy one of the very first video games I ever played, but, as I've learned more and more of it over the years, I've come to appreciate it as a "flawed masterpiece." It was made on a time and budget constraint, and a lot of the content either wasn't tested thoroughly or perhaps was broken but never fixed. Many spells do nothing, others do the opposite of what's intended. Run calculations are bugged. Elemental resistance and weaknesses don't work. The list is fairly large. The ports of the game do make changes to "fix" these things, but each release also pushes away from it's original experience and made it a fairly generic entry in the franchise. What FF "was" is a product of compromise and limitation, and so stands out as a unique entry to this day. It is my favorite, and I've always dreamed of being able to play a bug free version. Originally I looked towards ROM hacking since most of the bugs have been fixed but then I thought, why limit myself? Building the engine means I can both make it compatible with modern PC hardware and I can fix, change or add whatever I'd like. Some parts of the game have aged better than others, and I have ideas about what is important to keep, and what I believe can be changed. Now I can.

So what's this about enhancement, then?
The goal started out as recreating the game faithfully both in mechanics and presentation, and I will still endeavor to do so as closely as possible. Many changes will boil down to bug fixes, things that are demonstrably wrong and fixed in later versions, but many impact how the game plays. On the one hand, I'll be adding frames of animation, cleaning up artwork visually and adding color depth. These changes won't affect how the game plays. On the other hand, the game is also exceptionally simple and obtuse. I've also added new locations, dungeons, items, spells and boss fights. In both cases I my goal is to retain the original experience, to avoid changing things just for the sake of being able to. Still, it's my project and I'm going to make the version I want to play, and people have always encouraged me to do so! The NES version is still there, and my version doesn't seek to replace it. But, if you liked that, I hope you will also enjoy this.

What do you mean color depth? What kind of art changes?
The original NES could handle a very, very limited palette. Not only was a sprite limited to 4 colors, the scene itself could only use so many. To start, I'm using 51 of the original 52 colors of the NES palette, 4 new colors, 2 yellow and 2 brown, and a modified shade of blue. Instead of four colors, each sprite has a palette of 8 colors + transparent, and obviously as many of the colors as I want can be on screen. This is a considerable leap over the NES could handle and gives me the ability to really make the sprites pop. Still, going overboard would diminish the appeal of the original graphics, so my goal here isn't to 'modernize' the art, just to add detail and reduce noise while keeping the same aesthetic. When editing I try to use the original source art as much as possible as well. Most of the original sprites are amazingly faithful to the artwork by Yoshitaka Amano and I prefer them far more than the later remakes. Still, I'll be doing touch-ups as I see fit. For example, Kraken has an mess of tentacles that are not part of the original design and are just visually noisy as they don't seem to come from or go anywhere. While I love this sprite, I ended up doing quite a bit more work than I originally intended. Others have far less dramatic changes, such as Kary who I cleaned up the face but largely left unchanged. In both examples you can see the enhanced color depth in play, though this aspect will be something you can turn on or off.

When will it be done? When can I play?
Right now! Dust off your NES! As for my version, development has resumed and enough testing has been done to consider it finally playable! I'm a bit hesitant to put it out there as this is just a chunk of content and I have no timelines or promises for anything further down the line. That said, depending on skill there is around one to two hours of content available. There are still some aspects of the game that aren't fully developed yet. For example, shops will show you what the attributes on gear is, but you can't see that information in the inventory. It wasn't quite so big of an issue when it was a 1:1 remake because that information is readily available online, but now it's probably a bit confusing to jump in if you aren't familiar with the source material. Check the tips section below if you don't want to go in blind.
Download (Windows) 7.91mb



Version History

Code:
25 April 2020 - Release Build 1
01 October 2019 - Development resumed, pre-alpha
Tips And Hints
A lot of what was true about the game still is. This did start as a strict remake and despite all the new content I've started to add, I still have tried to not change things just for the sake of changing them. I like the original balance of the game, and I just want to flesh it out. That said, here are some starting tips for new players:
  • You start out with Travel Clothes and Wooden Staves, while these are good enough for bashing Imps, you'll need to gear up before heading to the Temple of Fiends.​
  • The Temple of Fiends is meant to be done in two parts, rescuing the princess and fighting Garland. Some players may find they are able to do both depending on preparation and party, but returning the princess to the castle brings with it a nice windfall of extra resources.​
  • CURE is a vital spell for a White Mage or Red Mage, whereas Sleep or Fire are good choices for your Black Mage/Red Mage to start. The Black Mage has the worst physical attack in the game, but his spells can be devastating on the right target.​
  • Gold is fairly tight right now, and exploration is dangerous but rewarded.​
  • Don't be afraid to run from a fight, but not all fights can be run from.​
  • Reaching Level 2 is the most important level milestone in the game.​
 
Last edited:

Hyomoto

Member
So, I had most of today off and I used it to put up this thread but the first video I posted was a little old and I've made some progress since then. My recent focus has been the battle logic, since that's by and large the biggest part of what Final Fantasy is. For the most part the code that handles moving around is done, and I've even blocked out the entire world already so you could theoretically travel the entirety of it even if there isn't much to it right now. In fact, a lot of the game 'exists', it just lacks code to use it. For example, the qualities needed to make the airship work are already in, there just isn't any airship for you to use. That said, up until today I'd been doing a bunch of gears work, just getting the pieces to play together nicely and be able to handle events. But I sat down and wrote most of the code that handles magic today and put together the interface so you can now choose actions for your characters, including the aforementioned magic spells. I also put in a fix for a long-standing complaint about the original game: the dreaded 'ineffective' attack. In this case, the game will select a new target randomly if the one you selected is dead when your turn comes around.
The major features you can see are the addition of magic spells, and the interface to use them. At this point I have 100% of all the spells programmed in, however some of the opcodes that handle their function currently do nothing. Specifically only hp down and hp up are working right now but it's largely because HP is actually the most complicated routine. Additionally, the hit effects now use the same palette that your weapon uses. Previously only the weapons were colored by this effect. Now for some nerdy stuff that I just want to throw in here:

This next part is just for people who might want to learn something.

You might wonder how the battle routine actually works. Timing and event handling are complicated tasks, at least compared to making an object move around with the touch of a button. You need some method to control what things are doing are doing and when. In this case, the battle is a turn-based affair where the player can select actions that will then be carried out and there needs to be some enemy AI. I've opted for a scene controller that handles 'flow' logic (ie: the order in which the battle takes place), and individual actions by the battlers themselves which control the movement, sound and attacks. The only difference between the enemies and your party, code-wise, is that you choose the actions for your party. From a scene perspective, when a battler's turn comes up, the action it was assigned is converted into two sets of opcodes, one is used by the scene to determine the outcome of an action, basically it tells the scene what rules to use for that round, and the other one is sent to the battler itself. This is where things get interesting. Each battler has an action queue assigned to them, and generally speaking, the scene simply waits for the current battler's queue to empty out before continuing on. That means a battler's turn essentially lasts as long as the action queue for the current battler lasts. A battler's queue consists of seven opcodes that determine what will happen:
Code:
01 - EFFECT
02 - ACTION
03 - ANIMATE
04 - WAIT
05 - SCREEN
06 - HIDE
07 - SOUND
For example, when the player battler walks forwards for a standard attack, the action queue looks like this:
Code:
[ $0524213, $A172, $214 ]
The list is parsed left to right, and opcodes are the last 4-bits of each number. The rest of them are values being passed with that opcode to make something happen. For example, if you look at example above you can see it decodes to 3 events, ANIMATE, ACTION, and WAIT. Let's look at how the ANIMATE opcode breaks out:
Code:
$0524213
3 - ANIMATE
1 - TARGET SELF
2 - NUMBER OF IMAGES
4 - FRAMES TO WAIT BETWEEN IMAGES
2 - NUMBER OF TIMES TO LOOP
5 - FIRST FRAME ( #5 is walking image)
0 - SECOND FRAME ( #0 is standing idle )
The simplest explanation is the battler will alternate between frame 5 and 0 two times, pausing for 4 steps each frame, and stopping at 0. This is important because this is what makes the battler actually do things, and depending on what happens (such as a missed attack or perhaps a target dies) the action queue will have additional opcodes added to it. For more complicated chains of animations, you simply string them together for as many actions as you need performed. For example, this only animates the battler. We still need it to walk forwards, which is handled by the ACTION opcode:
Code:
$A172
2 - ACTION
7 - MOVE
1 - FORWARDS
A - 10
The ACTION opcode causes something to happen, generally affecting the battler in some permanent way, in this case it causes the battler to move forwards 10 pixels. The thing is, each battler will attempt to complete as many actions each step as possible until it's queue is empty. This is how you can have things happen simultaneously despite having to pass multiple opcodes. The issue is that the queue would finish before the animation and action had completed! The most obvious effect is battle would happen very quickly, and animations would overwrite each other. There needs to be a way to tell the actor to wait on something to finish. So, to ensure everything happens in the right order there is a very important and obvious opcode, WAIT. Again decoding above:
Code:
$214
4 - WAIT
1 - TARGET SELF
2 - ANIMATION FINISH
Pretty simple to understand, $214 tells the battler to wait until it's animation finishes before it continues with it's queue. Battlers don't just perform their own actions though, often you need another battler to do something, such as flash or take damage, and in that case you need to wait for IT to complete an action before continuing. That case we simply change it to TARGET OTHER. Most opcodes use bits 5-8 to specify what to wait on, targets are SELF, OTHER and SCREEN. Since scene processing only waits on the current actor, not it's target, waiting for the target to do something is the simplest way to ensure all processing finishes before continuing. A simple breakdown of a combat sequence is a battler chooses the next target from it's target queue (only one if it's a single target, but some spells affect multiple) and performs it's action. If there are no more targets, it moves on to the next battler in queue and repeats the same process for it, and finally when no more battlers are left the round finishes and the scene checks for victory and loss conditions. It's a very powerful system but it's simplicity can also be a source of errors, it is fairly mess up a sequence and these errors can be visual, logical or in extreme cases, soft-lock the game. I could put in some safeguards against certain combinations but I generally avoid that because they will also hide errors instead of forcing me to address them. Sometimes that simply isn't possible though, because I found one place where it is unavoidable. When an action queue cannot finish, anything waiting on this queue will wait forever, that includes the scene. Hence, a soft lock. The game is response, it will just never continue. For example, you never want a battler to wait to finish it's own queue, ie: include the BATTLER_WAIT_QUEUE flag on a WAIT opcode, because it will wait to finish waiting. It should only ever be used on a TARGET OTHER opcode. Simple right? Well, while implementing magic I came across a situation in which it is unavoidable: when you cast a spell on yourself you are the actor AND the target. Since the caster has to wait for the target queue to finish, the game soft locks. To prevent the error, the battler will masks out the BATTLER_WAIT_QUEUE flag from the WAIT opcode if it is both the actor and the target.

Anyways, I'm mostly just talking to myself at this point so I'll end my post here.
 
Last edited:

Hyomoto

Member
Just a small update today, since things like this aren't particularly interesting to show off anyways. I've fixed a couple bugs, worked on a few graphics, and finally coded a proper input controller in (I'll talk about this at some point) and as I mentioned before, a lot of what's left to do is the interface work. The data for the player, enemies and world is mostly complete, believe it or not, after all there are dozens of FAQs and wikis available with this information. The problem is the player has no way to interact with it! So while I can spawn any enemy, I still have to make all the encounter groups and assign them to the map regions. The game has all forty weapons in it as well, but the equip screen and stores to buy them don't exist yet, so unless I hard code it into the player's inventory, well: the game part is missing. So, I've been trying to fix that by getting those elements up and working. I didn't have a lot of time to put into this tonight, so there's not much to show off.

I'll keep this update a bit shorter since that isn't exactly mind blowing stuff right there but I figured I'd talk just a bit about scene rendering. You see, in the past I'd usually have handled all the drawing myself because I've generally considered GM's render pipeline to be ... cumbersome at best. However, a few months ago I was watching @Mike's video on JetPac. In it he uses tiles and layers to essentially recreate the way the color on the ZX Spectrum worked and this really got me thinking about how I used the render. See, I was always trying to cram everything into a single draw cycle. I figured the more control over it I had, the better the end result, or at least the more accurate it would be. However, what Mike was doing was using layers to change how things were drawn. Basically, he was using them as a form of scene control. By deciding what layers things should be drawn on, he had amazing control over the final image! Seriously, if you don't read the YoYo Tech Blogs and follow the developers, you are missing out on some really cool stuff.​

So, when I started out I wanted to do something I never do: use the room editor. Typically I write my own scene loading and map editors. However, GM2 has a much improved room editor and as I said, after watching Mike work with it, I wanted to give it a try myself. Each game map is a room, can contain as many layers as needed. However, there are a required 'system' layers that handle special rendering which I'll cover in a moment. The use of layers allows me to do quite a few things very easily. For example, the NES doesn't use overlapping tiles. I don't have that restriction, so I can do some things that weren't possible on the NES version, such as going behind buildings or fences for example. Or to add more detail to the maps.
Going behind buildings, for example, is easily accomplished. The roof of the house is on a layer higher than the player so they are drawn behind it. However, the fence works a bit differently: the player can walk both behind AND in front of a fence, it's important that it be sorted and drawn correctly. This cannot be handled easily using tiles, and so the fence is actually not a tile at all, it's an actor like the player, albeit a very basic one. All actors share this property and need to be sorted and drawn according to their depth, and this task is handled by the depth render. As many people are aware, GM2 did away with the old method of depth sorting. In order to handle this, the depth render culls anything on it's layer that cannot or should not be drawn, then sorts everything else and then draws them to the scene. For example, the original Final Fantasy had an effect where you can enter rooms and the things inside appear, and the things outside disappear. To achieve this effect, much like the original game, the depth render simply ignores anything that shouldn't be visible from inside the room.

In fact, objects don't draw themselves at all. The game utilizes three renders working together to build the image you see on screen: the composite_render, depth_render, and system_render all work together to composite what shows up on the display. I already talked about the depth_render, and for simplicity's sake, once the scene has been rendered to the application_surface, it is passed through the palette shader and drawn to a composite surface. There are several reasons for this. For those who are familiar with this game, or even RPG's in general, there are two particular effects that rooms in GM do not handle natively. The first is map wrap around, the effect were you can seamlessly travel from east to west and north to south, and the other is automatic filling of tiles beyond a room. For the first effect, I could probably just add a buffer of water to the edges of the map and move the player before the reach the end. Since they couldn't see any tiles except water at the transition, they'd never notice. Hell, that's probably how the original game did it! Still, I am too lazy and compulsive for solutions like that. Instead this is a function of compositing the screen: the map is patched together on the composite surface before being passed to the palette shader. The other issue is solved similarly, while I could extend the edge of the maps you could never see the edge of the room, I am still too lazy and compulsive to use that. Instead, for rooms where the tiles extend infinitely past the map itself, the composite surface is simply filled with offset tiles before the map is drawn to it. Yes, I've gotten out of work by doing even more work. I'm one of those types of people.

However, rendering is not done yet! The system_render is one of two final passes, and it works basically like the GUI layer. I've never been able to warm to the GUI in GM and considering how much control I've already given up, well some habits die hard. The system render works very much like the depth_render with two exceptions: all elements are sorted (as I said, the depth_render performs culling) and secondly, sorting does not happen each frame since system elements do not typically change depth. This means that you can add things to the screen and have them not be drawn until the system_render is told to update the scene. This is helpful because sometimes things need to be created that shouldn't be visible at creation. While it is possible to simply have them be hidden, this reduces overhead quite a bit and is made use of pretty extensively to make sure things do not appear until the player should see them.

The other advantage of the system_render is things are always drawn with absolute coordinates instead of relative ones. For example, if I were to draw a dialogue box to the application surface directly, it would need to be drawn relative to where the player is on the map. This would be annoying on the best of days, but it won't work anyways because if the player is at the edge of the map, it would be 'cut off' since there is no surface to draw it to. In fact, because the application surface uses transparency to properly composite the map, it will also cause visual artifacts if it is drawn over any transparent areas! There are other solutions, but the one I use is to simply wait until the scene is composited and then draw it directly to the final image. Believe it or not, this flexibility in rendering actually makes a lot of rendering tasks much simpler.

Anyways, my post as gotten a bit out of control again so I'm going to cut it off here. Until next time!
 
Last edited:

Hyomoto

Member
Another small update, since interface work is boring. I could explain how the interface works, but it's just not terribly complex or awesome. However, as I lamented before, it is what allows the player to interact with the world. It's a bit humorous to see how much the game expands as I add them though, I can finally interact with all these bits of data while game is running. Previously, to test a weapon for example, I had to hard code it into the party member's inventory. So yeah, it's nice to see it working so well. Most of the party menu has been coded in now and you can finally equip and unequip items. Something that has been a particular pain throughout this whole thing is ensuring that the party can have a variable number of members. The original game didn't support this, and in some ways I wish I'd just ignored it too. It's been a wellspring of annoyances to be polite about it. The thing is, as I mentioned before I want to recreate the game faithfully, but I'd also like to have some room to grow it once that's done. So, coding in things I'm not using right now but hope to later is important to ensure I'm not rewriting large blocks of code later on. Anyways, ever see a menu before? Well here's mine.
Since I'm working from a development standpoint I never bothered putting in a menu or title screen. So now, there is kind of one. The screen itself isn't so important as it represents the hole in the scene logic that the menu will go in when I do get around to it. I also got the weapon, item and magic icons working, and hooked on the 'outside of combat/only in combat' flags for spell usage. That's what causes them to be grayed out in the magic screen. Most of what I spent today doing was actually a lot of unexpected bug fixing. The program itself is very simple in a lot of ways, which makes it sensitive sometimes. I hooked up the new idle handling code, it's a script that sets the proper idle action for an actor to display, ie: after they attack or get hit. Should be a simple task right? See for yourself:
I'm a bit ashamed to know how long it actually took for me to fix this. It's one of those very, very obvious mistakes once you figure it out, but until then it literally looks like your program is defying the rules you gave it. To be honest, I'm still not entirely sure why this is the result, I'd figure it would have caused the animations to just go wild. Still, there are two important clues to what is happening. The first one is that the weapon and pose do not match. That's the battler_gfx_ready_1 pose. The attack pose is battler_gfx_idle | battler_gfx_weapon_01. So clearly this isn't a frame I constructed, that can be verified just by looking at frame data. The idle pose you are looking at is 0289, hex $121. That means there is one frame, 0, in the animation that lasts for 2 frames and loops once. Clearly not a match for what is being displayed. This is basically how you change an actors image when you don't need to animate it. From a technical perspective, it sets the frame, counts up to 2 and then clears itself. Since the animation no longer updates, the battler remains in that state until a new animation is set. That makes this a bit of a phantom frame. The battler shouldn't be animating, and even if it was stuck, it should only be displaying a single frame! Wait a minute, why IS it looping? Again 289 does not loop, it hits 0 and then clears. It was at this moment I realized the issue. The animation sequence counts up. When it hits the total number of frames in the animation it loops or ends. As I've said previously, I don't like to code safeguards in because they tend to hide errors. In this case it highlighted a very important, and very stupid mistake. The frame you are seeing is junk data caused by the frame counter. The loop is supposed to end, there's no more animation data. But what if the frame counter just keeps counting? Well, I guess I have my answer now. Checking my ANIMATE opcode, sure enough, there it was. When the animation $FFF1 is passed, it substitutes it for the proper idle animation but while the animation was being set, the frame counter wasn't being reset. As to why this never happened before: I never used $FFF1 to transition from an animation with 2 frames to an animation with 1. In the former case it would have cut the animation short by 1 loop and that would have been very noticeable, but since the idles are all infinite loops, the error went unnoticed until now.

Along with that I updated how the program gets and sets resolution, sort of a preemptive bit of work for aspect ratio support. I updated how some of the text is displayed to the screen, changed some names to better reflect the original game, etc... put together that sweet bit of title artwork. Added the proper music track to the status menu, and also cleaned up the code base a little bit and fix some errant naming inconsistencies. I also put a bit of work into how battle timing and execution works, such as ensuring windows that pop up when you attack look correct, which is related to why I came across this bug. It's always kind of hard to tell just how far along you are since some tasks, like the bug above, take unexpected amounts of time but things are coming along nicely. The pieces still missing are shops, the item menu, item and drink menus in combat, eight spell effects and I can start moving into working on content more extensively. Or to put it another way, it will actually be playable as a game. Exciting! For me anyways, your mileage may vary.
 
Last edited:
I've enjoyed reading your progress so far. It reminds me of the FF1 engine remake I was doing in GM8 that was going to be fully mod supported. Of course, I didn't get nearly this far, as I had to come up with a whole slew of mechanics to make the engine mod capable, the most complex being a parsed scripting engine. Keep up the good work!
 

Hyomoto

Member
Hooray for progress! I have three things to actually show today, and one thing to ramble on about! If you read my update from a day or two ago I lamented including the ability to have a variable sized party. The reasons for this are many, but the short version is I went back and completely overhauled the party system. Now the game supports both an unlimited number of party members, well memory allowing of course, and varying party sizes. Of course, this code isn't actually going to be used in the version I'm working on, the original game always had a party of four, but all the bugs and inconsistencies caused by it are gone. To be fair, the original system wasn't really meant to be used. It was one of those things where it's like, I need data now but I don't feel like setting up a proper system that then grows and grows and grows until finally it's completely unsuitable for the task at hand. The short version is the party used to be stored as very, very ugly data. And because I was working on various parts of the game, a lot of things started to access and rely on that data. This is bad because not only was it was ugly, but it was slow. Now every character exists as their own neat little bundle of data. By simply moving a single variable or changing the size of the array, everything else will adapt. Additionally, all data is handled through proxies, so if I have to change or add something, only the proxy needs to be adjusted. To be fair, it worked this way to some degree already and that made this change far easier than it could have been, but as I said, everything that needed data was interacting with it directly and I had to remove every direct reference. This extends to weapons, armor, items and spells as well, the former three combined into a single data structure. Simply put, everything is just how I prefer it: orderly and easy to access. I might still change it later on as the current format I'm not entire sold on, but as I said, everything uses indirect references now so if I do it will require far less work.

So. You can't see that, if I'd released the game in that state you'd have never known the difference, so what can you see? Well, I updated the logo at the top of the page to look a bit better and you may notice I also added the four orbs below it. In the Japanese version you were restoring light to the crystals, but I didn't know that. So before I found out about Western localization differences, I always wondered why they were never used again. To me, the orbs represent something special that I wouldn't dare swap out. That being the case, I really want them to be bad ass and I spent a bit of time putting together their new sprites and setting palette data. I dare say, they look freaking awesome. Right now, you can only see the four unlit orbs because while I had intended to post them in this update as a sort of 'hey, check out the art' part, the orbs deserve something better. Instead, pay attention to them. Like the heroes of light whose progress could be charted by their shining orbs, I too will chart the progress of this project with them. As things near completion, they may just begin to glow anew.

Enough words! Moving pictures!

Clearly the imps do not like the wolf palette very much.
It's been very much my goal from the beginning to reproduce the game as closely as possible, and this includes how the NES actually displayed colors. Of course, GM2 doesn't handle this natively and the way it works here is shader-based, but the spirit is the same. There are two very good reasons for this. First, it makes palette swapping much easier which is how a lot of effects such as blinks and flashes are handled, and second it is how I'm handling the color depth option without doubling the art space. The sprites are all stored in a very limited palette of colors until they are run through the palette shader to produce the image on screen. While this is great from a coding perspective, it does make it a hard to visualize what something looks like, or even show artwork off since I have to re-color it by hand, then decolor it again. So, I went ahead and built a graphics viewer that can display a range of sprites and palettes to show what they'll look like while the game is running. In the above example we have the same range of sprites, but the left one is using the wolf palette, and the right one is using the imp palette. The wolf palette is unfinished and lacks the status frames which is why there appears to be three missing columns with the imp palette.

Fancy on-the-fly color depth switching!
As I said, this also assists with color depth. While most people are probably familiar with the NES version of the game, what people outside of Japan are likely less familiar with is the MSX port. In many ways the port is undesirable. While it did fix many of the NES' bugs, it came at the cost of smooth scrolling when moving around the map, long load times when entering towns and battles and though the music has more character, it doesn't sound better to my ears. Yes it has the original artwork and gameplay, but it's an imperfect alternative. One important place it differed, for both better and worse, is it could handle far more colors. While the color choices were definitely questionable depending on your preference, the sprites are generally very attractive and I like it. As I've said before, you can choose to play with the original palette or an enhanced color one. The very simplest way of looking at it is that the original palettes contain just 3 colors per sprite whereas the enhanced palette supports up to eight. I love the way the original game looks, I enjoy the chunky art style, and it's my favorite among even the two Famicon sequels. The various later ports appeal to me less because the artwork has generally gotten worse, see Square's mobile offerings, and so I want to keep the original style I love, but I also want to give it a bit of a face lift. As I said in my original post, I will be making edits as I see fit but generally speaking if you choose the authentic option, the game should look damn close to what you'd get if you popped the game into your NES.

A menu! It does stuff! Truly bleeding edge accomplishments.
And last but not least, the menu is now complete. All of the functions of the original game are here, and I've added a lovely convenience feature that wasn't! In the original, pressing select allowed you to reorder your party in the slowest, most painful way possible. Not only did it take a while, it also played possibly the most annoying sound effect ever chosen for a thing. For my version, you can simply press right on the d-pad to move to the character cards and reorder them as you see fit. You can also see the menu supports less than a full party, though this feature won't be used for the final game. Still, a nice addition made much easier by all the party code refactoring and it supports my future plans should I pursue them. Something I didn't show off is I also finished the battle windows that pop up when you do things and corrected timing on a lot of actions, so now the damage floater that popped up in the original video has gone the way of the dodo. I need to post a battle update some time. I didn't put together a gif for this, you'll just have to trust me. Anyways, that's the end of this update.
@stainedofmind - Honestly these posts are more for me to collect my thoughts and it's a fun way to sort of track the progress of the project over time. If you enjoy reading it, I'll just consider that a bonus. I did consider modding support and such but I have a bad habit, or at least a strong history, of overengineering the hell out of my projects. My project folders are stuffed to overflowing with engine prototypes and various 'solutions'. This project is a large departure from that way of doing things for me, I almost have to laugh with how simple it really is compared to what I'd normally do. At the same time though, it's nice to actually make quantifiable progress forwards. That said, modding support would be possible here too but the reason it isn't is because I didn't want to write a parser. Pretty much all the code is just hard jammed into a startup script. It's definitely not my normal style, and to be fair if I write a parser later on I can have it just spit out all the data that's already in the game :D

@lolslayer - If you could tell it's a remake of Final Fantasy on the NES then you've probably read plenty. ;)
 
Last edited:

Hyomoto

Member
Just a short little update today and no pictures for a fairly good reason. As anyone who watched the live stream is aware, I was working on the combat windows and put together the rest of the spell effects. Need to test those out still but the code is there and should be working. As for the windows, well, that's turning into a nice little heap of work. After I got all the battle window animations working, I had to go back and work on the menus and the thing is, like much of the combat code, I had a different paradigm in mind when I started. I had a basic idea of what I needed to do to get it up and running, and at the time it seemed like a good idea. But as I've talked about in the previous updates, timing is a bit of a pain. Making sure things happen in the right order and when they are supposed to is it's own can of worms. The old way the window code worked was just a chore to use, it made specific timings very, very annoying and bloated actor command queues which is definitely not needed. On top of that it was a bit of a hack anyways since I hadn't built the battlers with that function in mind, it was just available for it. That's why I went ahead and ripped out that out and put in a more robust and dedicated system. Now you can control the windows independent of the actors and they have their own considerations, most importantly they now have a simple and universal access to the 'respond rate' feature, meaning menu timings can be adjusted. See the original game if you want to know more. The short of it is the battle windows were very terribly implemented and now they have a much better system. Additionally, timing used to be per phase in battle, but now it's global. From a player perspective, yawn, but from a development perspective it means everything works in a more consistent and controllable way. In lieu of screenshots, here is some code:
Code:
// #====================================================================#
// #    WINDOW QUEUE                                                    #
// #--------------------------------------------------------------------#
// #    The window queue handles window event processing, specifically    #
// # the opening, closing and text changes.    The events are passed as    #  
// # 1D arrays:                                                            #
// # [ window_id, wait, actions, text ]                                    #
// #                                                                    #
// #    Events are performed open=>text change=>wait=>close                #
// #====================================================================#
if !is_undefined( window_queue ) {
    // [ window_id, wait, actions, text ]
    while ( window_queue_id < array_length_1d( window_queue ) ) {
        var _action = window_queue[ window_queue_id ];
        var _id        = _action[ 0 ];
      
        if _action[ 2 ] & battle_window_open {
            _id.travel = 1;
          
            if _id.open[ 0 ] == 1 {
                if _action[ 3 ] != undefined { _id.text = _action[ 3 ] }
                if _action[ 2 ] & battle_window_active {
                    _action[ 2 ] ^= battle_window_active;
                    _id.active = true;
                  
                }
                _action[ 2 ] ^= battle_window_open;
              
            }
          
        } else if _action[ 1 ] > 0 { _action[ 1 ] -= 1 }
        else if _action[ 2 ] & battle_window_close {
            _id.travel = -1;
          
            if _id.open[ 0 ] == 0 {
                _action[ 2 ] |= battle_window_pass;
                _action[ 2 ] ^= battle_window_close;
              
            }
          
        }
        if _action[ 2 ] & battle_window_pass { window_queue_id++; continue }
        else {
            window_queue[ window_queue_id ] = _action;
              
            if _action[ 1 ] == 0 && _action[ 2 ]== 0 { window_queue_id++ }
          
        }
        break;
      
    }
    if window_queue_id == array_length_1d( window_queue ) {
        window_queue    = undefined;
        window_queue_id    = 0;
      
    }
  
}
In a lot of ways, the window queue works very similarly to the actor queues, but in a lot of ways it works exactly opposite. Basically each queue will attempt to open the window, wait for some period of time, and then close the window. Omitting any of these actions will simply skip that step. Where the actor queue tries to perform as many actions as possible, generally the window queue does not. There are some specialty actions in there, battle_window_active and battle_window_pass which activate a window (used for command windows) and to allow multiple windows actions simultaneously but the window queue is much simpler than the actor queues. Once I have all the menus up and working again, I have to implement item and drink usage and battles will actually be done! That's a pretty exciting prospect, they've definitely been the largest amount of work so far and probably not for the reasons you'd guess (unless you read all my posts I suppose).
 
Last edited:

Hyomoto

Member
Yikes, so today was a bit of a grueling day. I've long known the battle code was a little ... unwieldy, or at least just very ugly. While it was serviceable, I figured I'd eventually have to rewrite it for any number of reasons. Mostly because it was a sort of a patchwork that evolved in equal parts necessity and experimentation. I have a decent amount of experience when it comes to UI work, I spent about three years just doing that, so that part of the interface was pretty easy to write. As I mentioned in my previous posts, I put off a lot of UI work until later because I just didn't want to and so when I got around to it I just put in a hacked together solution. Once I got around to doing a proper menu system for the party, I began to really loathe to poor job I did with the battle system. Simply put, it was too complicated, it just had too many moving pieces and so it was also very finicky. In the last post I talked about building a window manager that handles the windows. Well, today I ripped out the entirety of the battle logic and re-implemented it. The most basic change was I tore out almost all processing from the actors and pushed that into the scene manager where it belonged. The biggest problem I had with the previous system is I was constantly searching for where something was happening. It was like a relay race of objects passing scene control around and it was just a nightmare. Some of this is because when I started I was trying to identically implement certain aspects of the FF game for no benefit. For example, the original game iterates over all actors whether they exist or not, so I had done the same thing. A minor, but useful, change I made was to ditch that and use the scr_get_targets script to produce a list of everyone who is current alive. This is nice because it can already be tailored to search for players, enemies or both and that means implementing surprise and preemptive attacks required no extra effort. It also returns a list of ids for battlers whereas the old system had to translate battler positions into ids.

The actors are all quite happy their events fire properly now!​
So much like the window manager, there is now proper scene control and while it looks nearly identical to what came before, I didn't rewrite everything since a lot of the old code just needed moving and adapting, it has all been greatly streamlined. For example, animations used to be hard coded into the various events that happen, but now they are taken from the battler's animations. This means I could theoretically set up custom animations for enemies and characters, but for now it just means far less ( IF ENEMY DO THIS, IF ALLY DO THIS) logic chains. Essentially, the two work identically now with the obvious exception you get to choose what the party does. I did have to give up a tiny bit of flexibility because of this but what I get back in manageability is well worth some minor workarounds. Previously it was very easy to pass commands to all battlers at the same time, but now scope is limited to the current actor and target. This means for things like the start of battle and the victory animation I have to force animate them. However, this does fix a constant source of soft-lock potential since a battler can no longer wait on itself. Internal consistency! Yay!

The sheer size of this undertaking is exhausting and it's technically not even done. I put together most of the scene flow again, and hopefully the edge cases have been weeded out though I suspect I'll be enjoying the odd bug for a while yet. Still, 75% of what I had before I started is replaced and working again and in the end it was worth it to just get it done. Unfortunately this definitely pushed me back quite a bit further than I'd like, so if you are hoping to play it you'll definitely be waiting a bit longer than I wanted. I'd hate to do two updates with anything to show but honestly there's just not much to show. If you are interested here are the last two live coding sessions I did. I really look forwards to doing some of these once I get this engine work finalized and I can dive into content production.
 
Last edited:

Hyomoto

Member
Trying something new, here's a video update.​

So yeah, super productive two days and got a lot of big tasks out of the way and now it's time to work on some of the fun stuff! Today's live stream saw the completion of the magic shops, the item screen and out-of-battle item usage. On the back end I fixed some old and long-standing bugs dealing with how actors are rendered to the screen. The really big feature however is that the palette shader has been extended to even more parts of the game and even more parts make use of the color depth system. As time has gone one I've started to standardize how the color depth works in terms of palettes, as when I first started it was more of a novelty and I wasn't sure how I wanted to implement it. So it's a little less unruly per-item and a bit more consistent now. The last major part of the game to hook up to this is the map, but not only does that require editing all of the map assets, the way it is currently rendered makes that a lot harder and it's a problem I'm not quite sure how I want to tackle.

As a whole I haven't gotten as far as I was hoping to, I guess I underestimated just how much work goes into an RPG, even if you know in advance everything you need. An RPG isn't really a game until all of it's systems are up and in place, when anything is missing it just feels unfinished. I don't mind updating as new content is finished, but missing vital systems? Even if I get the last bits that need doing in, the only character in the game is the Fighter, good ol' Dill an Bary. Literally the first test characters, and now sort of my official mascots. And let me assure you, adding the rest of the classes will be a pretty large task all by itself. Code-wise they are largely taken care of, but art wise I haven't even started. I might throw together an alpha demo that features the duo and you can try to defeat Garland with them but I don't know yet. Enough text, time for pictures!​

Maybe nobody cares. Maybe this is a feature only I care about. But I really like it.​
I had to go back and adjust both the yellow and brown palettes. The NES has a horrible selection when it comes to those two colors, and while there is still no native yellow (and the one I have is still the original shade) the lighter and darker shades have been adjusted to be create a better gradient. I hope they still feel authentic, but it gives me a little more artistic breathing room. The browns were cheater colors anyways, it's just that the ones I picked turned out to be pretty useless. As you can see in the Innkeeper's hair, the new ones aren't as warm as the originals, which means I may still go back and tweak them a bit. Something about the NES palette is that it is very pastel, and these washed out browns work look alright, but at the same time the NES has vivid colors and the browns are not. Perhaps it's just impossible to find one that fits both those criteria. If you want to suggest a shade, feel free.

At this point GM2 is telling me I've put 181 hours into the game, which is roughly 80 hours more than I originally though I'd need to be 'feature' complete. I'm willing to be at least 40 of those hours have been wasted on redoing artwork and code, but it goes to show that even if all my work was perfect game development is one of those things that just takes time. I put this part in just because if you happen to be reading it, hopefully it gives you some satisfaction knowing all things take time and if you keep at it that task list gets smaller and smaller. At this point I'm estimating there's probably at least another hundred hours to go but it's really satisfying getting to a place where all my work feels like forward momentum again. That's it for today's update. If you are interested, today's live stream is on my YouTube channel and you can watch it to your hearts content. Until next time!
 
Last edited:

NicoDT

Member
This is looking really good, good job!
Are you planning do add jobs other than the original six? I think it would be a good addition and a good way to pique people interest.
 

Hyomoto

Member
In some ways I disagree, there will be enough 'new' features in terms of QOL, tweaked graphics and the new color depth setting that should make it appealing in it's own way. The original has certain qualities to it that were stripped out in the consequent remakes and the more I work on it, the more I realize why this is still my favorite. While later entries would have a decidedly jRPG touch to them in theme and presentation, the original was largely based on western-inspired fantasy, especially Dungeons & Dragons. It was really a wRPG, and I still prefer the chunky graphics and the punishing difficulty. While a lot of ROM hacks have focused on bringing the graphics for later entries in, I don't see the appeal. Even 'fixing' the whole 'ineffective' attacks removes a layer of strategy that adds to the tension of each fight. All in all the original game is a highly satisfying adventure with a lot more depth than a game of it's age would suggest, even more so with the bugs fixed. I fully intend to pay proper homage to that legacy, it deserves it. In fact, maybe a bit too much since trying to faithfully recreate it has meant doing some things in some very odd ways that I'll later have to fix or change.

However, once all that has been done I do intend to build my own version of the game. I suspect when it's done it will be quite a different adventure than the original, serving more of a jumping off point than a strict interpretation. So if this version seems unappealing or lackluster, perhaps later incarnations will better whet your appetite and have some more of that widespread interest. Either way, thanks for the compliment and interest!
 

Hyomoto

Member
This is sort of a mini-update but I wanted to talk about a little feature that's been creeping in over time. To borrow from a conversation had during the 2016 AGDQ stream of Final Fantasy, some flaws in the game are debatable. It just isn't always clear what is intended or a bug sometimes. For example, the MUTE status also prevents characters from using the DRINK command. Is this a bug or a choice by the developers? The INT stat famously does nothing. Enemies always wake up on their next turn. Some statuses always miss. Some will be treated as bugs, but for the others I've decided to implement EASY MODE, CLASSIC MODE and HARD MODE. Really what it comes down to if it makes the game easier it will be part of EASY MODE, if it's a change that makes the game harder it's part of HARD mode. Classic will still be as faithful to the original outside of QOL stuff and obvious bugs, generally those fixed in the Wonderswan and MSX ports, and will be the project as I intended it. The other two are there to let me play with some ideas or deal with those changes that can affect project integrity.

A good example are INEFFECTIVE actions. Was it a limitation of the time? All future games would do away with it. I think it was intended and adds a lot to the combat experience. An ineffective attack represents the idea that all actions take place simultaneously each round over about 5 seconds. If two people attack the same enemy and it dies during the turn, one of those attacks might be wasted. They can't just change their minds mid-attack and choose someone else. But let's look at it practically: if you consider that the length of a battle is taxed directly to your health and other resources, you can show removing the this feature is actually a blow for player interaction. To minimize your own costs each battle, you have to optimize your actions for each round. The better you do, the shorter combat is, and the lower the 'battle tax' is. Ineffective attacks are a representation of where the player gambled and lost. It's a combination push-your-luck and game knowledge to ensure you pick the right targets and actions to maximize your output and minimize enemy input. Still, it is an infamous aspect of the original, and one later remakes did away with. Here, personal taste vs developer vision vs playability, I have decided to use this difficulty model. Choosing EASY will have the select new target behavior, while the other two modes use the original design. Code wise this is a small change, but in gameplay it has significant implications.

None of these changes will be 'MORE HP/LESS HP' types of edits, that much I can promise. Generally EASY will limit user mistakes, while hard will add some new considerations. The default mode for the game will be CLASSIC in case anyone is wondering. I'll discuss these changes more as a release becomes eminent, but this should be accomodating to those who want a simplified experience as well as cater to purists and sadists as well.

As for progress, I've gotten all shop functionality in, all menu functionality in (including use, drop, and trade), and now I'm finishing up battle items, drink and flee. Status effects are only partially implemented, sleep is permanent for example, and I still need to code the logic for TENT, CABIN, HOUSE and EXIT and WARP. I'm sure there's some other stuff I'm forgetting but still, the list is getting quite small. Once that stuff is done I'll be getting into content pretty much full-time and my goal will be to put out a demo featuring all the stuff I've talked about up until this point and move the project into BETA. I'm expecting to have up to Garland in the beta demo. That's a small chunk anyone familiar with the game will know, but even with all the tools and engine operating, content is more than just laying out some tiles. It's data entry, graphic editing, map building and event coding. Still, I'm aiming to have that available next week and my progress feels pretty solid. While you can't hold me to it, that's the goal.
 
Last edited:

Hyomoto

Member
Right, so instead of working on the project today I hit a large setback. For some reason the problem I've had for quite some time where my project, for no apparent reason, begins to run at a lower frame rate became permanent. Nothing I did seemed to fix it. I tried reinstalling GM2 and uninstalling Windows updates among the goofier options, but the result was the same. It was stuck at 32, though once in a while, and for seemingly no reason, the project would instead run at 44 FPS (48 is what it's supposed to be, for the record). And I couldn't convince it otherwise. Humorously if I increased room speed to like 62 it would get up to 48 but that's definitely not a solution. What it seems like is the project is still running at 48 fps, but processing at 32. Ugh, so infuriating and confusing and there's just nothing I could do to make it work right again.

So defeated I just took a break and watched Aliens. But this is one of those problems I just have to solve, I can't accept that my project is just arbitrarily broken and there's nothing I can do. So I tried some more things, I mean at one point I just ran the project with nothing more than the render object. It was like the project was cursed. But finally I tried something else, I had exported my project to upload as a bug report. I figured, it's permanent, maybe this will help Yoyo figure it out. But then I remembered, new projects weren't afflicted by this problem. So I tried importing my own .yyz file and wouldn't you know, 48 FPS again. Here's the thing. I haven't gotten around to testing it much or working on it more, so I have no idea if that was a fluke caused by the GM2 update or what but right now it feels like the project is in a bit of flux. Hopefully things go well and my next update will be about the changes I made to how magic is rendered, which was what I wanted this one to be about.
 
Last edited:

RangerX

Member
Try running the game without V-sync. (sucks though if its because of V-sync).
Else try to fiddle with the Sleep Margin (graphic tab in the global options)
Set it to 10 ---> see if your game always runs good
Else set it to 15
 

Hyomoto

Member
@RangerX - Had to put it to twenty, also logged a bug report. But it looks like I can start making progress again, thank you.
@Mi7 - You might be exactly the kind of fan for a project like this then, eh? I do not have a sealed copy, though I have considered, but if like me you've always found the various ports and remakes to be missing something, that's exactly who this project is aimed at! Very cool, I'm a bit envious.
 
Q

Quailfail

Guest
I've been silently watching this thread since the first post. It's been really inspirational as I'd love to do the same thing with Megami Tensei when I have better programing skills under my belt.

Are there any updates/changes you've been debating about implementing but are afraid that it would deviate too far or "lose the spirit" of the original?
 

Hyomoto

Member
@Quailfail - Pretty much all of them to be honest. There are quite a few changes I'd like to make to the script, interactions with the world and even timings that I want to tweak or change but I've decided for now I'm going as close as possible. In fact, I coded in a much easier way to use items, but I'm debating on whether or not to keep it since it is a huge deviation. I have total control over the engine, and I can pretty easily do whatever I want. In fact, that's why I chose this route rather than just doing a ROM hack. Still, even small changes could have a unexpected effect on the experience. While I am sort of doing that anyways graphically by updating sprites, adding some frames of animation and adding color depth, if I make any changes that deviates from the original in a significant way mechanically, I'm going to push to the easy and hard modes. I mean, my starting goal was to recreate Final Fantasy without the bugs for myself. It's best to error on the side of non-interference for now.

One feature I've toyed with and even coded in is to have the map change in response to defeating the fiends. The opening text crawl talks about a world covered in darkness, that the seas have gone wild, the winds have stopped and the earth is rotting. It's an important context to the story, and yet when you begin you are greeted with a pretty bright setting and fairly cheery music. I might still use it, but I haven't decided yet. Another example is that the Light Warriors all arrive holding an orb ... but from where? Corneria is one of the most inaccessible regions of the game! Until the bridge is built you cannot even reach Pravoka, so where the hell did they come from? It's honestly a pretty insignificant detail where they came from, but how they got to Corneria I think deserves an explanation. I've mentioned before once I'm done with this I'd like to make my own adaptation, so while this probably won't be addressed in this release, it is the type of stuff I'd like to get around to doing one day. It's pointless to talk about now but the goal is to make this, get it working very faithfully and fully playable, and then branch out to my own vision. I think it's best that way since working on it at this level gives you a pretty good appreciation for how and why certain things were done and hopefully a bit of insight where it can move and change without being instantly unrecognizable.

That said, here's where I act like a total hypocrite and show off a radical change! Here's a preview of Corneria with some added color depth!
I'll probably talk about this with a bit more depth at some point, but the way the render pipeline works is the scene is drawn in layers. Once of these layers is for actors such as NPCs, fences, bridges and other 'dynamic' tiles. Another layer is reserved for system elements like dialogue boxes and menus. There was a bit of a stop gap measure to get the palette hooked up to maps by having it run the composite scene through the palette shader. This was just to get it working as it meant if any actors had any system colors, it would cause them to be drawn incorrectly. Today I fixed that and added proper palette handling to the map. At this point almost everything is hooked up to the palette render and I've done quite a bit of work on the promised color depth setting. A nice side effect to getting this done is that I might finally be able to add an effect I wasn't sure if I'd be able to pull off: the screen transition between battles, shops and the menu. On the NES it works by cycling the palette and blanking out colors. I'm doubtful I'll be able to achieve the original effect since I can't quite pin down how it works, but I should be able to achieve something similar. For now, however, I needed a test scene and I figured it's as good of time as any to work on the town tileset and update it to make use of the color depth feature. I've talked about the MSX port in the past and as I said before, I'm using that as a guide in many cases. While I didn't care for a lot of it's color scheme, it did have a superior aesthetic in a lot of ways. It's the only port of the game that kept the original aesthetic intact, and in many ways is the closest port to what I'm trying to achieve here. Strangely the MSX port didn't apply the enhanced color depth to things like NPCs, which I will be doing. So yeah, if you've seen that and this seems familiar at all: that's why.
 
Last edited:
Q

Quailfail

Guest
I used to dismiss a lot of ideas I had for updating- that I would be diverting too far off and lose the spirit of the original. However, after the release of Yooka-Laylee I started changing my mind. People I knew getting exactly what they asked/wished for in this game only to realise that time + nostalgia had blocked out the more annoying parts of the mechanics/theme they were wanting. Compared to Shovel Knight that shared elements but deviates a lot from the time/limitations of the inspired era.

I am now looking forward to your personal adaptation! You bring up a lot of good ideas and thoughts to touch up not only bugs, but smoother mechanics and story bumps/holes. I understand why the opening feels out of place. It's the start of the game and there is no reference to what "good normal" is in the story yet so one can't really get that visual/audio dissonance. I'm also found of pointless details for so you mentioning adding explanations like how they got to Corneria in the first place has me very excited.
 

Hyomoto

Member
Partially thanks to the setback earlier in the week and for the reasons I already mentioned, I haven't had the time I would have liked to work on this. Which is basically the long way of saying I'm not sure when I'll be able to get a demo together. That said, I have still been making progress where I can and I'll share some of that with you now.

Battle is nearly, almost, largely, mostly done. Every time I turn around I realize there is something I forgot or something weird happens and I have to spend time figuring out what the heck. I have finally gotten most statuses up and running in the game. Poison and confusion are the two that don't currently do anything. You can become confused and poisoned, it just doesn't matter because there are no effects. I also need to code in the regeneration effect some enemies had and implement running still but progress is there. Still, you can receive and recover from in-battle status effects correctly. I spent some time writing up a new parent object for windows, two actually, that handle menu to standardize cursor control and window features in general. Since combat had the first menus I wrote, they were the ones most in need of updating. Everything except the magic menu has been updated to the much tidier code, it wasn't completely necessary but it does streamline game logic quite a bit. Item, drink and magic menus are now all fully functional and can be properly affected by statuses. For example, in the original game MUTE actually locked out the DRINK command as well as MAGIC. While I've debated 'fixing' this, I figure it is a good place to use those difficulties I've been prattling on about. If you play on CLASSIC or HARD, MUTE also affects the DRINK command, while EASY will only affect MAGIC. Speaking of which, here's a quick peek at magic, items and statuses in action!

Sorry for the low FPS, I should've used 33 instead of 15.​
I believe I mentioned that I rewrote how magic is displayed, and it's now hooked up to it's own palette. Each spell consists of six frames of animation, but while originally they were hard-coded to switch between frame and frame + 1, now custom animations can be assigned and shared among spells. I also took some time to rewrite how events are stored and accessed on the map. Since the very beginning, all events were stored in a list that was then used to sort them for display, but also used to search for them when the player is interacting with the world. For example, where you step on a square it would check your feet for an event. This was fine with a small number of events, but it really made me worry about some effects I wanted to accomplish. Primarily that any decorative events would eat up processing time. In towns this list is accessed by every NPC, and even though I think generally most computers are fine with handling it, I put together a different method altogether. Now, events are stored as a map. Their tile positions are put together to form a unique tile identifier and all events on that tile are stored in an array. So now when it's time to check for an event it simply calls for that tile ID in the map and is returned a list of events or undefined.

There's an added benefit to this as well. All events are still sorted and drawn by the depth render. If you have a map with, say, 200 touch events for leaving the map, much like the previous situation, the depth_render has to cull 200 entries every frame. The solution here is to make use of the new event system and cull any duplicate events at map load. Instead of checking the instance itself, it only checks the tile ID for events, which means I can store the same tile ID in multiple locations. So basically I can copy paste the same event all over the map, and this is something was not possible with the previous system. This means no matter how many duplicate events are used, when it comes time to cull and sort, only one entry needs to be managed. I'll be honest, this is one of many features that the game will never fully utilize, that is to say there are no 200 event rooms in the original game. Still, it definitely helps future proof and gives a lot of breathing room. On a similar note, events can now be given a flag_render_tile flag which allows them to be drawn from the tile pool rather than a sprite index, which will reduce duplication in the art department and that makes me happy. There are a few places this matters, but doors are the big one since now they'll share the proper palette with the map they are on. Oh, and speaking of that, here's an update on the graphics:

It looks even better in a larger window!​
Obviously work in progress and all that but I'm pretty happy with how it's turning out. I've spent quite a bit of effort making sure that the original color depth looks as close to the original as possible, minus a few minor edits that were possible even with the original tiles. I've also included a few of the 'uncensored' sprites now, chruches instead of clinics, but mostly because I just couldn't get a clinic icon that looked decent. See, the original tile has the wrong palette assigned to it, and so when I tried to correct this it just always looked wrong. So finally I just tried out the Japanese sprites and I was immediately happy with them. I think that's about all I've managed to get done. Honestly, the battle engine is still giving me some issues with timing. It's hard to see in the gif, but for some reason when attacking multiple targets, the first target is slightly faster than every other target. That's the end of this update. Until next time!
 
Last edited:

Hyomoto

Member
Another minor deviation today, and really one of the first QOL features I'll be showing off. The way the original game handled status effects was a bit lacking. Only one status effect could be shown at a time and status were only shown for the party. While it's true that having multiple afflictions was generally rare due to very few enemy groups having the ability to afflict multiple statuses, the second thing is a bit more serious. Specifically, in a large group of monsters, which one is asleep? If you are using this information to determine who to attack, if you hadn't memorized which monsters were afflicted by a status, you had no way of knowing. And since it isn't always obvious what monster is being activated, it's nearly impossible to keep up with which ones have or don't have a status once the round has passed. The monster activation is something I fixed a long time ago even though I never talk about it, basically the 'active' monster flashes when they act. Also, in the classic game, monsters couldn't be paralyzed and always woke up on the next turn anyways so the display was less important to begin with. While I'll discuss my solutions and implementation for those status effects later, what can and will be done regardless is the actual information needs to be clearer. Status icons were used in pretty much every other game in the series and for good reason, they work. So that's what I've done. I'll probably tweak them as time goes on, but for now they look good. If a actor has multiple statuses it will cycle through them as well, so you can easily keep track of who has what.

I'll still probably tweak them a bit, but still an improvement!​

I also finished up confusion today. The original game had an odd implementation. Not only was it impossible for the party to become confused, enemies were programmed to use FIRE on each other. I don't consider this a bug, but I do consider it to be a poor or at least lackluster implementation. My solution is a bit different, if a character is confused there is a certain chance they will act confused. If so, it selects a random target from all possible targets. This has a limitation that I debated for a while but decided to go with, which is that if you use a skill that affects multiple targets, confusion will reduce it to a single random target. First, this more closely mimics confusion in the original game. Second, it solves two major issues in terms of balance. The base game has no way for the party to become confused, so even though it is possible mechanically, there are no enemies that can confuse you. That means confusion is primarily a danger to enemies and since many enemies use AOE attacks, it would move confusion pretty high up the list in terms of effectiveness. While I'll probably play with the values based on feedback, this seems like a good compromise between the original implementation and the later games.

Speaking of which, there is another infamous aspect related to magic I've decided to tackle. The intelligence stat doesn't do anything. This creates a lot of balance issues. First, INT is a primary stat for magic-users and does nothing for them. Second, since this means the Red Mage is equally proficient with magic and can equip most weapons and armor, they greatly outclass dedicated mages. So while they are weaker Fighters, they are also near-equivalent Mages. This is compounded by Knights and Ninjas also being equally good Mages once they acquire magic. The only way to do anything about this is to implement INT but this isn't something that is bugged, it literally just didn't exist. So while I can look to later games for inspiration, there's nothing in the original that suggests what the developers may have intended to do with it. There have been a few discussions on the subject and generally boil down to either let INT buff effectivity ( a stat that determines the damage or healing ) or buff accuracy ( which doubles damage spells and affects to-hit for status effects ). I don't really like either option because they fail to address the problem with magic in general. Unlike melee classes who get stronger just for levelling up, there is no spell scaling and magic does not keep pace since it has static values. Additionally, spells are a limited use item so you have to rely on melee for majority damage anyways. The Red Mage is equivalent to the other two Mages in power with the added bonus of being a decent melee attacker. Adding insult to injury is items also have the same power as a mage! The thing is, magic should be bad ass and mages should excel at it. It's already a limited asset so there is no reason to make it weak and consequently steal the Mages primary strength. I'm going to go with a sort of hybrid system where INT will be used to determine effectivity and high INT will also provide bonuses. As an example, if a spell has a EFF of 20, it is clamped to the users INT stat. Then for every, say, 4 points over that number it will get an extra EFF. Something like that. This change would mean the mages would be superior casters whose spells leveled up with them, items would have static magic powers, and the Red Mage would remain a decent mage but not as powerful as his dedicated partners. This is just a general outline and still needs tweaking to get right, but that's what I'm aiming for. I'm also debating whether or not this will go into CLASSIC mode. HARD will definitely make use of it, while EASY will use the original method but I don't know if it belongs in the original experience. It's debatable whether or the lack of INT could be considered part of the original balance.
Code:
if !_skill {
    var _LVL    = magic_get_attr( _index, skill.level );
    var _INT    = party_get_attr( _actor.base, character.int ) * ( _LVL + 1 ) div 2;
    var _BFF    = max( 0, _INT - _EFF );
 
    _EFF    = min( ( _INT div 2 ) + irandom( _INT ), _EFF );
    _EFF    += _BFF div 4;
 
}
On paper this equates to a boost of about 15 at max level for a 1st level spell, and about 30 at max level on a 8th level spell. Considering that the damage equation is EFF + IRAND(EFF) before doubling and weakness are factored in, that equates to a boost of up around 45 damage for a 1st level spell and 60 for a 8th level spell. It also means a level 1 fighter casting magic could potentially have an effectivity of 0. A level 1 Red Mage does ~14 damage with Fire, while the Black Mage does ~32. So yeah, not insignificant and should help even low level magic remain relevant for casters. Of course, this is on paper. It might also make odd level spells unexpectedly more powerful. It'll be interesting to see how this model works in practice. Still need a solution for status affecting spells as well.

Progress has also been made on the other statuses, poison and regeneration. In the original, regeneration doesn't work at all. It has a routine, but it just isn't applied. It's hard to say whether or not this is a bug, but I've decided to fix it because it works in all later versions of the game. The original was 2 HP per turn, while later games would make use of 5%. I'll be using those numbers for EASY and CLASSIC respectfully, but for HARD I'm going to implement a weak and strong regen effect based on some enemy data. The numbers will have to be tested but I'm looking at 5% and 10% as a base and I'll tweak it as necessary. Poison on the other hand did work, and was a paltry 2 HP. For now, EASY and CLASSIC will use 2 HP and HARD will use 5%, though depending on feedback I might push the 5% or some other number to CLASSIC as well. It's one of those cases where I'm not sure how much to tamper with it. Poison just really doesn't matter later on, I believe most late game enemies largely stop using it, but 2 HP is what it was so it seems irresponsible to tweak it just because I think it's weak. The most dangerous poisonous area of the game is the Marsh cave, at which Fighters have around 100 or more HP so 5% is 5 HP, nearly double the base, so I think the numbers will need tweaking, maybe 3 or 4% but it'll need testing to get it right. I might try for a strong/weak poison implementation later on but I'm going to shelf that for the time being.

So ramble over. As I've said before, the task list is slowly dwindling down and I'm really, really, really hoping to get more into content here soon. It'll just depend on how much time I have available.

@Mi7 - I'd be glad for you to test it out and hopefully I'll have something soon. I'll PM you when it's ready.
 
Last edited:

Hyomoto

Member
Two status updates? What is this, Christmas? No, just looking for some feedback. According to the guides put together by AstralEsper, the formula for running in FF is Luck > IRAND( LEVEL + 15 ). This just comes off a bit weird. The Thief is the only character to keep pace with the Luck stat. He begins with 15 luck, which given the above formula gives him a 1/16 chance of not running. Because his luck keeps pace with his level, he can actually run nearly all the time. The other characters are a bit different, maintaining ~30% chance to run at level 1 and a ~50% chance at level 25.

So here's the thing: luck works properly and part of FF is definitely picking your battles. Knowing when to run is a very important mechanic for survival, so it gives a certain value to the Thief. Still, it just seems really high whereas the other characters seem about right. I guess doing the math I'm going to leave it as is for now but if anyone wants to chime in with their thoughts I'd be interested to hear them. Having a dedicated runner is definitely a skill, and even though it's a high number there are both battles you can't run from, and if the Thief is killed or stunned he can't run anyways. So it clearly has it's balance if you also consider he's far weaker than the Fighter as well.

The thing is, discussion on this topic generally agrees that even if the Thief's luck stat worked, it would still be better to take a fighter. This comes down to the classes themselves. The magic stuff should help the mages greatly, but in terms of base stats the fighter is off the freaking charts. I want to include an agility mechanic at some point which should help that A LOT, but for now I'm just wondering if anyone else has thoughts on the run percentages.
 
Last edited:

Hyomoto

Member
Small update, and another one where I moan a bit. The new GM2 patch dropped and while it fixed my sleep margin issue, it tanked my performance. The world map has always been a source of low FPS, and it's something I've intended to fix or address at some point. The reason is because the entirety of the map is drawn, even though you only see a small portion of it. This is important because the world map has to wrap around, and so in order to piece it together I have to render the edges of the map. This is obviously not possible now and I have two options, find another solution or roll back GM2 to the previous update. For now, it's the latter. I love that GM2 is evolving and hopefully becoming a better project but I'll admit I am a bit annoyed that for two updates now the performance of my project has changed in some significant way. Anyways, I have some other stuff I'm working on that like the last time this happened I'll be showing off later. I really only had enough time to test out the update today and vent a bit I guess.
 

CMAllen

Member
You should probably break the overworld into chunks which can be streamed in and out depending on proximity to the active view area. You and I both know there was no way the original game loaded and kept the entire overworld area in memory. The chunks, in turn, also mean that that wrapping around the edges becomes a simple matter. Food for thought (that I'd wager you've already considered). -edit- it also makes the underlying engine that much more robust and capable of more detailed and computationally intensive regions for future projects.
 

Hyomoto

Member
My current idea, and I love your thinking by the way, is probably going to be a render once solution. Right now it renders every step, but while other maps need this for technical reasons, the world map has unique qualities beyond just being large that should make this possible. Still, it is something I may try to find a more universal solution for in the future and that's where streaming could come in.
 

CMAllen

Member
My current idea, and I love your thinking by the way, is probably going to be a render once solution. Right now it renders every step, but while other maps need this for technical reasons, the world map has unique qualities beyond just being large that should make this possible. Still, it is something I may try to find a more universal solution for in the future and that's where streaming could come in.
If there's nothing being animated in the world map (or if it's just a few things here and there, they could be converted into simple objects), it's certainly possible to render out a sizable chunk of the world area to a surface that is sized so that the nearest dimension is always far enough away that the player can't reach it before a drawing update is performed on the surface. How large of a surface you'd use would depend on how quickly the player can move (at the absolute most) and how often you want to update the surface's capture of the world area.

Another option you could employ (if you aren't already) is checking the distance away from the active view area for any given draw call and ignore any draw calls that fall outside an acceptable margin. So check the abs x value against the viewport x, and then abs y value against the viewport y. If the results fall within the required range (based on viewport size and some padding), only then will anything be drawn. There's obviously no point in drawing anything that won't show up in the viewport.

These two solutions could even be used together with a little tweaking to further reduce the amount of drawing done.
 

Hyomoto

Member
So, not a lot of time over the last few days to do much but I have gotten a couple small things done. First up, I finally hooked controller support up. This wasn't actually that hard because the way I handle the controller in game is indirect. I've mentioned I don't like direct access of certain things because it leads to large problems or changes later on. In the case of the controller I don't access the keyboard directly, or even the object that accesses the keyboard, instead to check for a button press I use something like:
Code:
if button_A == key.pressed {  do stuff... }
This is to reduce a lot of code duplication and, in case something needs to change or be added, ensure it doesn't break everything that already relies on it. The easiest example I can give is actually with the mouse and the double-click. How should I handle it? Should I have each object that needs a double-click perform it's own processing? Maybe I could make it a script, that would be better, but it doesn't really solve my main problem. From an object perspective, I really only care about specific outputs. For example, the A button being pressed. So, my solution is a controller object that handles key presses, holds and repeats, button masking and simultaneous inputs. Key presses and holds should be self explanatory, but repeats are just when you hold down a button there is a period of time before the key begins to repeat. It's the exact same effect as holding down a button in a text editor. Button masking is largely used to emulate the controller when you are using a keyboard. For example, on a controller you usually cannot press left or right at the same time. Instead of hard-coding this into each object, the controller object just masks out the opposite input making it impossible to do. Finally, I can define both keyboard controller inputs to register for a particular button so if any of them are pressed the game sees the same thing. For example, button A is mapped to both button A on the controller and the enter key. If I press either, the controller handles it and the game just sees that button A is pressed. Truth be told this is just one of those objects I coded a while back and use a lot, no sense in reinventing the wheel, however I added some support for checking if the controller you were using is removed, seems important in hindsight, as well as when multiple controllers are detected it will wait for you to press start on the one you want to use instead of just assigning you the first it finds. Right now it's not possible to reassign keys and buttons, but it's not because the controller can't handle it, just because that requires an interface I haven't written and have no desire to do so right now. For the time being the game uses the d-pad, A, B, start, select. Get yourself an NES classic controller or even an NES to USB adapter for a very, very authentic experience. However, that stuff will come later. Anyways, if you are interested, here's what the code looks like:
Code:
var _hasController = controllerActive != undefined, _id = controllerActive;
var _debug    = keyboard_check( vk_control ) && keyboard_check( vk_shift );

if !is_undefined( controllersActive ) && _id == undefined {
    log( me(), " :: Checking for controller..." );
    for ( var _i = 0; _i < array_length_1d( controllersActive ); _i++ ) {
        if gamepad_button_check( controllersActive[ _i ], gp_start ) || array_length_1d( controllersActive ) == 1 {
            controllerActive    = controllersActive[ _i ];
          
            log( me(), " :: Controller found [", controllerActive,"]" );
            break;
          
        }
      
    }
  
}
for ( var _i = 0; _i < array_height_2d( uiActions ); _i++ ) {
    var _key = true, _button = true;
  
    if uiActions[ _i, key.mask ] != undefined && buttons[ uiActions[ _i, key.mask ], 0 ] != key.free { continue }
  
    if !keyboardRespond || uiActions[ _i, key.contKey ] == undefined || !keyboard_check( uiActions[ _i, key.contKey ] ) { _key = false }
    if _hasController {
        if !controllerRespond || uiActions[ _i, key.contButton ] == undefined || !gamepad_button_check( _id, uiActions[ _i, key.contButton ] ) { _button = false }
      
    } else { _button = false }
  
    if !( _key | _button ) || _debug {
        buttons[ _i, 0 ] = false;
        buttons[ _i, 1 ] = false;
        buttons[ _i, 1 ] = 0;
        continue;
      
    }
    switch( buttons[ _i, 0 ] ) {
        case key.free    :
            buttons[ _i, 0 ] = key.pressed;
            break;
          
        case key.pressed:
            buttons[ _i, 0 ] = key.held;
            if buttons[ _i, 1 ] { buttons[ _i, 2 ] = one_second div 8 }
            else { buttons[ _i, 2 ] = one_second div 2 }
          
            break;
          
        case key.held    :
            if buttons[ _i, 2 ] > 0 { buttons[ _i, 2 ]-- }
            if buttons[ _i, 2 ] == 0 {
                if buttons[ _i, 1 ] == false { buttons[ _i, 1 ] = true }
                buttons[ _i, 0 ] = key.pressed;
              
            }
            break;
      
    }

}
There's a bit more to it than this, but if you have some experience under your belt you can probably muscle out what it's doing. Anyways, next on the list of stuff is some art. The original sprites for the party have issues. They use their own palettes, and that palette is often not accurate to the full-sized character sprites. I'm not fully sure, I thought maybe was a NES limitation since only 4 palettes can be loaded at once, but that really just raises more questions. The Black Mage has two different palettes for example, so what gives?
I like these sprites, mostly, but that's a bit of nostalgia because there's at least one very important issue with them. All the NPCs are taller than the party, sometimes by 2 pixels, causing your party to either look like they came from a different game or that the Warriors of Light are just very short. I don't care for that and I started work on them. The palette issues are easy to fix but making them taller is a bit more dicey. If you are a purist like me there are a couple things you want to maintain. For example, the Fighter was probably the party leader most of the time. He has a very deterministic walk for his left/right movement. Sure, he looks a bit like an ogre lumbering around, but he looks like he has somewhere to be. The NPCs on the other hand do not, and just meander around. I think this is important because you see it A LOT, and I think it matters that your party looks like it has somewhere to be.

However, this presents an issue. The world map. I can't be certain but I believe the reason the party is sized this way was to make it more appropriate regardless of scene. On the world map, a full sized NPC looks like a goddamn giant. I mean, they always did, don't get me wrong, but two pixels makes a difference depending on scene. I want to fix the sprites for the town scene, there's no denying that and I already like the improved sprite quite a bit even though I'll still tweak it. But that means the world map has to change and this is where it gets tricky. I'm a purist. I really am, and I don't want to tamper with the game as much as possible. Still, this is a place where the visuals can be changed quite a bit. Still debating on this but I already have an idea which basically boils down to having a smaller, more accurate size for the party. I had a test batch of sprites lying around to show but I can't seem to find them, so here's a gif of the walk cycle I'm working on for the Fighter.

Needs work, but I like it better already.​
EDIT : Hey, look at that. I found them. I quickly adjusted them to work with the palette render and hooked them into the code and voila. This is really just a rough implementation, but this is pretty much what I'm going for as far as these sprites are concerned. To me, it adds a bit to that feeling of a large adventure as now the world is actually quite large compared to your party. There's some other stuff I'd like to do as well, but for now I'm just leaving this here to show off what I had in mind.
@Quailfail asked about how I determine what to change and what not to. For the most part, I've said and maintain I want the game to feel and play the same. My biggest complaints with the later ports and remakes is that they just change way too much both visually and gameplay wise to really be the same game. Obviously it could be argued I'm really not doing anything much different, and as the project gets further along into content I'll probably have some of the same effect on it. Still, unless you happen to be a massive fan of the game like myself, I'd wager most people won't even be able to point out most of what I've changed outside of maybe the color depth setting. So for me, the real metric is just how I feel about the changes I've made. I don't want to change things just to change them, or just because I don't agree with them. In the case of the walking animation above I think there's a little of that, but at the same time some of Final Fantasy's limitations were of the time. This was a new project, a new idea, and largely a last effort by the company. So while I don't have to defend anything I do, in this case it's because some of what FF is stems not actual NES limitations or even developer vision, but time, money and pressure. In the case of the sprites it's clear a second pass wasn't made for many of them, in fact, that's probably why the party sprites are the way they are in the first place. That's why I'm more liberal, or pliable, with changes to the art than I am about core gameplay systems.
Lastly, this is just me having a bit of fun. The truth of the matter is I'm not at home and I don't have my full PC setup with me, and I won't for a while. So while I absolutely loathe lugging around extra equipment, there's no reason for me to be ill-equipped for the task at hand, right? So for the random passerby that might be interested and my own enjoyment, here's the setup I'm using right this very moment to generate this post!
 
Last edited:

Hyomoto

Member
Alright, so I have another small update for you guys today. I did get a chance to sit down and work and I decided I'm going to try to get to a demo state. This basically means finishing up the content up until the Garland fight. It's a good metric for finding things I may have missed. This really led to my first order of business which was fixing doors. As some of you might be aware, the game has two kinds of doors. There are those that lead into a shop, and there are those that 'reveal' another area in the current map. Why this was chosen, or why it was implemented how it was is anyone's guess. But making sure I get the effect right is important to me and the previous event system was a mess. A literal mess. It worked, and I could even say it worked well, but in order to fix doors would require either some really, really bizarre code or a total rewrite. Guess which one I went with? This is hardly the most complex part of the game, it's biggest flaw was just being an area that expanded over time as I found more features I needed/wanted. Eventually you sort of come up with the list you need and at that point I just decided to do a rewrite. For example, the way events work is by having an action assigned to them. The action can be bump, touch, use or leave. The first is when you 'collide' with an event, touch is when you end movement on it, leave is when you leave it, and use is, well, when you press A. The last one is really the most complicated simply because it has to check it's own space, the space you are facing, and if the event has a 'pass-through' effect, the space behind it.

To start with I really simplified how events are found. I already made headway here when I changed how events are stored on the map, I could simply take a whole stack of events and then sort through them for what I wanted. This is still done, as there's no way around that part, but I pushed it out into a script that allows me to use a couple conveniences. Namely checking for an event in a direction or a specific tile, and then filtering the list it returns by events that have the type of activation I'm looking for. It turns out the majority of processing that events were doing was this, because the new code is ~200 lines shorter than it used to be. Some of this is because I simplified how events behave. I used to have a lot of specialty events to handle specific tasks, but by rewriting how events are triggered, those built-in 'functions' no longer exist and are handled by the objects themselves. For example, doors used to have special code written in, but now doors are simply three events: bump, touch and leave. The bump event opens the door and plays the sound effect, the touch event performs the action ( entering a store, revealing the room ) and the leave event closes the door. This greatly simplifies how events work, while also expanding greatly how they can be used. A few other clean-ups of code and the like and the system is mostly back together though NPCs logic is currently disabled pending review. Still, a massive improvement and I'm quite happy with it.

I also took the time to improve performance on the world map. On my system it used to run at a real_fps of ~300, and now it's running at about ~800. GM2 is amazingly efficient with it's tile drawing, far more than GM:S 1.4 ever was. The world map consists of roughly 32,000 tiles that are drawn every ( or every other ) frame. Previously it was drawing ~96,000 tiles. So if you are wondering where the performance gain came from, that's the long and short of it. I didn't actually reduce the number of tiles on the map, they are just drawn slightly more intelligently now.

I also, as you may have guessed, have been working more on content and art. This is easily as time consuming as coding the damn game. While I could just drop the original sprites in and call it a day, even that isn't as simple as it may sound. As I've talked about before, the entire game is run through a palette shader and that means all sprites need both a palette built and to be converted to use it. While I could be very lazy, instead I've chosen to implement a consistent palette format for everything in the game, something I've talked about before, and the short of it is if editing sprites was time consuming, hooking up palettes is even more so. Not to mention any new artwork that has to be done or added. Oh, did I mention this was on top of the coding tasks? I'll admit, I vastly underestimated the amount of work this would take. The good news is that my tools are improving and it's getting easier and easier to do it as features are solidified and the engine needs less and less code work. I haven't been able to do a video in a while, and I hate to have updates that are just walls of text, so here's a gif of the updated temple of fiends. This building is ugly in the classic, and it's largely thanks to a terrible tileset. It's supposed to reflect ruins, which I think it does, but what even IS any of it? It turns out build maps is easy, editing the tileset is the time consuming part, which required moving around the design of the level in addition to updating, adding and fixing tiles. The end result is quite an improvement. Obligatory 'not final' but most likely very close to what you'll play.
 
Last edited:

Hyomoto

Member

Showing off that enhanced palette and new sprite!​
Originally I didn't really want to show this off, but maybe it's a nice tasty teaser for those interested. I always thought Garland was a highly underappreciated boss. Supposedly he's quite powerful and a talented swordsmand. I get that the Light Warriors are awesome, and I get that there are four of them, but anyone who has played this game over-prepared. He can easily be beaten at level 1, making many of the fights getting to Garland more dangerous, and for most players he's considered more of a joke of a boss than a milestone. So while I don't intend to change anything about this right now, this is really the first character in the game that's receiving a total makeover. Despite being a swordsman, no version of the game has ever given Garland a sword. Later games like Dissidia would, but no port of the original ever has. So right away I knew I would at least give him a sword, he may be a pushover but he can at least have a weapon. Second, his out of battle sprite and his in battle sprite look nothing alike. This is another case of I have absolutely no idea why. Perhaps he puts his helmet on when the fight starts, but like the party, his color scheme is completely off. So I also wanted to give him a proper map sprite. And that's what I've done. I have kept his original color scheme because I do think it's awesome. Like all the graphics I'll still tweak them over time, but I still consider these to be a big improvement.

This picture is actually showing off two things, but one is probably far less noticeable. The way I was handling battlebacks, the 'background' image if you will, was to cut it up into three 48 pixel wide chunks and just repeat it four times across the top as that appeared, at the time at least, to be how the game handled it. After digging into the ROM to try and isolate these images (I was previously using FF3 rips from spriters resource, convenience man, it's a hell of a drug) I discovered something interesting. Each 'battleback' is made up of two 2 x 4 columns of tiles. To create some diversity, I assume, the developers cleverly don't repeat them statically, and rather do a 0, 1, 1, 0 repetition. So I went ahead and updated the battlebacks to use this new format and now they display just like they did on the NES. I'll admit, I love the added color depth. It gives me the ability to add just a smidge of detail or color where previously there wasn't any. I should admit my success and happiness with the end result varies quite a bit, but overall I really like the way the enhanced color works in the scenes. It's a feature you can toggle on and off at will in-game, so it really demonstrates both the night and day difference it can make. Hopefully not too much longer now. I updated some more event code to handle the Garland fight ( he attacks you after you talk to him ), which is also needed for treasure chests and have started getting the other classes in-game.

I don't assume I have a huge following of rabid fans eagerly awaiting a release, but to those of you who may be I apologize for how long this has taken. That said I want what I put out to be a tasty morsel and with no missing features or major bugs. I'm really pushing to have something out soon.
 
Last edited:

Hyomoto

Member
I'm putting out a short demo build called "Dill and Bary's Adventure". Presently you can guide the two Fighters, Dill and Bary, on a quest to defeat Garland. Because the demo is a bit short and light on content, I beefed up Garland to at least make him a worthwhile fight. However, this is firmly an alpha build and has some missing features! I wanted to wait, but I might be seeing a time crunch and I wanted to get something out, so here's the short list: inns don't work, clinics don't work and tents don't work. Also, no saving. Magic is in, and functions, but Dill and Bary are Fighters and don't have any so Heal potions are the only way to restore your health. If one of them dies, you'll have to start over to bring them back to life. But maybe someone is crazy enough to do a solo run. Everything else should be up and running. For this build I enabled the enhanced color depth so you can have a look at what that looks like. I originally decided against it because it still needs work, but I this is my way of apologizing for not having a more fully featured build to play. I think that's about all.

Oh, and if you find any bugs, please let me know and if the game crashes, please provide the exact text given at the crash. A description is good, but having that text makes finding things MUCH easier. The link is in the main thread, but because you were so nice to scroll all the way down here, here's another:

Dropbox

EDIT: Grrr, naturally there was a major bug in the first build I uploaded. If you managed to snatch it in that 30 minute period, please download the updated build and actually enjoy yourself.


Edit 2: I just realized the controls should probably be explained. If you have a controller, use that. Otherwise it's the arrow keys, enter, end, escape and backspace.
 
Last edited:

Hyomoto

Member
Update to the demo to fix some very important bugs. See the version history if you want to learn more. Other than that, I did a bit of behind the scenes maintenance of code clean ups and consolidations. Basically, previously every door, teleporter, treasure chest, etc... was all it's own object. They shared a common parent, but the amount of duplication was still very high since my lists of objects showed 'treasure_chest_1', 'treasure_chest_2', etc... I was reading up on the creation code in the room editor and it turns out this is a blob that is executed after the create event and before the room start event. So I moved a little code around and condensed most of these various objects into generic objects. This isn't a change so much to how the scene handles these object as it is a gross reduction in redundancy. It also consolidates a lot of specific code to the maps themselves and reduced the file size by a whopping 200kb. Basically I rebuilt everything I already have. This is more of a sanity net, as eventually these objects would have gotten out of hand. It's best to deal with this stuff before the project expands.

I also took some time to clean up some mapping mistakes. As I've previously mentioned, the mapping and event systems were the first things I wrote. And while they worked well, since then I've added features or removed things and the short of it is some of my old methods were a bit wasteful. Like reducing code redundancy I wanted to reduce layer usage and optimize tilesets. So I put a dedicated shadow layer into the maps and moved all shadows to a dedicated tileset which both frees up space and allows them to be shared across maps. This also meant cleaning up Corneria quite a bit, it was the first map I built and it had a lot of odd choices. Combined with the event consolidation and it's basically a completely new map. That improves the performance a bit as well, though generally that hasn't been an area of concern.

Lastly I was able to implement an effect I wasn't sure I'd be able to pull off. In the original game when you went to the menu, entered a shop or got in a fight, the screen would use some palette tricks. Originally this just wasn't possible and I really had no idea how I was going to pull it off. As time went on and I studied the effect more I started to see what it was doing better but it wasn't until I got the map render hooked up to the palette shader that it became feasible. The end result is amazingly faithful to the original effect and looks just great, in my opinion of course. It's here because it turned out to work literally on my first try. No code changes, fixes or adjustments to make. That's always a nice feeling.
Anyways, the demo shouldn't have any more game-breaking bugs in it. I started work on getting the Inn and Clinic implemented but they are not working yet. For the demo I also reduced the starting gold because I'm a masochist. Next up will be finishing up Inns, Clinics, Tents and some sort of rudimentary saving. Once those are in I'll be working on getting all the classes put in. I'm working on those other items first simply because the classes require a lot of data entry and art creation, the Thief is partially implemented but still needs a few more hours of work at least before he'll be ready. That's just one, and there are four more basic classes! As usual feel free to comment, try out the new build or just stalk the project.
 
Last edited:
Just popped in to say that I tried it.

First impressions:
- The keyboard controls are absolutely awful. Use something standard like Arrow keys/Z/X or WASD/K/L.
- 30 FPS. I don't know of a single release of FF1 that doesn't run at 60FPS. It makes the game feel choppy and some things like battle windows appearing end up slower.
- Graphics are great. The game looks similar enough, but you can immediately tell it looks better. The NES palette is very limiting, especially with colors that aren't blue. Very welcome changes.
- Battle animations are amazing! Love every bit of it.
- Madponys still suck
- Crashes in the item menu. I moved around a bit and it threw some error about item indexes. I assume this is because it isn't fully programmed yet.

I like it so far. One question: Are you planning on keeping the bars separating the players from the enemies? I ask mainly because you're already making it look better, and they literally do nothing.
 

Hyomoto

Member
Didn't have time to work on this today except two quick bug fixes. A crash when trying to equip nothing, and the sound effect repeating on the main menu when you skip the initial text crawl. Also, at @nacho_chicken's request, I've update the keyboard keys and enabled the full speed mode. If you get slowdown, let me know.

Edit - Another quick hotfix to resolve two more crashes in the party menu.

@nacho_chicken - I was literally about to push a new build to fix two bugs ( one is the crash ) when you posted, and so I'll go ahead and incorporate your feedback. There is a 'high speed' mode which runs at 48 fps, and a low speed mode runs at 24. I didn't enable it to ensure wider hardware compatibility, but I've gone ahead and turned it on. Please let me know if you get any slow down. I've done some optimizations, but I wouldn't be surprised if it runs poorly on weaker hardware and feedback is especially appreciated here. Also, the crash is fixed, sorry about that. Stupid mistake I actually added because I'm an idiot sometimes.

Lastly, right now I want to have a very, very faithful 'classic' mode. That was my original goal: to recreate the game with the bugs fixed. However, once I've gotten that done I'd like to do an enhanced version which would be more my take on the it with updated user interfaces. One change is a redesign of the battle screen. Sort of paying homage to a classic before I put my greasy fingerprints all over it. That said, there are some QoL and convenience features that will be added, such as item and magic descriptions, and the enhanced color palette and for now those changes will be large enough. I'm glad you enjoyed it, sans crash, and thank you for the feedback! Things like the controls are easy to ignore when you are working on it, so sometimes it's nice to hear you should fix it up. That said, the game does have full controller support and I recommend playing with one! But for those who aren't, they'll enjoy having better keyboard controls.
 
Last edited:

Hyomoto

Member
So, I had some time today and I decided that the priority implementation should be saving. Truth be told it's because I've been playing the demo to sort of get a grip on what the game looks like from the player's perspective. From a development perspective I tend to overlook a lot because I have this tasks I'm trying to complete. Turning that off I was able to find six crashes, all pushed previously as hot fixes, that just escaped my notice during testing because I wasn't using any of them in an actual capacity. The strangest by far was the item menu crashing when you have no items, it was a strange bug because I had coded in the ability to have an empty inventory. However, for technical reasons when the inventory is totally empty, it returns a value of -1 which is what caused the crash. Along the way I've squashed some other irritants and started putting together a log of observations. However, today I'm mostly going to talk about saving. I haven't used the buffer functions in GM2 at all, so because I'm tired of text files and because I wanted something a bit more secure I started reading into the manual about them. Immediately the buffer_save function jumped out at me. It's not that amazing, it just saves the specified buffer to the disk as a file, but it was that moment I decided I was going to figure this buffer stuff out I've written a lot of save routines using GameMaker: Studio and before's file handling functions. I hate them. So seeing that I had an alternate method to save a file and the output data would be more secure without really much effort on my part at all and I got excited.

The buffers are incredibly easy to use. Like a data structure you just capture the identifier when it's created and then you can use the buffer_write function. Since all the data in my game is generally stored in multiples of 4-bits, the buffers were like a magic fit for the data I wanted to put in and most importantly I didn't have to do any string conversions. Previously if you wanted to save a number in a file, you would have to convert it to text and then convert it back to a number when you load the file. It's just a chore. And yet, here with buffers I can line all my data up of the various types and then when it comes time to load, you just read it back in the same order!

Well, I would anyways if my data was a little more rigid. The game needs several blocks of data stored to 'capture' the current game state, namely the party order, the party members, the party inventory, party gold, metadata and quest states. Since my game is already build in such a way this data is readily available, it's not terribly difficult to save it. What is, is that the engine supports up to 255 party members, even though only 4 are part of the party. I wrote this because one day I might like to convert the engine to other games. In fact, there are quite a few features in the game that you won't see as part of this project but that I built in for future use. So in this case, it's not good enough to just paste data into the buffer, it needs to have some way to know what data is being stored so when I read it back it it gets translated properly. The thing about the text files are you can read exactly what text you are getting in, from a visual perspective this makes it easy to 'sanity' check. Luckily, as I said, I've done this a lot and I can apply that experience to buffers. Basically, as I said the save data is broken up into blocks. So, just like a text file, I just need to identify what each block is before I start reading it.

Once I had done this, things were working well. You could save and load and I was quite happy with it but I noticed a new bug had cropped in. You see, in the meta and quest data some things are stored as arrays. For example, one of those features I was talking about, chests can have any number of items placed in them. When you open the chest, the game will try to give the party as much as it can. However, anything the party cannot take is left in the chest. This is done by storing all the items in an array. The buffer, however, does not have an array data type. The solution? Just like the tags that indicate what a block of data is, quest and meta values specify whether or not they are an array, and if they are, how many blocks of data they contain. For some people this probably doesn't sound that interesting, you might be nodding your head going: yeah, that's what I would do. And heck yeah you should, buffers rule!

Enough about buffers and saving for now, let's talk QoL improvements. You can now stay at the Inn, though it isn't animated, and make use of the save system there as well. I also edited doors so that when you enter a shop and then leave your character is standing outside the store instead of inside the door frame. It's a simple visual effect but looks better and is more accurate as far as authenticity goes. So I'm pushing the new build, 052417a, today. At this point almost all core game functions are now up and working, should have some time coming up to get some serious work done but for now hopefully this update makes it a better experience.
 
Last edited:

Hyomoto

Member
Finally, time for some progress! Right to pictures:
Whew! So, with my free time I've been trying to get a little time in to actually play the demo I put out. And as I played I discovered two features it was in desperate need of: saving and magic. The game is cool, it's technically proficient and I'm super happy with my results, but a big part of classic Final Fantasy was building your party and heading out. I'm a ways off from the building your party part, but I realize that not having access to magic in the demo is a huge letdown. So I made it a priority to get a spell caster in the game pronto! Bary has gotten himself a new job, taking on the role of a Red Mage in the demo. I'm sure someone out there will say, "That's not red". Yeah, well the classic palette exists but Bary's palette is green and blonde. Keep in mind I, for lack of a subtler description, sort of rushed him in. Each class has twelve battle sprites, eight town and dungeon sprites, and eight world map sprites. And both of those sprites have a 'classic' and 'high' color mode. Long story short, classes are a lot of work and the Red Mage will need and see some tweaking to his sprites, though I'm very happy with the results for now. See them yourself in game in glorious 4-bit color!

After this, I'll be releasing maintenance on the demo if there are any game breaking bugs but otherwise I don't intend to update the demo content wise for a little bit. If I get clinics done, I'll probably slide that in because it's needed, but for now I think the demo does a decent job of showing what you can expect and hopefully being an enjoyable piece of content in it's own right. The truth is these updates eat up quite a bit of time, and I've probably been working a bit harder than I should so for now please enjoy the Red Mage, and get out there and defeat Garland!
 

Hyomoto

Member
Release 052517b, more bug fixes. I had about an hour to test today so I spent it just trying to play through the content. I found ~7 bugs, 6 of which I've corrected in this release. The other one isn't game breaking, sell items aren't sorted, and I'm not currently sure how I want to tackle that. It's more a quality of life feature than a bug, but I consider it a bug because that's likely how the player will see it.

- CREEP uses the wrong palette. Just a simple database mistake, palette was set to 2 which is the enhanced palette for the CRAWL causing the wrong data to be used for coloring.
- Magic charges were being added instead of set on level up causing the Red Mage to gain A LOT more spells than intended. This was a case of having had one intention in mind when I coded the routine and then having a different idea in mind when I actually added the data to the table.
- Status magic was bugged to apply a seemingly random effect instead of the proper one. After I added the ability for INT to affect spell effectivity I put in a check to prevent it from affecting status magic. However, I coded it wrong. I was checking if skill type was == skill_effect_swap, when it should have been & skill_effect_swap.
- Items can only be sold from the first party member's inventory. This was just a order of operations issue. I consolidated some menu code and in doing so, moved a line that resets the cursor position to 0 before that position is used to set whose inventory should be sold from.
- Odd tile placement in Temple of Fiends. This was actually an FPS concern. When building the map I applied a background which contained the layout of the temple (it's how I do all the maps). However, I forgot to remove it when I finished so it was actually drawing a rather large layer it shouldn't have.
- Long delay after status recovery windows are shown. Each status effect has a respond rate delay attached to it. Once all of them are shown, a window collapse event is called. However, that event also had a respond rate wait attached to it which I simply removed. I haven't tested this one yet, but it should fix the excess wait time.

Also, I realized a lot of the Red Mage sprites didn't have enhanced color support which caused him to 'flicker' in some actions. I'm sure I'll still tinker with his sprites, but at least he now has full enhanced color support.
 
Last edited:

Hyomoto

Member
I put up a new build today to correct a very, very terrible bug followed by another terrible bug. The first one is battles outright crashing, and the second is the item shop crashing when you buy PUREs. The first one was caused by a project cleanup and apparently a resource I thought was no longer in use was in use in one place on the battle screen. The second was a bit more odd and was actually a compound bug, thanks to @Mi7 for finding it. Essentially when you went to buy an item it was using the wrong pointer data, it wasn't checking the right object in your inventory to figure out if the new item would stack. The second issue was when checking how many you had, it was comparing the wrong bits. Neither of these were the result of the crash however, that was caused by there being no error message for the item shop when you cannot successfully purchase an item. It was an odd bug since you could still buy SOFT and HEAL, only PURE caused it. Oh, and the status screen will now display the proper class. It was hard-coded to say FIGHTER instead of using class data.

Anyways, that's up. But I got a whole day to work on the project and here's some progress to share! As I've said before, the game is almost code complete. Except for the various bugs that will inevitably be discovered, a few mechanics such as the clinic and tents which I've still yet to implement, and some polishing that will take place the engine is just waiting for content. After playing the demo for a while I know that getting all the classes in needs to be my priority. However, as I've said that is quite a bit of work and part of that is thanks to this feature:

Thief, White Mage and ... White Mage?

Four fighters? Sounds good!​
I've always been a fan of customization in games, and I wanted to have palette swaps for characters form the beginning. Today I standardized how this should work for each character. Basically each character has three custom colors: generally skin , hair and clothing that you can choose variations for. Way back when I first started I tried my hand at putting together a female fighter and I made two variants. I wasn't sure if I'd use them but the idea of also having variant sprites, specifically gender, stuck with me. Well, the White Mage from FF3 is female, so I was able to pretty easily put it into the game to test this out. You can see the results and I think it works out pretty well. While Final Fantasy is best with a diverse party, even still, being able to pick your characters is a big part of what makes an RPG what it is. I feel like my pixel work is getting better. I've had to put together all the world sprites from scratch and I'm pretty happy with the results. I'll likely tweak them more as time goes on but I was able to finish 5 of the six combat sprite sets, 4 of the world map sets, and 3 of the dungeon sets today and that's much faster than it took me to get the fighter in. Most of that speed comes from knowing just what sprites I need and how to arrange the palettes, but I'd like to think it's also an improvement in the actual detailing as well.

Speaking of which, I also changed the way the graphical aspects of classes are stored. Since that particular data has not only become more complex, but also needs to be referenced from other places now, I needed to build a new class table. Previously it was a localized table that was initialized when your class was, but that doesn't work for party building since I need that data to display the proper sprite and name. I originally was just going to fake it but that creates more headaches than it solves, so now all data is properly referenced from a single table. That's it for today, keep those bug reports coming in!
 
Last edited:

Hyomoto

Member
I don't have a new builds or anything to show off today. While testing I came across what amounts to a very, very large bug in the engine. I found I couldn't take any items in the Temple of Fiends other than weapons and armor, and even then armor was being put into the weapon inventory. My first suspicion was that I put the data in wrong, but that was not the case. Upon investigating I discovered the way items are given to the player is completely borked. The simple version is each item has a type, and each type belongs to a category. The engine takes that value and decides how to deal with an item given to the party. Originally there were two categories, is_weapon and is_armor. Basically if it wasn't one of these it was an item, and these were all I needed for shops. This meant I was using is_weapon and is_armor to decide where an item should go and either something recently broke it or, more plausibly, it never worked right to begin with. Why? Because they don't actually do anything. The shops don't even use them, since item type is coded to shop type, but wherever they came from I was treating them like item masks. Because they are nonsense in this respect, it means they mask out unrelated bits. An item makes use of 20 bits and looks like this:
Code:
00000000 00000000 0 000
 ^             ^  ^  ^
 |             |  |  \Item Type
 |             |  \ Is equipped?
 |              \ Item count
 \Item table entry
What I think happened is originally an item had 4 bits to assign a flag to. The four bits were item, weapon, armor and equipped. In this case, the mask would work. You could check item type & is_armor, for example, to see if the item was armor. However, that's not how item types are stored, and masking is not possible so this approach does not work. This is a prime example where direct references end up hurting. If I had done it properly to begin with I would have just added the item types and at worst offending items would work improperly, instead it ended up breaking pretty much the entire item system.

So the solution was to go back and fix the whole system. The first thing I needed to do was fix the category logic. I wanted to keep is_weapon and is_armor, but there were two things being left out by this and I added is_gold and is_item as well. Next up, with proper item categories working I consolidated all the item handling into a single routine. This is a bit of future proofing. Previously it was not possible to have a store with mixed wares, and while the game doesn't actually make use of this, I definitely want a back-end that could handle it if need be. Besides, it cuts down on code duplication and reduces bug potential as well as eases bug fixing. All good things. Lastly I just had to convert everything over to use the new system. This actually ended up being easier than I thought since besides chests, the only real other place this was used is shops. That said, a lot of other places make use of item logic, and those still need to be edited to use the new system. Not because they were broken by my changes, but because they still use the old way of doing things which is a liability.

Anyways, that was my update today and I'll see you next time!~
 
Last edited:

Hyomoto

Member
Well, today was a productive day. I went to work trying to whittle down my task log here, and that mostly consists of fixing all the bugs that I've found recently. Some, like the inventory bugs I talked about yesterday, were a lot of work and some, like MADPONY being invisible were incredibly easy. Today, however, I'm pushing the very first build where you are able to create your own party. All six of the original classes are in, and should be working. If you have any problems let me know. I keep trying to circle back around to working on content so I can get to beta proper but for now here's another alpha build, mostly feature complete and missing the following bugs.
Code:
Version 052717b -
*Added
 - Ability to select party on new game.
 - Icon to show when a controller is connected/disconnected

*Changed
 - Save system now saves and creates objects based on class ID rather than object_index
 - Completed BLACK BELT combat frames.

*Fixed -
 - MadPony does not appear except when it attacks.
 - When characters are hit with status effects, the idle does not change to reflect it.
 - Odd delay after restore status message in combat.
 - Gender is not saved.
 - In combat CURE uses fire animation.
 - Window for using items and magic out of combat is 1 line too short.
 - Corneria item shop has wrong prices for HEAL, PURE and SOFT.
 - Corneria item shop sells SOFT instead of TENT.
 - In combat, pressing B during command selection takes you back to the first character instead of previous one.
 - Items in ToF cannot be taken.
 - Leather helmet is added to weapon inventory.
 - Crash while entering shop and holding B.
 - Crash while saving at the Inn.
 - Crash while leaving a shop and trying to open the menu.
The good news is each build is, surprisingly, more stable than the last. Barring any new bugs my goal is to start getting all the Garland content up and running, testing that, and if everything works well I'll be officially pushing the project into beta.
 
Finally got a chance to test this sucker out! ... Unfortunately, I almost immediately ran into a rather game breaking bug, namely, the following error when trying to equip weapons or armor:

Code:
___________________________________________
############################################################################################
FATAL ERROR in
action number 1
of  Step Event0
for object window_menu_equip_toolbar:

Variable window_menu_equip_toolbar.class(100045, -2147483648) not set before reading it.
at gml_Script_calc_stats
############################################################################################
--------------------------------------------------------------------------------------------
stack frame is
gml_Script_calc_stats (line 0)
gml_Object_window_menu_equip_toolbar_Step_0
 

Hyomoto

Member
Today I’m going to try a slightly cleaner approach to my updates by laying out what I’m going to talk about, elaborating and then adding a closing statement. You know, like someone who gives a damn might do. For the past two days I’ve been mostly working on bug fixes and code cleanups, with some small added features peppered in for good measure. The problem with talking about this sort of an update is that I really can’t show you anything and it’s not like you’d notice anyways. Still, for anyone interested in the process perhaps you can gleam something useful from these posts.

First up is how icon tags for item and magic names are handled. This is a task that the results are generally cached for, meaning that the string is processed and then saved. To sort of simplify this task, I had originally hard-coded the tags to have to appear at the beginning of the name for two reasons. The first is that it just looks better. The second is because checking characters 1 – 4 of a string doesn’t need to be calculated, it’s always 1 – 4. However, even if these results weren’t cached this is an operation that happens very quickly and having it work this way is very limiting. Specifically, what if I wanted to include an icon in character speech? I could use a workaround by calling it for that word specifically and injecting it into the larger string, in fact this is how treasure chests work to some degree, but I wanted to expand it a bit. Now it checks how many tags are in a particular string, and then replaces them one at a time with the corresponding icon. This means a piece of text can also have as many icons as it needs, and as a sort of ‘catch’ it will also remove any tags that don’t match.

Next is a large cleanup on all of the party and character scripts. This one started with fixing a bug in the level up code that caused you to need 1 more XP than you should have. It was an easy fix, I just needed to use >= instead of > but I noticed that this was called in three different places. I’m not sure why I thought this was a good idea but it’s because the level up script would return which characters levelled up. However, to ensure that a character that gained multiple levels would do so properly I then had to check if there was enough XP to gain another level. On top of that it would also skip checking for a level up if no one gained a level. That sounds good on paper, but the truth is it’s just a complication. So the scene logic has been cleaned up to give the party XP, check each member for a level up, and then the battle ends. This solves the first bug because now the only time XP is checked is in that one position.

Fixing up the level up routine got me working on a larger clean up. I prefer all of my scripts to have a category, and that includes an introduction word that adequately describes the scope of what it should be doing. For example, all ‘global’ scope or ‘misc’ scripts use the ‘scr_’ intro to show they are generally a one-time or higher function script like setting the resolution or loading a save game. For something like giving out experience points, on the other hand, I use the ‘party’ intro. The reason this was chosen is because ‘actor’ is used in combat to handle battler scripts. However, there are a lot of party scripts that do not affect the whole party and some that should be broken down. Other scripts are just pointless. The result is now there are ‘char’ and ‘party’ scripts, char is obviously any action targeted at a single party member, and party is reserved for actions that affect the whole party. This means I had to break some functions down and then convert the party scripts to essentially be a convenience call, but in doing so I also simplified a lot of scripts and fixed some inconsistencies.

Lastly there are a few new minor features. I added a new feature to EASY MODE, which is when a character levels up their new HP will match the same ratio as it was pre-level up. That is to say, if you had 100% health before the level up, you will have 100% afterwards. I also worked on some per-class overrides. The KNIGHT and NINJA can now properly gain spell charges, and the BLACK BELT uses the proper calculations for unarmed and unarmored attack and defense. I also started work on Corneria castle which along with the Mystic Key are the last two pieces needed for the Garland section of the game. So yeah, things are coming together and I'm hoping to push this into beta in the next week or two.
 
Last edited:
K

Kenjiro

Guest
Damn that's a lot of text. Had to swipe up on my phone at least 100 time to get to the bottom of the page! :p
 

Hyomoto

Member
Holy crap, there are some bugs that refuse to be fixed it seems. Or more specifically, to be found in the first place. I cannot figure out what is causing this but when a map loads, the party is created and has its direction set during the create event. Then, in the room start event the image_index uses this value to set the proper frame of animation. For reasons I cannot comprehend, the value is wrong during the very first step. It's not like it's being constantly changed either, just apparently something happens between the room start event and the begin step event which causes this value to be off by 1, and only if it's greater than 0. Apparently if I just update it again it works fine forever but the question is why is it changing in the first place? The only reason this bug is even noticeable is because normally NPC frames are updated each step anyways, but this update doesn't normally happen during a scene transition which causes it to be visible. No matter what I do I just can not find the source of this bug. I've checked every line that references direction or image index and even logged which event is doing the change and what event is being changed, as well as the value of image_index for any of these changes and nothing. All I've discovered is that the value set during the room_start event changes before the begin step event. Theoretically this means something created after the party has to be changing it during it's own room start event, but I've even tried this on a blank map with no other events and it still happens. The fix is relatively easy, the NPCs now just update their frames regardless of scene transition, but it is absolutely maddening to be unable to figure this out. This is truly the strangest bug I've ever encountered.

The reason this came about is I'm working on a clean up of the NPC code. In the engine the difference between the party and an NPC is basically you control the party and can trigger events, otherwise the code base is shared. However, there's always been this bug with the party where when you change scenes the party is facing the wrong direction until the transition completes. So I figured this was a good time to tackle that. What I didn't realize is that I'd apparently already tried to fix it before, and apparently just assumed it worked (because it should have) and this is the rabbit hole it led me down. Ugh. I wasted two, maybe three hours trying to find this and to no avail. So enough of that, the fix works and is really all that should be needed: but damn it this is just so aggravating.

Anyways, I'm mostly done with condensing the NPCs down to generic events the same way that all other events work now. This is mostly just to remove a lot of entries from the resource window and also consolidates the NPCs themselves to the rooms they exist within. In fact, there have been quite a few of these over the past weeks and this is just the latest version. A while back I consolidated a lot of NPC action code so that all NPCs can respond to any type of action, you just simply have to give that NPC a piece of code for it. The issue is that most NPCs don't have a need for that code, so it's kind of wasteful to bother having a unique resource for every one. Even within the confines of the create event there is quite a lot you can do to customize and NPC and it's behavior, it's only when you need more complex handling that a custom object is required. Which is how it should work. I'd probably have finished this earlier but I wasted a lot of time tracking down nothing, but this should be done soon. I've also finished the first floor of Corneria Castle and updated the code that handles how rooms are displayed to fix a few bugs and handle some edge cases. Progress continues.

This update is mostly a rant, but sometimes you just have to vent.
 
Last edited:

Hyomoto

Member
So after some rough patches here and there, content is moving forwards again! NPC logic has been finished up, I put in proper support for locked doors, and I finished Corneria castle, Corneria and the Temple of Fiends. There is still some work left to be done, that stuff I've put off forever. Namely game overs and the Clinic. Still have quite a bit of work to do I suppose, but the game is very, very playable. For those of you familiar with the game, the screenshot might look just a wee bit odd. That's because this is the first level that I rebuilt. The original Corneria Castle second floor is, I have no idea. The problem is that the map doesn't look anything like the castle, and the first and second floors seem to have nothing to do with one another. So I rebuilt the second floor to actually seem a bit like an extension of the first floor and also I've added some more decorative elements to help spruce up the castles a bit more. I also got proper shadow support working so they'll be more of that, and I'm sure some other stuff I missed. I'm going to upload this build and it'll be the last one until I finally get all of the game logic in. Keep in mind it is possible to have the bridge built and to cross it, but what lies beyond is not finished in the slightest but you can have fun exploring beyond the confines of the original map. Also, as you can see, I'm putting the new icons to use since they can now be used anywhere.

Because of the really, really large changes to the engine I fully expect bugs. I'm hoping I caught most of them, but history has long proven I did not so as always, please report any bugs you find! That's it for today. Short and sweet!
 
Last edited:

Hyomoto

Member
Today's update is another small one as I slowly work towards finishing up the final features. That said, there's actually quite a lot new going on. It may not surprise you to know that someone who is remaking Final Fantasy for the NES might be interested in as authentic experience as possible. This includes the controller. While up until this point I've been using an XBox One controller for testing purposes, it's not ideal. So, I searched around online and in local stores trying to find something that would be a better fit for this project. It turns out there are quite a few options. There are supposed USB hubs that will convert NES controller signals into digital ones for the computer but that sounds like a hassle and all the reviews said it didn't work. Next up, there are quite a few USB NES controllers available, but they are all super low quality, most reviews list them as garbage and they are directInput not XInput. Sorry, but I'm only supporting Xinput for now. Finally, and I can't remember why or how, I came across 8bitdo.com, and it turns out they sell a very nice controller for this purpose. I bought it last week, but it came in today and I finally got to hook it up!
Unfortunately it didn't work straight out of the box, it turns out the one I received was using a very out-of-date firmware. However, it was super easy to update and the latest version allows me to also use it with my Nintendo switch. I approve! Once I got it working and started playing I came across a important problem: the d-pad is connected to the joystick and not the POV like I expected. At first I thought about trying to find a swap joystick to POV, but then I realized I don't want to mess around with any of that and the player shouldn't either so I simply added joystick support for movement which solves the issue and gives a little more flexibility if you choose to use a joyostick instead. Maybe you want to play with an NES advantage. However, there was a more serious issue at hand: anyone familiar with NES controllers knows the proper layout for the B and A buttons are B on the left, A on the right. In fact, though this uses Xinput, the buttons are labelled correctly. I never even noticed it being backwards on the Xbox controller (it's second nature with that controller to have A on the bottom). But as soon as you hand me an NES controller and the inputs are reversed? I go into Nintendo mode and this will not do, this will not do at all.

So I did what any sensible person would do: reverse the buttons. But then I started thinking about it: assuming you do play my game, and assuming you do use a controller (you should, what the hell is wrong with you?), I'm guessing it's most likely you'll be using a PS4 or Xbox-style controller. Most people are not me. 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. It wouldn't be right to annoy every single other user just because you are all wrong. So I put in the ability to swap the B and A button layout. If you hold select (or back for those of you with the wrong controller), you'll see the B and A buttons swap. This setting is saved, and the default is the Xbox layout, so even if you do prefer the alternative (you should), you won't have to set it every time you play. So those of you who are like me and want the proper experience, you can get that now.
I have some pretty specific art and design guidelines I try to follow to maintain than NES feel, which means I generally avoid animations like this. However, in this case it's important for the player to know this is a system function and not game feedback so I tried to make something that was noticeable, and obvious something happened, but without breaking you out of the game. A while back I put together a really basic 'widget' framework which basically lets me give feedback using icons, sound and animation that ignores everything: scene changes, screen effects, restarts, etc... quite versatile. Right now only the controller makes use of them, but I'll probably put them in for saves and such eventually as well. Anyways, a lot of work on controller support today. Fixed some bugs, finished the new game screen (and updated it to make choosing and customizing your party easier) as well as the long-awaited ability to name your party! See the changelog for everything, keep those bug reports coming, and farewell until next time!

Until next time!
 
Last edited:

Hyomoto

Member
It's here!
This is an exciting day for me. Today I finally achieved all of my alpha goals, and am confidently ready to push the project into the beta phase. Today is the official release of 'beta 1'. It contains the original 6 classes, Corneria, Corneria Castle, the Temple of Fiends all of the associated content up until you defeat Garland and cross the bridge. The project has grown more ambitious than I initially expected, and taken far longer. With that time I've added a bunch of quality of life features as well as some other comforts to make this the 'definitive' version of the game I love so much. The controller support, palette and gender swapping, expanded names and font tables, as well as the enhanced palette are all things I hadn't planned on doing when I started. Now that that work is in the past, I couldn't be happier. This is truly a passion project I'm proud to share! Just for statistical prestige, the project was started March 20th, 2017 and took 350 hours to reach beta on June 6th, 2017.

That badge costs 350 hours.​
On a personal note, I have no idea what the raw interest in this project is. I know there are plenty of people out there that if they knew about it would probably be interested, but I also know that 'started' projects, and especially 'alphas' and 'betas', are a dime a dozen. The real value is actually completing the game and giving people something to play and enjoy. So I hardly expect bells to be ringing. Nonetheless, all of you who read my status updates, send me messages and lurk on the thread, you should know that your contributions are not minor. Everyone who has downloaded the game, everyone who has reported bugs, and even anyone who just lurks on this thread have served as a source of inspiration. This topic has been viewed ~1,500 times and for a project I started just over a month an a half ago, I think that's pretty cool and definitely serves as a source of motivation.

So about the beta. The engine is more or less complete and no additional major features are needed. I've fixed a lot of outstanding bugs, pushed in a few small features and tried to get this build as solid as possible. There are still some behind the scenes tweaks I want to do, and there are some larger changes to some interface elements I'm considering, oh and I'm sure there are still bugs to squash, but if I did nothing else I could pack the entire game in and that ... well it just feels good. Coming up I'll be putting together the rest of the area around Corneria and Pravoka. That includes the Ship. One of the interesting features of the original game was how well it tutorialized itself. You start out in Corneria with nowhere to go but the Temple of Fiends, and pretty much everyone asks you to save the princess so let's just say you have a pretty clear goal in mind. Once you do that, the bridge is built and you can visit Matoya's Cave and Pravoka. It is the latter location where you get the ship and the game starts to open up. There are four ports you can visit within the initial area and the game really starts to feel large at this point. However, despite a fairly large quest chain you are just getting started. Once open the canal, the world really opens up and pretty much all direction is up to the player. That makes the project pretty intimidating since while this first block is fairly easy to implement, it's very straight-forwards, moving ahead the game really starts to open up and that's when, just like for the party, that the real work begins. Until next time, thanks for watching, thanks for reading and most of all, thanks for reporting bugs!
 
Last edited:
This looks amazing! I am a huge fan of the original FF on NES, it is probably this (and Dragon Warrior) that created my love of RPG games. I played through the original beginning to end at least a dozen times, if not more (and started and never finished probably dozens of other games). Suffice to say, I have put hundreds of hours into this game over the last 2-3 decades ;).

I am going to check it out, I will give you any feed back I can think of when playing.

I think the potential here is great, though - hopefully too much support doesn't draw the all seeing eye of the big N and get your project shut down. I could see your engine as a launching point to build out your own game and story to avoid that eventual issue.

In a perfect world, they leave you alone - you recreate the game but add more features, UI improvements, classes, monsters, loot, magic, map locations, etc... basically build Final Fantasy 1+ which is basically the original game PLUS a whole bunch of changes.
 
Top