Beta Final Fantasy for NES [PC Beta Available]

Hyomoto

Member
@DividingByZero - You might find it humorous that this project actually somewhat got it's start as a recreate of Dragon Warrior. I originally selected that game because of just how unbelievably simple it is. It's a good quest, and I've been trying to get my time to complete under 4 hours for a while. I have a few prototypes lying around as well that I started in GM:S, and then later tried to port to GM2. However after watching Final Fantasy run at AGDQ I started reading up more and more about it and started getting more and more interested in a 'bug fixed' version. There are quite a few guides on fixing the various issues with the game, but eventually I was like this is a heck of a lot of work. I might as well just make the game myself and then I can do whatever I want without limitations. So, that's basically how it got to where it is.
 
@DividingByZero - You might find it humorous that this project actually somewhat got it's start as a recreate of Dragon Warrior. I originally selected that game because of just how unbelievably simple it is. It's a good quest, and I've been trying to get my time to complete under 4 hours for a while. I have a few prototypes lying around as well that I started in GM:S, and then later tried to port to GM2. However after watching Final Fantasy run at AGDQ I started reading up more and more about it and started getting more and more interested in a 'bug fixed' version. There are quite a few guides on fixing the various issues with the game, but eventually I was like this is a heck of a lot of work. I might as well just make the game myself and then I can do whatever I want without limitations. So, that's basically how it got to where it is.
Ha, that is funny - started out DW. I tried it, it is very cool - I love the minor graphical updates but keeping to the original style. I also like the improved battle animations and what not.

If you get to a point where you are taking ideas to alter/improve on the original - can you please make it so if a target dies, the players attacking will move to the next available? That always bugged me about the game. And the fixed in later games, so I don't think you'd be out of line. ;)

Keep up the good work!
 

Hyomoto

Member
Ha, that is funny - started out DW. I tried it, it is very cool - I love the minor graphical updates but keeping to the original style. I also like the improved battle animations and what not.

If you get to a point where you are taking ideas to alter/improve on the original - can you please make it so if a target dies, the players attacking will move to the next available? That always bugged me about the game. And the fixed in later games, so I don't think you'd be out of line. ;)

Keep up the good work!
It's actually already coded in. The thing is, it's not a bug. It's intentional, and keeping it is too. To distill the conversation, I understand not everyone likes it and you are right: later Final Fantasy games did away with it including the remakes of the original. So, there is a (currently inaccessible) easy mode that if you activate it will provide some 'convenience' features such as target switching. However, the reason I've included it as an optional feature and it's currently disabled is because it basically ruins the game. I don't expect to fully convince you, but combat is essentially a tax and the longer combat goes on the higher that tax is. So the player is directly rewarded for optimally assigning resources in combat. If the game just reassigns your target when you, essentially, pick wrong: it removes a huge element of player choice and strategy. With it on you are largely relying on luck that your characters will attack in an optimal order, most of the game becomes holding down the A button. With it off you have more control over that order and it's a combination push-your-luck and know-your-world mechanic. Remember Final Fantasy XIII? That's where removing this mechanic leads to, that was the inevitable end point. Doing away with all meaningful gameplay and replacing it with an 'Auto' command. Perhaps that's a tinge dramatic, but the game isn't horribly complex, and even a simple change like this has huge ramifications. So while I have included it, it is my least recommended way to play.

Short answer: I've put quite a lot of thought into this, I've coded in the alternative into easy mode, but I think that it damages the gameplay by reducing player interaction. Still, I understand it also has value so it's an option for those who want it even if I personally loathe it.
 
Last edited:
I hear ya, it is totally part of the original game, the strategy, etc... I agree. But, I also get frustrated by it now when I replay the game. You are correct, though, the combat isn't terribly intensive strategy-wise, so retaining that original functionality adds some amount of strategy.

I can see and support the idea of recreating the original first. But, I also see lot of possibilities to make lots of improvements across the board - so make the combat more intensive in other ways, so some of those other changes make more sense.

Anyways - I am totally blown away by this so far. You have my support if I can help at all.
 

Hyomoto

Member
@DividingByZero - I appreciate all feedback. Switching targets is appealing because it makes sense to the player. That guy is dead? Attack someone else. Switching targets is definitely the simplest solution, but it's more band-aid than fix. The literal problem is when you watch your character walk forwards and attack the darkness. I'm not sure what the best solution is for that, but that's where the core of this issue lies. Something which could be slightly more understandable is if I just skipped the character when they have no target. Then the player is like, oh, his target was dead so he didn't do anything. It may not match their preferred action, but it preserves the line of logic from the player's perspective. Not to discourage you or anything though, and it will be an option. Just playing the game is super useful, and giving feedback on systems I'm grateful for. I see the game through the same lens you do, I've played and completed it dozens of times on multiple systems. I love the game (obviously) but that does blind me to things. My friend pointed out the other day he had no idea what the 2 next to his magic was. He thought it meant he had two spells. Looking at it now I'm like, yeah, I can see that. So I'm looking for ways to make the game more approachable as well. After all, when I played it as a kid it came with a strategy guide. Clearly there is room for improvement. This is why characters raise their hands when you are buying items: to let you know who can actually use it. Cutting edge technology if I do say so.

Speaking of which, how about an update?

The problem a lot of RPGs have, especially old ones like this, is that combat is the main attraction. Final Fantasy is 50% fighting, 45% travelling and 5% opening chests and talking to people. This is why I'm careful to tamper too much with the combat. If I simplify it, it becomes boring. If I add complexity, it becomes a nuisance. My general idea for improving combat is to make it more intensive, but also reduce it's frequency. Basically I'd like battles to be less of a damage-per-turn affair and reward the player more for proper item, spell and skill usage. The player should be adequately rewarded for combat, but also given tools to avoid it. To this end I'll be tweaking enemy groups, spawn areas and threat levels. I want there to be battles that some parties avoid and others enjoy. I'd also like to introduce a 'population' mechanic that reduces encounter rates the more battles take place in an area. Essentially a 'thinning' of the herd the more you fight. Lastly, I would like to introduce class skills to add a bit more versatility to non-magic classes. I won't be implementing most of this yet, but as I've said from the beginning, once I get a faithful recreation up I'll start more complex game changes like these.

Today, however, I am working on Pravoka. I completed the rest of the continent and filled out all the battle regions and encounters, so next up is Pravoka and the ship. I usually have the original open while I'm working, and I use a series of cheats to bypass a lot of stuff. Doing this I realized the way the game checks for the ship is quite odd. I'm not entirely sure but it seems whatever tile the ship is on takes on that personality. When you are on a port tile and try to move into the water, it checks if that tile is the ship and if so performs a bit of trickery by changing the party into the ship and clearing that tile. This means if you were to, say, edit the tile the game looks for the ship, you can make it so you can embark at any port! So, I want to replicate that behavior. Partly because it would make a bit of debug logic easier, and I just think it's a fancy solution. While I could pretty easily change what object represents the player, it's much easier to simply change what the player collides with to replicate the various types of movement. Besides, the canoe basically uses this method anyways since the player can enter or exit the river on any valid tile. Since the engine is mostly done my task list is now mostly content-based, and coming up is Matoya's cave, the Dwarf Cave, ElfLand, ElfLand Castle, Northwest Castle and the Marsh cave! Once all that is done, well, that section of the game is complete! Barring any minor bug fix releases, that will encompass the next content update and it's a pretty decent chunk of game. I have no timeline other than it will take longer than I'd like but probably be faster than I think.

Well, that's the plan anyways. So until next time!
 
J

joseph pro

Guest
@DividingByZero - You might find it humorous that this project actually somewhat got it's start as a recreate of Dragon Warrior. I originally selected that game because of just how unbelievably simple it is. It's a good quest, and I've been trying to get my time to complete under 4 hours for a while. I have a few prototypes lying around as well that I started in GM:S, and then later tried to port to GM2. However after watching Final Fantasy run at AGDQ I started reading up more and more about it and started getting more and more interested in a 'bug fixed' version. There are quite a few guides on fixing the various issues with the game, but eventually I was like this is a heck of a lot of work. I might as well just make the game myself and then I can do whatever I want without limitations. So, that's basically how it got to where it is.
i like retro game
 

Hyomoto

Member
Today's update, to me, is a bit controversial. Because it's basically 100% what I'm against doing. This is one of those moments I talked about where I most certainly can but wonder if I should.
Those of you who are not familiar with the original game, this is not how it happens at all. It's kind of funny to work on the game and come across what I consider to be ... the weaker portions. The Garland fight is already pretty high on my list but I guess I forgot about Pravoka and the ship. The thing is, Pravoka is being attacked by pirates and the light warriors have to confront Bikke and defeat them. Afterwards Bikke gives you his ship and you can continue. In game this equates to walking up to Bikke, fighting 9 of the weakest enemies in the game, and then ... you are done. So much room for improvement. So today I put in an entire chain of events. When you arrive you find the pirates assaulting someone. Save him and he'll tell you that the town is being attacked by pirates. There are pirates everywhere ransacking the town, and once you've defeated enough of them, Bikke will appear to confront you. It works well, it's enjoyable and it adds quite a bit to what was essentially a throwaway encounter in the original game. There are a few quirks to it that stretch this part out beyond just adding a few battles. However, the question is of course whether or not I should. So far most people who have played and given me feedback have been pretty vocal that they are completely fine with, and totally support expansions to the game like this. Hell, I do too. In fact, the only reason this took me so long is because I had to add a few new features to the engine to handle cut scenes. It's very basic, but it allows me to move characters around and show dialogue boxes.

What I've decided, for now is to just also do a non-enhanced version of Pravoka. I did the same thing for Corneria castle. For now, future demos will be set up to run the enhanced content, but later on I'll provide the option, much like the difficulty levels, to play a more faithful version or the enhanced one. The question I present to anyone who would like to chime in is how interested are you in an enhanced version? What about the classic mode? The thing is, this enhanced version adds quite a bit of content to an otherwise very short part of the game, and I absolutely adore the improvement. So for the demo it's a nice chunk of extra stuff. In fact, it makes me want to go back and touch up the Garland encounter! However, this stuff does slow down development a lot. I already have a lot to do in terms of additional graphics, maps and just raw data entry. Coding in event sequences and the subsequent testing is a large chunk by itself. So I guess what I'm interested in is does anyone care? Would you rather see more content, or wait longer for it?

Anyways, a nice short update (for once). Matoya's Cave and Pravoka are completed, and I rewrote the ship so it works again. Next up is ElfLand!
 
Last edited:

Hyomoto

Member
Another short update. So, after talking it over I've decided I'm just going to do the enhanced version as a default. One of my initial goals has always been to clean up the script and fix some plot issues, but so far I've just basically recreated the game verbatim. However, there's no real way to fix some of the biggest problems with the way the game handles the plot without being a bit more hands on in the process. I don't know if I talked about this before but my idea was originally to have a dialogue-based system where you can talk to people and try to get information. Basically some words are 'key words' that get added to your vocabulary. Then, if someone knows something about that topic you can ask them in conversation. It still needs a bit of tweaking but I got the initial prototype up and running. It supports all kinds of features including context awareness so it's possible to change what people have to say about topics not just based on their knowledge of it, but also what's going on in the plot. I think I'll most likely only use this feature on key NPCs because of the sheer amount of dialogue that would be required otherwise but it should add quite a bit to the game and player interaction. Oh, and I also added another QoL feature. Previously party members would raise their hands when they could use an item in the store, now it will also display that item's stats and how it compares to what that character currently has equipped. Anyways, that's it for today!

Share with me your secrets.

Knowledge is power. The power to make the right decisions.​
 

Hyomoto

Member
Another quick update. Nearly finished with the dialogue system, and I've decided I'll just be using it everywhere. It's pretty easy to use on an NPC, and adding in their original dialogue is good enough for now. The best part about the system is it's very expandable, so I can just leave them with conversation bones for now and add in more complex speech later on. The general gist of it is an area has a list of topics that are relevant to the people who live there. When you talk to someone it combines this list with a list of words they know checks it against the list of words that the party knows. The end result is you can ask anyone about anything that's going on in the local area that you also know about. Not every NPC has information on every topic, and some NPCs know more than the general population. When you talk to someone, any key words they use are added to the list the party knows. In this way your dialogue options increase as you talk to NPCs and ask questions. Finding topics and the people who know about them should be a nice extra bit of flavor.

I've said before that Final Fantasy is like 50% combat and 45% walking around. That last 5% is talking to people and opening chests. This should help make talking to NPCs a more relevant part of the game, and hopefully a more enjoyable activity. It also serves a practical purpose of taking the place of the 'quest log' modern games are so fond of. The original game did not have a quest log, at best it had a map with glowing dots to encourage you to visit them. Other than that you were on your own, talking to random people was the only way to piece together the story and what you should be doing. I liked that, but I also know that the game came with a strategy guide. So clearly, clearly it could use a bit more direction. So now, rather than having to seek out specific NPCs for cryptic clues on where to go next: if you are ever in doubt about what to do, talk to the locals. They generally have something to say about what's going on in the area. In fact, when you first arrive in a new place you probably won't have many topics you can ask about, so as you talk to more and more people that list starts to grow and a picture of what's going on and where you can help begins to form. It should make discovery a bigger part of the adventure and make quest discovery a little more organic. After all, those little rumors and hints might have something to them...
 
Last edited:

Hyomoto

Member
Just another small update, mostly still working on implementation of the dialogue system. There are a couple hiccups I ran into in terms of needed functionality that I'm still not quite sure how to implement. The first is multiple pages of text, right now it just locks out any controls other than the A and B button which will advance the text. However, I need to put in some sort of indicator that shows that there are multiple pages of text. The other thing was for subjects you can ask or talk about multiple times to get additional responses. Still not sure if this one matters, but experimenting. The last is a bug that cropped up. It turns out the draw_text_ext has a bug in it where it doesn't always treat every line of a monospaced font as the same length. So even though it may cut some lines off at the right character, other times it terminates early. Since the dialogue box is only 20 characters across, accurate word-wrap is important. So I've gone ahead and implemented my own word wrap solution. One benefit is I can define break characters, whereas the built-in method only breaks at spaces and dashes. I've decided to move my goal post a little bit because of this, and now I'm going to work on getting all the current content up until Pravoka working with the new dialogue system and that will be the next release. This will include Matoya's cave, Pravoka and the Ship as part of the new content. ElfLand, Dwarf Cave, Marsh Cave and Northwest Castle will not be a part of it.

I'm also looking for ways to standardize and simplify the implementation of the new dialogue system. Overall it's pretty easy to use and set up, but in cases like quest marker advancement and multi-page dialogues I'm trying to see if there isn't a way to handle this beyond just having to custom code it in for each NPC. Most don't use it, so that is a viable option, it's just I'm lazy and this is tedious so if I can simplify it I will. I don't want to push much further ahead until I'm sure this is the method I want to use and it's working correctly. So far Corneria has been updated, and I'm working on Princess Sara and the King. Something I've wanted to do since the beginning is require you to see the King to receive your starting gold. It's a good way to introduce a bit of the plot and encourage the player to explore around. However, just like the original game if you want to skip this you can. However, you'll be required to punch Imps to death for gold. This is something I love about old NES RPGs. Dragon Quest (or Warrior as it's called on NES) has a whole plot and story for you to uncover, but if you've played the game before you don't have to do any of it. For example, the Loto Seal (sorry, used to GBC version) is literally just lying in the Marsh. You are supposed to use Lora's Love and some clues to find it. But if you know where it is, there's literally nothing stopping you from walking right to it and picking it up. I love that sort of stuff. Fallout 3 was another fantastic example of this type of storytelling. If you know where your father is, you can walk right to him (or even stumble across him) without ever having asked a single NPC about it. Final Fantasy is a bit more rigid but it also has some areas where you are more free to do what you'd like and contributing to that only brings a smile to my face.
 
Just another small update, mostly still working on implementation of the dialogue system. There are a couple hiccups I ran into in terms of needed functionality that I'm still not quite sure how to implement. The first is multiple pages of text, right now it just locks out any controls other than the A and B button which will advance the text. However, I need to put in some sort of indicator that shows that there are multiple pages of text. The other thing was for subjects you can ask or talk about multiple times to get additional responses. Still not sure if this one matters, but experimenting. The last is a bug that cropped up. It turns out the draw_text_ext has a bug in it where it doesn't always treat every line of a monospaced font as the same length. So even though it may cut some lines off at the right character, other times it terminates early. Since the dialogue box is only 20 characters across, accurate word-wrap is important. So I've gone ahead and implemented my own word wrap solution. One benefit is I can define break characters, whereas the built-in method only breaks at spaces and dashes. I've decided to move my goal post a little bit because of this, and now I'm going to work on getting all the current content up until Pravoka working with the new dialogue system and that will be the next release. This will include Matoya's cave, Pravoka and the Ship as part of the new content. ElfLand, Dwarf Cave, Marsh Cave and Northwest Castle will not be a part of it.

I'm also looking for ways to standardize and simplify the implementation of the new dialogue system. Overall it's pretty easy to use and set up, but in cases like quest marker advancement and multi-page dialogues I'm trying to see if there isn't a way to handle this beyond just having to custom code it in for each NPC. Most don't use it, so that is a viable option, it's just I'm lazy and this is tedious so if I can simplify it I will. I don't want to push much further ahead until I'm sure this is the method I want to use and it's working correctly. So far Corneria has been updated, and I'm working on Princess Sara and the King. Something I've wanted to do since the beginning is require you to see the King to receive your starting gold. It's a good way to introduce a bit of the plot and encourage the player to explore around. However, just like the original game if you want to skip this you can. However, you'll be required to punch Imps to death for gold. This is something I love about old NES RPGs. Dragon Quest (or Warrior as it's called on NES) has a whole plot and story for you to uncover, but if you've played the game before you don't have to do any of it. For example, the Loto Seal (sorry, used to GBC version) is literally just lying in the Marsh. You are supposed to use Lora's Love and some clues to find it. But if you know where it is, there's literally nothing stopping you from walking right to it and picking it up. I love that sort of stuff. Fallout 3 was another fantastic example of this type of storytelling. If you know where your father is, you can walk right to him (or even stumble across him) without ever having asked a single NPC about it. Final Fantasy is a bit more rigid but it also has some areas where you are more free to do what you'd like and contributing to that only brings a smile to my face.
I like your thought process here with needing to speak with the king to get your starting gold (and to start a bit of the story telling). I also like the expanded text from NPCs, it gives an extra push to actually talk with them.

On a similar note, one of my favorite things about FF2 and 3 (USA numbering) was seeing what I could get away with ahead of time. There wasn't a ton, but there were some things tucked in various places you could get to early and give you a little boost or just break from the linear part of the game.
 

Hyomoto

Member
Just a teeny, tiny update for today. A combination of internet troubles (and that GM2 refuses to work as intended without internet) and lack of free time means I haven't worked quite as much on this as I'd hoped. I was hoping to have some screenshots and stuff up today, I do hate doing multiple text-only updates, but this is going to have to do.

So in the little time I did put into the project I had to go back and fix the word-wrap I wrote. Again. So, there's a lot of new text being introduced thanks to the new conversation system, but the thing is up until this point I basically was inputting it by hand and letting the word wrap format it for me. I can do manual formatting but it's limited and time-consuming. So I put together an in-engine way to enter text and be able to see exactly how it will display. This of course highlighted that once again, word wrap was not working as intended. The problem actually turned out to be very small, \each time a space was inserted at the end of the line it wasn't being counted if the line was wrapped, so now word wrap works very well. The only issue I have is that it won't properly terminate after a comma if that is the last character on a line, but that simply requires manually inserting the new line. This is really the first tool I've written to simplify working on the game, and while what I would like is a way to edit text databases without having to recompile the project ... I'm not sure I want to put the work in to make that a thing. For now, this is just a handy way to make writing text quite a bit easier.
 
H

HA2ARD_R380RN

Guest
Was never really a fan of FF, not in its early years neither later, so I don't know how best give feedback on all this. For starters all the menus look like a pain to make, kudos to all the great work.
What I can say is that, although I am distant from such a title, it still feels so right. It takes me back to classic games with every image I see. Such a well executed idea! :)
 

Hyomoto

Member
While I could probably at this point write a pretty lengthy essay on my feelings about it, suffice to say the original Final Fantasy stands out among every sequel for one very odd quirk: it's a western RPG. It was styled quite a bit after D&D and even a lot of the lore and monsters are firmly rooted in western fantasy. Every sequel, however, is decidedly more eastern-influenced. It's the black sheep of the franchise in many ways, and I think that's why I remember it so fondly as opposed to every other jRPG I've played (or because it's literally the second cartridge I played, before that I only had the SMB/Duck Hunt combo). It's interesting to hear an outside opinion on it, so thank you very much for your compliment and kind words!
 

Jyrocity

Member
This is fantastic. I started something like this many years ago, I would like to share it with you.

-Jyrocity
 

Hyomoto

Member
Still haven't had much time to work on this but I still wanted to give a little update here. After mulling it over for a while, and looking at the code base, I've decided to scrap it and largely start over again. A defining part of the engine, and quite to it's detriment, is I originally set out to pretty much emulate the NES way of doing things. This meant certain things were built in such a way that no longer make any sense as I steer sharply away from that. Not to mention that I've added or changed quite a bit recently to try and make room for some features the engine was never designed to support. What this basically means is the code base has become untidy. I've done some pretty big cleanup jobs already but the internal inconsistency is driving me nuts and I just want a more stable platform. I love standardization and there are just some decisions that I made early on that are biting me in the butt right now. That said, there are parts of the engine that are well done and will be salvaged. Things I wrote such as the music player and the controller handler will be cleaned up a bit but are useful as is, and obviously all the art, music and internal databases are still useful and were massive bodies of work. The original engine took about 150 hours or so, and hopefully the rewrite will take less than that but it'll probably be a few weeks at best before it can be brought back up to parity. This will also let me pursue something else I've wanted to do: externalize the databases. The end goal would be to allow me to make changes and see them in real-time without having to rebuild the program every time. It will also allow me to put together some tools to make editing the databases a bit easier.

That said, I've started already and the first thing is getting the render back up and working with a few tweaks. Originally the render pipeline was split into parts and the final image was composited together, but the scene as a whole was rendered to the application surface. This worked, but the problem was in order to perform certain rendering tricks I had to render the whole map (including non-visible parts) every frame. Now I'm using a similar method except each part is rendered to it's own surface before the final composition stitches the scene together. The big change here is that only the parts of the scene that change are redrawn each frame. That alone yields massive performance improvements and is something the world map in particular needed. Initial tests are a room 2048 x 2048 filled completely with ~6000 tiles still has a performance of > 6000 real_fps as opposed to ~1200 with the old method. This should free up quite a bit of render budget so I have room to add effects if I choose to do so later on, but more importantly will make it more playable on lower hardware specs. Anyways, that's the update for today.
 
Last edited:

Hyomoto

Member
New render is working out very, very nicely and there are some other benefits beyond just the increased performance. First off, some old bugs such as when actors leave the map they disappear has been fixed. This was because originally everything was drawn to the application surface, so anything off the map disappeared because it was being drawn beyond the surface. Now the actor surface is the size of the window, and anything outside of that is no longer drawn. But anything within the window will appear correctly. The other issue with this was the application surface was always the size of the room, which meant any flood fill effects like the 'infinite' tiles used for the ocean and grass were unnecessarily taxing. I had bypassed this by using a special surface for the flood fill, but this is no longer necessary and opens up options for parallax backgrounds that would have been more difficult. Some older effects that I stripped out, namely the animated ocean, can be added back in for very little cost as well.

However, the star performer is of course performance. A game like this no one expects to be particularly taxing, but it was deceptively so. A few people reported low performance on the world map, as I expected, which I'd used a few little tricks to try and mitigate but the truth is it was just a really big map and rendering the whole thing took processing power. Now, since it doesn't have to re-render it each frame (even with effects like the animated ocean), the whole thing has been sped up considerably. So it's somewhere around 4 thousand frames per second rather than the 1 thousand I used to get and the improvement of being able to use as many layers as I want as well. This is just a demonstration to show off that it does indeed work, and that the project now runs in 96 frames per second instead though whether or not I'll be keeping that is questionable at this point, that was just to acquire some additional processing overhead but also shows off how much better it runs considering it's a higher real_fps despite doubling the fps.
 

2DKnights

Member
I like the project and dedication. I wrote an implementation of FF3 battle engine for GM Studio, I made many changes, ATB, graphics, palette swapping etc, One thing I did do was to alter auto targeting (which FF3 did have) for defeated opponents. I gave a 75% reduction in power for a redirected single attack or spell (with a special sound effect) and name (Redirect), I believe this would give the player an incentive to target wisely but if the player is fighting weaker enemies there would be no need to plan so much, or if they were trying to desperately to finish off a tough foe, they might take the chance of doing weaker damage.

I think a system like this could work well in your reimagining of FF.
 

Hyomoto

Member
Not as much to report as usual, just a quick update to let you all know I am indeed working on this even if slowly. The map rendering is done, works great and I've been working on setting up data organization for it. Music and the controller are in and working, and I hooked up a slightly more complex debugger to help view some data that wasn't previously visible to me. I wanted to add mouse support which isn't as hard as it might sound since my controller object actually HAS mouse support, it's just commented out and with it A* pathfinding. Basically I'm playing around with whether or not I can make it touch/mouse controllable. I also started working on the party database and building the underlying functions which interact with them.

This is something I talked about a little while ago, but when I first started prototyping the engine I had done things in a very direct way. That is to say a lot of data was directly referenced. As time went on I worked a lot of getting rid of others and replacing them with indirect references so that I could more easily add or change things. Since I'm working from the bottom, I'm building all that into the foundation instead which will make for a much cleaner experience. The other issue is when I started adding the new dialogue boxes, they were built on some new code, which was sitting on top of some old code, but I still needed that old code for treasure boxes aaaaand ... well, let's just say this is another good opportunity to clean that up. The same goes for NPCs and the player, they used to share a lot of code, but they still required their own. What I want is for the NPCs and the player object to share the same exact code base with the sole exception that the NPCs are controlled by an AI, and the player is controlled by the player. This includes adding in A* pathfinding to make it a bit easier to handle cut scenes. Obviously this is quite a bit of work, and honestly I've decided to not work very hard at it.

When I did the first engine I worked, far, far too hard on it, skipping out on A LOT of sleep. For something that is, at it's core, a hobby project, there's no reason to do that. Mostly because as none of you are aware, the demo has gotten exactly 29 downloads. I'm excited to play my game, but the demand for it is pretty low. I'm sort of glad I added in that tracking because it made it a bit more apparent that I'm not accountable to anyone but myself here. It's easy to get swept up in thinking everyone is as excited for your project as you are. I've seen plenty of fan projects come about that took the author years to make, so I don't know why I was so dead set on getting this done but it is a bit of weight off my shoulders to just put a few hours in here and there. To be fair, things are still progressing faster than I expect since every time I need art or sound that part is largely done. So I'm just taking my time to build a better code base to work off of now that I have my final feature set and know what I want the end result to look like. That said, as you have probably noticed I'm also going to be updating less, maybe once a week at most. That might ramp up as I have more interesting things to show, but for now just a mild pace is the one I want to take.
 
Thanks for the update! Mouse support will be a good addition, I think. Many people that will play this, may never have played it on NES. We did, so we know that the game controls one way and mouse seems odd. But, for others, playing something on a PC without mouse support can be an almost awkward experience.

On a side note: The coolest thing about what you are doing now is that - yes, it will be Final Fantasy, which is amazing... - but the other take away is that you are going to have a pretty sweet custom RPG engine that you can build into other games (if you so chose). It seems like this latest 'reboot' of your engine is going to make those types of things much easier?

Anyways, keep up the good work! It is a great project and eventually will pay off for you in one way or another (either just improving as a developer, making a good game engine, or just completing on a passion project). Also, low downloads means that you are under the Big N's radar right now. If you get too much coverage, you can probably expect some cease and desist type events occurring.
 

Hyomoto

Member
I sat down the other day and wrote up a proper 'camera' for the game. Gamemaker Studio 2 has a built in camera system, but I'm not using it because of the way the scene is rendered. This is one of those, it used to work this way, and now it works that way kind of changes. The original 'camera' if you want to call it that was pretty basic, it was locked to the player object. This is one of those 'direct' references I've mentioned a few times now, and basically it meant that to fix it would have been a huge headache, but it was also the source of a lot of headaches. Basically in order for the render to work properly in the first case a scene required a player object, because the camera demanded it, a system render, a depth render and a few layers. Oh, and also a scene definition, that was required too. This meant that for something like, I dunno, the main menu, which wasn't a map the render basically fell apart. My workaround was simply to 'pause' the render. This in itself was another problem because, well, the whole point of the render was it's a convenient way to handle scene processing. So getting rid of it meant that scenes where it was paused had to duplicate some of it's behavior. I think it's pretty obvious why I didn't like it.

So, as I've mentioned before, the render object is no longer a global object. It's a scene object. Which means rather than one persistent object, it is created when the room is, and then sets itself up accordingly. So for GM rooms that are maps or menus it won't break, and I can keep the functionality I need for that particular scene. This is where we get back to the camera. As I said, I want to have a little bit of scene processing to handle things like cut scenes. The way it worked before is it would pause the player object, telling it to stop hogging the camera, and then manually set it. Ugh, such a headache. And ugly. And also what the hell? So how does the camera work now? Well, it's pretty simple. You can provide it three different types of data, undefined, an instance id or a set of coordinates. Undefined means the camera won't update at all, which means I could manually change the coordinates and handle it if I wanted to like before but it's no longer dependent on a specific object. In the case of an instance or an set of coordinates, you can specify how the camera moves. There is a camera_instant, which simply moves the camera to the new position, and camera_glide which causes it to move over a series of frames. The movement can also be provided a bias which will curve the velocity towards the beginning or the end of the movement. Think really of any modern UI for an example, but basically it means you can start off with a high velocity and reduce it to zero as you approach the final point, or start at a low velocity and increase it.

Not really a whole lot of work, besides that I found and reported two bugs in the GM runner, one has to do with using draw_surface_tiled when a room draws a layer to a surface that is larger than it's dimensions, and the other is if you press left shift and right shift together, vk_rshift will always return 1 until you restart the application. The first one is related to a bug I reported in GM:S for draw_sprite_tiled, so I find it kind of amusing it turns out the bug fix wasn't applied to all 'tiled' draw calls, but the original bug was fixed so I have no doubt this one will too and to be fair it only happens under very specific circumstances. The second one is just bizarre. But I guess that's the benefit of having a lot of people use your product.

@DividingByZero - Yeah, I think so too. If done right, it's actually not too hard. UI is sort of a hobby of mine, and it really is what separates good projects from the bad. I admit I think it would be pretty funny to do it better than Square. Their mobile games have some of the worst UI I've ever seen, so much so that if I didn't know the games were good I'd automatically assume they weren't just because the UI is so ugly.
 

MaGicBush

Member
Wow a lot to catch up on later! This looks amazing OP! I will gladly play it when it's finished(played way to many fan projects like this that never finish). I as well played this way back on my NES when I was around 8. I was actually wanting a different game, and remember being mad at my parents for getting me the wrong game lol. But when I got older around 10-12 I started playing it a ton and loved it as my first RPG! Thanks for your hard work and I will read through the rest of your posts. I was actually wondering how capable GM would be at producing an RPG game, as I don't like the restrictions on RPG Maker's battle system. Good to know it is possible with a lot of work.

I am a bit worried your project will be silenced one day though. I have seen a lot of fan projects like this die because Square gets word of it and drops the hammer. They do not like fan-made projects for whatever reason.

*edit* After reading through most of your posts it was fun watching your progress on this! And seeing how long it's taken :). It inspires me to get started on my game. I have worked on the design for it for a month now, but have not actually started it lol. It seems really daunting and I don't even know where to start on my game. At this time I am kind of waiting till I can afford to upgrade to GM2 from 1.4 and working OT so I can.

On your question of the enhanced version, I like your original idea of having it separate and optional. While I do want additions and expansions to the game content as you said it slows your progress down. I would rather see a completed FF1 game so I can enjoy it, and then you can go back and add those enhancements later and release your expanded view on the game but that's just my opinion :).

*edit 2* So a double edit here as my first edit was up until you asked about the enhanced version. I realized reading more you decided to go for it, and then decided to totally redo your engine lol. Well guess my opinion doesn't matter at this point, but that is how projects get stuck in development hell friend. Hopefully you don't get burned out trying to make it perfect before finishing. If one day this does see completion I will be glad to give it a shot, but hopefully you still keep it mostly authentic only adding touch ups to lacking area's as it's needed. Other-wise it will lose that nostalgia feel, and I wont be interested.
 
Last edited:

Hyomoto

Member
@MaGicBush - You wouldn't be wrong, all I can say is I have considered it. I'm not really worried about development hell since it's not a matter of livelihood or anything. My real concern is started projects are a dime a dozen. You are very correct. Finished projects are far more rare, and I did start with the intention to finish. The original engine still works and I have thought about undoing the dialogue and scene changes and go back to mostly working on art, sound and databases. I mean, that's pretty much all that was left. However, I want to continue on the current engine because it is for the better. Still, I have strongly considered finishing as intended first. We'll see :D
 
Last edited:

Hyomoto

Member
Ho ho ho! Big news today! I haven't actually started work on the game yet as I've been mostly putting together the engine tools, however I decided I'd gotten far enough that it was time to try a new challenge. Something most of you probably aren't aware is the original engine couldn't be compiled using YYC because it threw a bunch of errors. While it is true that I could probably have isolated and fixed them all, it wouldn't compile. So today I went ahead and gave it a shot. A little background, I've used the compiler in the past. I don't know how much better it's gotten, but it has historically disliked certain ... lazy methods you can use in GML. Basically just because you write it in GML doesn't mean it will run compiled. That being the case I have as time has gone on tried to adapt more compiler friendly habits.

So imagine my surprise when I hit compile and it didn't work! Hint: sarcasm may be at play. However, it threw two errors in ternary instructions. This is not new, and is a bug I've reported in the past but it seems either it or some variant of it still exists and ternary operators can be ... fickle. This is a bigger problem because I happen to really like ternary operations. In this case I found my old post and tried to apply the workaround apparently I'd found but it didn't work. Here's the good news though, the offending code is only used by the debugger to input camera control, and because it's just a ternary operation I can unpack it into a larger and less elegant version. Easy. And it's just those ternary operations, not all of them! So what is the result? Why, a fully compiled render! Exciting!

This is another good time to show off something else that is working. The debugger now has some extra features to help me view data during runtime in a visual way. In this case, in this screenshot you can see that debugger in action as well as two events occupying the same space! This is something that wasn't possible in the earlier version and is thanks to better abstraction on my part. The movement code used to be a ... be all end all solution. It handled everything from detection, to collisions to animation. Now, it doesn't. This is one of those major reasons I mentioned for wanting to start over instead. The previous engine worked, but it was messy. Some other stuff is I did roll back my original intent. It turns out having a per scene render works ... except it made it really hard to switch rooms in a graceful way. Not impossible, just not better. So the render has gone back to being a per-scene entity with one caveat, the 'helper' renders, ie: the system and depth renders are room dependent. This isn't required but it is the softest solution. Basically what happens now is when the room changes, the system and depth render are killed off. When the new room starts, they are recreated as needed. The end result is quite good. The old render used to have a heck of a time with a system restart. There was a whole script dedicated to cleaning up the engine so that it could restart gracefully, but now that shouldn't be an issue since using room_goto no longer causes it to panic. Anyways, work continues.

Until next time!
 

Attachments

D

danzibr

Guest
Astounding! This is really inspiring.

I'd love to give this a whirl. It may be a few days, but this looks really promising.
 

2DKnights

Member
I played it a bit, so far it seems good, I like the palette swap options for the characters, something that is easy to implement, but sadly many games are missing.

0. I suggest in the shops loop the hand raised animation for characters who can use the items and/or display the low hp animation for characters who cant. This will make it easier to tell who can wear what.
1. Dont forget in the original you could change the party leader by pressing select without changing your order.
1. Also the fighter's walking animation needs work, I'm good at sprite work, if you like I could work on it for you. PM me if interested
 

Hyomoto

Member
@danzibr - Thank you, glad you like it.

@2DKnights - If the animation makes it more visible, I'll probably do something like that. Seems like a reasonable improvement. Also, you can change your character order by pressing right in the menu screen though I admit there's nothing in the game that tells you that (and I admit I relied on series familiarity so much, this change is even less discover-able).

A bit more work today, I put in the event collision and animation system. The walking animation is not quite implemented yet, simply because I haven't decided quite how to handle the timing yet. After doing the camera work I decided to use a very, very similar method for handling movement timing and handling as well. Basically it means that if it were allowed, the movement system can handle timing and animation for any number of tiles in any direction. This isn't, once again, something I intend to use but it's a more expandable and robust movement system so there's no reason not to use it. Additionally I fixed all the collision problems with my original system and now movement and collisions are determined separately. Looking into it more, I'm not entirely sure how feasible A* will be. Not because it's impossible but because I'm very concerned with the performance considerations based on how collisions need to be calculated. If it was just tile passable/not passable it would work better, but unfortunately that isn't the case. Still investigating options with this. Basically the most reasonable option would be to have objects update their contributions to an overall passability map, but there's other issues with that. Having overlapping instances as well as 1-way blocking, etc... definitely makes this more complex. Anyways, here's proof I have made progress and until next time!

I don't show it very well here, but I'm actually outside of the map, something that wasn't possible on the previous engine. You can go on for infinity in any direction. Or at least until something crashes or overflows.​
 
Last edited:
A

Ankokushin

Guest
OP, congratulations on your work, really.

Do you give me permission to pass a link of this thread to Hironobu Sakaguchi public relations staff? Most likely my message will be ignored, but in the best case scenario, you might receive the creator´s blessing and get his input.
 

Hyomoto

Member
OP, congratulations on your work, really.

Do you give me permission to pass a link of this thread to Hironobu Sakaguchi public relations staff? Most likely my message will be ignored, but in the best case scenario, you might receive the creator´s blessing and get his input.
While I obviously can't prevent you from doing anything, and while the idea that the creator would give his blessing is certainly awesome, I'd say now is not the time. The project is too young and undergoing a rewrite, and even though I am proud of what the demo accomplished, I'd rather put my best foot forwards. And as many people have pointed out: being small and unknown also means no one messes with you, and that's the path I'd rather take for now.

I appreciate the interest though, it's nice to hear from people who want to see it finished.
 
A

Ankokushin

Guest
While I obviously can't prevent you from doing anything, and while the idea that the creator would give his blessing is certainly awesome, I'd say now is not the time. The project is too young and undergoing a rewrite, and even though I am proud of what the demo accomplished, I'd rather put my best foot forwards. And as many people have pointed out: being small and unknown also means no one messes with you, and that's the path I'd rather take for now.

I appreciate the interest though, it's nice to hear from people who want to see it finished.
I understand and respect your choices, of course. I am very impressed by the attention you are giving to this project and I really think Sakaguchi-san will be touched - if he ever learns about it. I wish you the best of luck and I am sure you will accomplish something very cool. I haven´t played FF 1 myself but I vow to do so once your remake is done.
 
D

danzibr

Guest
I understand and respect your choices, of course. I am very impressed by the attention you are giving to this project and I really think Sakaguchi-san will be touched - if he ever learns about it. I wish you the best of luck and I am sure you will accomplish something very cool. I haven´t played FF 1 myself but I vow to do so once your remake is done.
Whoa, you personally know him?
 
A

Ankokushin

Guest
Whoa, you personally know him?
You know, now that I read my post, sounds like I do - but I do not, at all. I only have some emails of his staff cause I was a fanboy for way too long in my teenagehood.
 
D

danzibr

Guest
You know, now that I read my post, sounds like I do - but I do not, at all. I only have some emails of his staff cause I was a fanboy for way too long in my teenagehood.
Still, that's awesome. Wish I could claim as much.
 

Hyomoto

Member
As usual, work continues but I decided to sort of prototype two new features as part of the render. It's hard to explain just what the differences are but all rendering now shares a unified code base, whereas before it was a lot of case dependency to decide, when what and where should be drawn. That gives me a lot of flexibility to affect just how things are rendered to the screen, and in some cases make some changes. In this case, I was playing around with adding a type of real-time shadows to actors. That likely makes it sound impressive, and I assure you it's not, it's just that you can define a single shadow for an actor and it will be drawn. The point of doing this is I can also control the color of the shadow in-render so if, for example, you enter a dark room I could feasibly change the color of shadows to reflect that. The second thing was a variable height. As far as the data is concerned, each sprite is located 'at a tile', but where it's drawn to the screen can be affected however I'd like. So I was playing around with giving actors different y-positioning on the tile plane. It can't be too much because other wise the player will become annoyed if they cannot pass and it looks like they can, but it just adds a smidge of visual diversity to the screen. For purists, it's quite simple to toggle it off (though all feedback thus far has been 'visual improvements welcome!'). I also put in the animation routines so now the player can be properly animated, but I didn't upload a gif since it's just of the actors walking. And lastly, this was a little while ago but I put in a smarter caching routine to try and help keep performance impacts as low as possible. Previously the scene cache for events would have to update every frame because characters can. However, this included rebuilding a list of all the current actors. Now that second action is only performed when something is added or removed from the scene. Anyways, that's about it for event rendering at this point and I'm going to start moving back into the UI stuff. Scene transitions, character movement and obstruction, animation, depth sorting, layer rendering, etc... is pretty much done now. So far the improvements have been well worth it, and hopefully it will show once the project starts coming back together into a playable state again.

First pictire shows off shadows and height adjustment, second shows off those debugger features I spoke about previously.​
 
Last edited:
D

danzibr

Guest
Looks good!

You're using objects for collisions? I'm using tiles in mine. I especially like tiles because it makes vehicles a lot easier.
 

Hyomoto

Member
Looks good!

You're using objects for collisions? I'm using tiles in mine. I especially like tiles because it makes vehicles a lot easier.
Actually nope, the collision grid is calculated when the room starts from the tile layers like you are doing, in fact there are some special flags that are assigned as well, the cursor shows the value for that tile. Those are the red squares. However, for actors and such they are stored in a ds_grid which the orange outlines represent. Object collisions wouldn't work very well and would be too slow. So nope, we are probably doing things quite similar!
 
D

danzibr

Guest
Ahh interesting. Thanks!

For some reason when I saw the colors my mind went to objects.
 

Hyomoto

Member
It's always funny when I'm working on this and I get some lofty ambition or idea and I have to remind myself to reign it in, reign it in. I was playing Kingdoms of Amalur and it reminded me how much I liked that game. One of the interesting aspects of it is you really do get to choose your play style. Granted, that style is generally "what you want to hit the monsters with" but the game has great diversity in that regard. So naturally I think of my own project and sort of ask, I wonder just what type of features could work in Final Fantasy. I've considered some sort of 'skill tree' in the past, also influenced by games like XCOM 2, or even certain aspects like sanity and stress from games like Darkest Dungeon. The point is really just that part of me wants to complete the game as originally intended, no changes, part of me wants to complete the game as intended, with some UI and QOL improvements, and part of me just wants to go insane and morph it into some sort of twisted abomination. Thank goodness for the sane parts of me.
 

Hyomoto

Member
So it's been a while since my last update, and the project believe it or not isn't dead. Progress just sort of ... tapered off thanks to the Atlas Rising update for No Man's Sky. Not trying to advertise or anything like that, just letting you know I kept meaning to sit down and work on this but kept playing that instead. But I'd like to keep you guys updated so here goes: Going to try to take a few hours here this week to get some stuff done because at the end of the month is XCOM 2: War of the Chosen and I'll definitely want to play that as well. I did do a little bit of technical work but nothing really particularly interesting, just setting up some foundation work. I think I'm leaning towards making some smaller changes to the game, more in line with my original intentions but I'm still working on how to implement them and still retain what I like about the game.

First up is some minor enemy abilities. Something that a lot of people don't like and won't agree with, but was very true in Final Fantasy, is that you don't want to fight all battles. Some party compositions just aren't as good at dealing with certain enemies, and some enemies have painful abilities that are just best avoided. It's really what was supposed to lend value to the Thief, a guaranteed runner could help move you out of those types of battles. Since FF was based largely on D&D of the time, there are a couple annoying and terrible enemy abilities I'd like to add, as well as make some tweaks to the existing ones. For example, 'dissolve'. A magic 'hit' would cause a piece of armor or weapon to dissolve. Some items would be immune to the effect, but others not so much. There's two reasons for this: first off, each character can carry four weapons but it's just dead inventory and this would give value to carrying multiple weapons, and second it's a great terrible ability to make a memorable enemy. Quite in line with the punishing difficulty of the original.

This transitions nicely into another change: being able to swap weapons in battle. The game has multiple weapons that target specific enemy weaknesses, but because of a flaw in how they are assigned (and a resistances bug), it's generally best to just pick your strongest weapon. However, being able to swap weapons as needed in combat would allow a bit more tactical flexibility the original game did not have without dramatically altering how it's played and is really the easiest to make. You could already 'use' equipment in battle, this would just allow you to change weapons.

The biggest item though is something I doubt anyone would notice or care except for hardcore fans but is a massive change: an alteration of stats. I had already implemented some of this in the demo, but the core issue with stats in FF is that they are largely useless. Hell, most don't do anything at all. I've considered plugging them into certain rolls the way I did with Intelligence but while that helps, it doesn't change your stats do little to distinguish differences between your characters. So I'd like to double-down on weapon types and resistances. For example, skeletons being vulnerable to blunt weapons and magical creatures being damaged by silver. Basically pushing most of what stats used to do into equipment and magic spells and retooling those equations to reflect it. In many ways to bring it more in line with D&D in general, the much older versions of course. This is all part of a bigger hope of transforming combat from being a 'travel tax' into being a more engaged and considerate part of the experience.

These are just generic examples, but I feel if I laid the groundwork where this was consistent throughout the entire game it would do a lot to respect the gameplay while helping bring it past it's NES limitations. As I said, I'm still working on just how I think this would work so nothing is set in stone. Still, I enjoy the creative freedom I want while still staying true to the source material.

That's it for today!
 
Last edited:

Hyomoto

Member
So soon? Must be progress! Hey, who wants to get back to updates where I ramble on about technical stuff? You? Perfect! As mentioned in my last update I'm still working out how I want to accomplish a few things, and I have some ideas. What it comes down to is I don't want to change how the player perceives combat, but I'd like to make changes under the hood to how results are produced. That way the game remains faithful, but also allows me to make the sort of mechanic changes that interest me. But, in order to do so I have to have some idea of how these changes would work in a game setting. How do I do that? Microsoft Excel.

Oooh lah lah, check out those assumptions!​
Right now I'm mulling around an idea of proficiency. The basics are like FF2 or Skyrim, use a weapon or type of magic and slowly you improve with it. This is all part of a much larger bunch of ideas so for now just consider proficiency to be a reflection of accuracy and damage potential. Now, the thing is, I know what I want it to do but how long will it take the player to improve? What level should they start at? What rate of increase should I use? These answers aren't easy to examine without tackling something else first: levels.

In FF the player can reach level 50, but it's common knowledge it's mostly a grind after that and the game can be beat around the 30 level mark. So I made two observations: the player could reasonably be expected to complete the game at level 30 and they should have gained 333651 experience points to get there. To tweak the curve, and as a control, I chose level 10 as a nice low point where the player should have earned 11116. From these requirements I was able to produce a growth curve that indicates at any given level how much XP the player should have gained. The last piece of the puzzle is how many battles the player would need to fight to reach level 50. Of course, this is just an estimation but it is based on the idea of the number of battles rising alongside with levels. This may sound imprecise but consider this: RPGs tend to have a inherent 'correction' for under and over leveled characters. Namely that as you 'fall behind' a single victory is worth more, and speeds up progress, while the higher you are the less a victory matters and progress slows. Generally if the player progresses forwards, unless they choose to grind out, this isn't a terrible prediction and it's still better than guessing.

Besides, that can always be tweaked if the numbers it produces look wrong or I find out I was totally wrong on implementation. So now we start getting into the meat of this spreadsheet. Based on the given assumptions and the XP curve, I can theorize how many of those 'total' battles you've completed, and given a set of assumptions about how much proficiency XP you might be expected to earn in a given scenario, figure out how many levels you could be expected to reach in order to achieve a specific proficiency. This is quite important because the only other way to test this information would be to literally grind it out in game and see what happens. I can take data from the engine to make my assumptions, but this is a good way to get a picture of it. In fact, once we know these growth curves we can even plot it to see what the entire curve would look like:

This shows variations in the XP scale the player expects to be at assuming the maximum attainable XP.​
Given all these tools it's much easier to tweak numbers and see just how a change is going to affect the overall outcome. Now, there are some things to consider when doing this and the major one is pretty obvious: your assumptions are only as good as your data! On paper this could look very nice, but if I've left out or overlooked a particularly important variable, the final result could be completely off. The other issue is consistency: these numbers work as long as I maintain that methodology throughout. It might surprise you to find out, but when designers are working on an RPG they often treat levelling as a function of time and not of experience or numbers of battles fought. They decide how long they think the player should invest to reach the next level and plan content according to that. The results of this going awry are players figuring out how to maximize their gains within that time by exploiting outliers. A famous example for me would be FF speed runs where the RNG is manipulated to produce an exceptionally high number of ogre fights to maximize gold and XP. I digress, for me I'm going with a slightly stranger metric: number of fights I expect the player to be involved in.

So what am I doing with this information? It might sound strange but FF is almost entirely combat when you get down to it. The problem is too much, or too little, can make the game uninteresting or boring. Referring to the chart we can see at level 30 I can reasonably expect the player to have fought 371 battles. Given that I consider this to be a fine 'end game' level, I can then extrapolate how many battles, given a defined rate of progress, what proficiency they would attain with a single weapon type from a starting rating. In this case, the graph depicts a FIGHTER could reasonably expect to max out a weapon around 30 levels. Pretty darn close to what I'd like to see. I then tweak the scaling curve for the weaponry to see how each class responds and where I personally feel they should end up. For example, to take a weapon from F class to SSS class would require 40 levels. Given the FIGHTER is a weapons expert and has a 15% bonus to growth, this seems about right. Let's look at what the Black Mage might look like:

The Black Mage, is not primarily a melee class and therefore the assumptions reflects as such.​
Looking at this we can see that, really, the Black Mage can be expected to never master a particular weapon type. This is based on the assumption that they will not only perform less melee attacks than the fighting classes, but that their low accuracy and damage means they'll be responsible for less kills as well. Looking at these numbers I can say this seems satisfactory. If you ground it out because you wanted to, specialized your caster or performed some other action to improve their XP gain, yes, they would faster. But under 'normal' circumstances, it's likely a Black Mage would reach level 30 with a B or A rank with their weapon. Sounds about right to me.

At this point you've probably moved on from reading this but let's say you stuck around and you have a question: what is the point of doing this? What is 'proficiency'? The idea is pretty simple, in FF your character generates a number between 0 and 255 based on factors such as strength and accuracy. I currently use a specific algorithm for magic to determine effectiveness based on character INT and spell power. Basically proficiency would be a stand in for spell power for melee attackers and allow them to have a similar rate of increase for their skills. One of the issues I'm trying to address is that FF like most RPGs and especially those of it's time are very linear progressions in power. While it's definitely cool to find a new sword or upgrade your armor, relying solely on this activity does not make for compelling turn-based combat. As I said in the opening, I want the game to look and feel much the same to the player while still redefining the underlying characteristics to produce a more adventure-focused adventure, and combat-focused combat but those things will be saved for another day.
 
Last edited:
I love all the changes you are working on, I think it will make a more compelling game for people (old and new) - while at the same time retaining the core parts of what fans of the original FF loved.
 

Hyomoto

Member
@DividingByZero - Something I didn't really mention in my rambling is that I'd like to move away from levels being your distinguishing factor for power and instead push that into readiness. You know how sometimes you'll be playing a game and you get a thing, like maybe a fire resistance potion and so you save it? Forever? Because you want to wait until you really need it, but even if it could have been useful, you still didn't use it to save for later? I'm trying to find ways to make gear useful in the moment, and encourage the player to think about their adventure in terms of preparation and execution. The way FF breaks up it's magic into tiers actually helps combat this already: you know casting AFIR won't prevent you from using CURE later, for example, so if you need it you're more likely to use it. Something else it does well is dungeon length, generally short and brutal. So yeah, using these sorts of things I'd like to flesh out the classes a bit more by distinguishing why you'd bring them along to begin with and the advantages and disadvantages that comes with their presence and absence.
 

Hyomoto

Member
Something I've mentioned before is I wanted to externalize my databases so that they would be a bit easier to work on. Right now everything is just hard-coded into the game itself, which works out fine and is in many ways more manageable since it doesn't require the extra work of writing, say, a loader of any kind. But, thanks to a little inspiration by another member I went ahead and just wrote myself a simple database loading routine which will allow me to externalize the databases. Now, the big thing that I wanted to accomplish with this is the ability to make the data a little bit more manageable than it has been. The issue is, I might decide there is something I want to to do later on and having to back port those changes to every item can be particularly annoying. The way I was getting around this before was to use macros or enumerators to define the memory location for each value. What I'm doing here is not really that much different except that I don't have to manage it at all anymore, and I'll just let gamemaker handle it. The first thing I needed was a way to define what attributes would make up the entries in the file to be loaded:
Code:
ATTRIBUTES
NAME, TYPE, MATERIAL, CLASS
ENTRIES
SWORD,1,1,3
END
I'm super lazy, so that'll do, but it should be pretty easy to see what's going on here. At the time the entries are loaded, it will assign the values according to the attributes. So the first entry will be NAME, the second TYPE and so on. The issue is, I'm lazy. I really, really hate typing and I spend more time coding things to make me have to code less than anything else. The irony is palpable. In engine I would do something like this:
Code:
var NO_SPECIAL    = enemy_class_none + element_none;
var EL_NON    = element_none;
var EL_LIT    = element_lightning;
var EL_FIR    = element_fire;
var EL_ICE    = element_ice;
var EL_EAR    = element_earth;
So that as part of the items I wouldn't have to type element_none, or element_ice + element_earth. I could just type EL_EAR. And for entries I use a lot, I would just combine them. This works fine in engine but obviously a text file has no convenience features like that ... or do they? I decided to take this functionality and add it to loader. This meant adding a new table of data, a definitions table if you will since all I'm doing is defining data. So first off was to make a list of what I wanted it to do. I've become very accustomed to using hexadecimal when dealing with numbers because a lot of them are flags, and I definitely wanted to keep this behavior. So I needed a way to define both numbers and hexadecimals. I have a lot of experience working with this type of stuff and so I just opted to have a special character indicate the value type, in this case # for integers, and $ for hexadecimal numbers. However, converting a string HEX to a number is a slow operation and I also like to improve quickness where I can, so I also included a < character which represents, quite literally, a bit shift operation. Since most flags are just 1 << some number of times, <1 is equal to 1, <2 is 2, <3 is 4 and so on. These are all the common number types I'm used to using, but this is all just part of the definitions table. I obviously need some way to indicate that the value comes from this table, and is not just a regular string. While thinking about this, I noticed something. If you look at my NO_SPECIAL above, it's the product of two values. While I could define it as 0, which it is, I wanted to incorporate this functionality into the definitions table and allow DEFINE entries to also reference themselves allowing me to combine flags if I want. Of course, I couldn't stop there because why? So basically you can now make a definition table that allows referencing and combination of definitions. In the above example it might look like this:
Code:
database
ATTRIBUTES
NAME, TYPE, CLASS
DEFINE
SWORD        $001
IRON            $100
FIGHTER        <1
KNIGHT        <2
CLASS_FI        :FIGHTER + :KNIGHT
END
ENTRIES
SWORD,:SWORD + :IRON,:CLASS_FI
END
I might get around to writing an editor at some point so I can even further reduce the amount of hand input I have to do, though found I can kajigger microsoft excel to output these entries for me, which means I can store this all in table form to make it even easier on myself. But the short of it is that I can now store my databases externally, and even make changes and load them in without having to restart the program. That's it for today's update. If you love dry technical details, there you go! On another note I went back into the characters and added the ability to define a sprite in layers and color each layer individually. This was mostly done for sanity as characters, such as the party, used to have to be saved as all combinations of their colors, but now hair, skin and clothing can be defined separately which removes an arbitrary limitation. Oh, and the excellent @2DKnights was kind enough to donate their impressive skills to updating the Fighter sprite, so I'd be remiss to not give a peek of what that looks like:
 

Hyomoto

Member
So in my last update I talked about writing an external database. Well, since I've never been one to be content with doing things the easy way, I went ahead and started work on a database editor. Basically, the files can be edited in plain text but the more I thought about it the more I realized that the definition libraries don't really need to be part of the game. This is just a convenience feature I wanted because writing the databases by hand is tedious, even if easier. Or to put it another way, it's not that much of an improvement over how I was doing it other than it can be reloaded during runtime to test out changes. That last part is awesome, but I'd like a bit more control. I may have mentioned this before but I spent a couple years working almost exclusively on UI stuff. I don't reckon that makes me very good at it, but it does make it a lot easier for me to tackle given that user interface isn't exactly a really easy thing. It's one of those aspects of development that seems to get 'last pick', so generally it's ignored in favor of things that are awesome and fun. That said, I'm a bit of a stickler for a good, usable UI that doesn't suck. And one of those aspects means trying to create a consistent experience throughout, I wrote the program but it should be relatively easy for someone else to figure it out. The gif cut out while I was recording, because GifCam can be weird sometimes but here's a gif showing off some of the interface functions at work. I'd say I'm about 50% done with it, but it's about 90% to being usable. Basically, it can read and save database files, as well as add, edit and move entries. However, you cannot actually edit the definition files inside of the program right now and you cannot delete entries. While you can do this with a text editor, I'd like to application to be a complete solution. Here's a short gif of it in action, GifCam cut the demo short, but it now supports all the features I need it to including flags, lists, texts and numbers. The whole goal is to make this much easier for me to view, edit and add to and to that it's a resounding improvement of writing it all by hand.

Sorry about the size, I didn't bother writing display scaling into it, so it's 720p.​
The whole goal is to make it easier to edit in-game data and while I haven't started using it for this purpose, as that will require me to export the old databases, import them into the editor and convert them into the new format, this will make it much, much easier to work on them. Basically it stores databases in two formats, compiled and raw. The compiled databases are what the game uses and it strips out the definition tables and finalizes the values. The raw databases contain a lot more information and are basically the backbone of why this is possible. You can see as I mouse over values it will show the 'finalized' values, while it normally displays the non-finalized values. I know most of you are probably hoping to see the game start to come back together again, so this might not excite you but we'll see if I can't get something more interesting into the next update :D Until next time!
 
Top