• Hey! Guest! The 36th GMC Jam will take place between February 27th, 12:00 UTC - March 2nd, 12:00 UTC. Why not join in! Click here to find out more!

Alpha Final Fantasy for NES [PC/MAC Demo]

Hyomoto

Member
So, today was a relatively eventful day. I started out with the desire to start going on the battle system. I haven't put many updates up about this recently and it's probably something I'll discuss in another update sometime. The short of it is there is a particular idea I've had bubbling around in my head for a couple years now. It deals with encounter rates, party leveling, enemy threat levels, equipment limitations, etc... basically it's a beast. For the sake of simplicity here today the idea comes down to how the party loses HP over time. There are a lot of ways to deal with this, but my least favorite (and coincidentally the most popular) method is some sort of hit points that, upon reaching 0, lead to your demise. You simply scale up and away and eventually you hit this sort of invulnerability ceiling. WoW or really any other MMO is a pretty prime example: a level 1 character could never hope to defeat a level 50 character by virtue of the numbers. You attain a sort of casual invincibility and personally: I don't care for this.

So basically I've been toying with the idea of three types of hit points, short term, medium term and long term or Health, Stamina and Injuries. At the end of combat all of your health is restored, this represents your characters sort of natural athleticism and endurance. Stamina on the other hand represents the gradual wearing down of your character over time just due to exertion, it is recovered via resting or some items. Injuries are a long term issue and represent significant afflictions that are not easily remedied without treatment, these can only be healed at clinics or via powerful magics or items. The idea is, when your party leaves town they are fully refreshed and at their peak condition. As they adventure and fight, they wear down, sustain injuries and, if things progress far enough, eventually succumb and die. At a mechanical level when your injuries surpass your health, your character dies. As a character recovers all health at the end of a battle, they can be close to death in one battle, but largely well the next. As injuries mount, that distance between health and injuries narrows and the chance that any given attack could be fatal becomes more and more likely. The other aspect of this is stamina which increases the likelihood of attacks being successful in the first place. The end result is basically that the more injured and worn out your character is, the more likely that future attacks will be damaging, and the more damaging the attacks, the more likely that any of them may be fatal. In the end, the goal is to move away from a system of 'I have X hit points until I die', and have the player consider more strongly their actions in and out of combat, including whether or not they even want to engage in combat. This doesn't fully do away with that 'soft invincibility', but a lucky hit by you or your enemy could cause damage. In the right circumstances it is 'possible' for even a level 1 character to beat Chaos (even if the likelihood is only superficially not zero), or likewise if you party is beaten down and injured, a lowly pack of Imps could do in a seasoned party. Obviously weapons, armor and training make this all less likely but the important part is that combat becomes a situation, something you consider and deal with. There are soft penalties for

As I said, I wanted to work on that today and maybe get some form of it up and running. Unfortunately I did not make it even half as far as I'd hoped due to running into a number of issues with the engine. Namely, I discovered that the method I used to increase FPS during scene compositing meant I'd lose ALL those gains whenever the 'color shift' effect played. Whoops! Fixing that required me to basically do some more layer slicing and change when the scene is colored. This did come at a performance cost but overall the method is still significantly faster than the original engine used. As a side effect I decided to hook it into the screen transition logic which allows me to use it the same way I do wipes and blanks, as well as combine them all together into crazy combinations I'll never use.

This is my attempt to recreate the Super Mario World end of level effect. Just think of the tune while you watch it.​
After doing that I realized I hadn't built in the ability to handle scene transitions. This is something that a specific object did before, but with the new engine I rolled up quite a bit of functions into what used to be the main render. Now I just refer to it as the 'scene helper' because it handles transitions, camera work and visual effects. The old system was hard-coded, which meant I had to call a specific branch to do something. This meant any time I added something to the game that required a transition, I had to code myself a new one. Naturally some of them could be reused but that's just not powerful enough! So I put together a system by which I can define a series of actions, this includes screen transitions, changing rooms, creating objects, playing music, or even changing variables. This took a few hours to get up and running and eventually revealed several previously hidden bugs. So cool, all that got fixed, new functions got added and finally, FINALLY I could work on the battle system!

Well, not quite. The problem with doing what I'm doing is now I have to look at what I have and decide how that information should be conveyed to the player. At it's core I'd still like the game to look like Final Fantasy and evoke that feeling, even if the underlying systems are extremely different. This requires me to prototype and come up with concepts and iterate and well, that just takes time. Still, I was able to get a rudimentary battle scene up and running and even the basics of the battle logic laid out. As I said, this is hardly final but if you'd like to comment on what you think, do feel free. Anyways, I said I'd try and post something game related (and by association work on something game related) so instead of boring databases and spreadsheets, here's some actual screenshots for you guys. Until next time!

Prototyping a few concepts here. It lacks that 'NES' feel though.​
 
Last edited:
N

Necavare

Guest
This looks really cool. I would love to get into the final fantasy series sometime. Sorry to say im not much of a fan of final fantasy. However, I really like what your doing here. I love the people that are taking these old games that are riddled with bugs and other broken mechanics and fixing them. One thing I have to suggest is that when I play the game it starts to use a lot of my cpu. Im not sure if you have focused on the side of optimization yet, but I think you really should. Ill definitely be playing this sometime though.
 

Hyomoto

Member
This looks really cool. I would love to get into the final fantasy series sometime. Sorry to say im not much of a fan of final fantasy. However, I really like what your doing here. I love the people that are taking these old games that are riddled with bugs and other broken mechanics and fixing them. One thing I have to suggest is that when I play the game it starts to use a lot of my cpu. Im not sure if you have focused on the side of optimization yet, but I think you really should. Ill definitely be playing this sometime though.
The latest build of the engine is considerably more optimized, so hopefully! In fact, it's the reason I started over: the old render was okay but didn't scale well and, as I feared, some people had lag and such. The new engine is much, much faster.

But, to help me out, can I ask what your specs are?
 
Prototyping a few concepts here. It lacks that 'NES' feel though.​
I like this concept, and it still keeps the NES feel (to me at least). Though, not having actual numbers will make it harder to judge health... but I like the idea of the red bar and status name, it looks really cool.
 

Hyomoto

Member
I like this concept, and it still keeps the NES feel (to me at least). Though, not having actual numbers will make it harder to judge health... but I like the idea of the red bar and status name, it looks really cool.
I played around with it a bit more to get this:
Which is more FF2 inspired. That said, and without covering it in detail here, it's because the way damage is calculated is not a strict number that makes sense from an observational standpoint. You can die at 0 health, or 250 health, or 500 health. It depends on how injured your character is, how low your stamina is, how effective you armor is and, yes, how high your health is. The calculation looks like this:
The system is still being tweaked so please take this with a grain of salt, but to explain it quite simply, essentially you generate a roll between 0 and ~255. Based on your current condition, a 'threat' band is created. A critical hit will cause an injury, a normal hit damages health, a graze only does half damage to health. Your character dies when their injuries exceed their health. So, how much 'health' you have is ... a bit abstract. I suppose I could show the difference between your health and your injuries, which is a relatively accurate depiction. I dunno, still playing around with it. Feel free to weigh in :D
 
Last edited:
Ah, I see - the HP isn't a clear number like originally. I think I like that too - but, I need to think about it a bit to be sure.

So, here is my thoughts on that method - and please don't go and change anything yet, I am just talking it out.

In the original games, as you progress - the main thing you can 'feel' as you get stronger is how hard you can hit (how much damage) and how much health you have. Is there still going to be something that gives you that final 'feel' of your progression if your health is more of an abstract number? For example, if the harder enemies only take a 3% percent of your health bar per hit, how will that be seen as a more difficult enemy than the first wave of imps who might do the same 3%? I know in the original, it works out the same way, percent or real numbers - it is the same idea. But, there was something about doing high hundreds like 700 (or thousands in later games, 9999) vs doing just 20-30 damage when you were low level.

Again, I think I like the direction you are going - it makes the whole system way more interesting than the original. You just need to make sure you can feel progression in the game, that the later enemies are bigger and badder, hit harder. If there was a lot of going back and forth to areas, I think it would be obvious - but much of the game, you don't really go back to the first areas and see the easier enemies. I mean, there is some, but not a lot.

Anyways, my two cents - take it with a grain of salt too... o_O
 

Hyomoto

Member
@DividingByZero - Technically, 250 health and 0 injuries is not the same as 300 health and 50 injuries, though I'm not sure the distinction is important to the player. So I might just go this route with it. While reaching 0 health will kill you, injuries are more dangerous in terms of survivability. So injuries aren't just 'permanent' damage (health recovers at the end of combat), they also represent an overall reduction in character capability. So yeah, I'm not sure '250' accurately represents that though it is a good starting point.

As for the progression stuff, I'm still working out the details but right now leveling only affects your max health and stamina. What I'd like to do is entirely discard the traditional experience based system and go to a dynamic system like you might find in the Elder Scrolls games. Part of progression is currently proficiency, where as you use weapons and spells your characters grow better at using them. The stronger the enemies or more powerful the magic, the higher you can raise your proficiency. The second part is the weapons themselves. Right now weapons provide the expected attack bonuses but they also have a material, type and effectivity. Your proficiency and weapon effectivity provide a limit on just how effective it can be. No matter how skilled or amazing you get with a dagger, for example, there is a upper limit to how much damage you can do with it. Conversely no matter how good the dagger, unskilled hands gain less, if any, benefit. At least base severity. The bonus severity is the total attack proficiency minus effectivity divided by 4. That means for every 4 points over your attack does an additional bonus point. This is where your 'primary' attribute comes in, in the example above it's strength, and having a high strength, in this case, provides a 1.33 bonus, which means your attack is 1.33x higher for purposes of calculating the bonus. This allows items to have a more natural implementation in the game: specifically, a weapon isn't 'inherently' better and mindless upgrading of your equipment is expensive at best, pointless at worse. Specifically, a Black Mage may see absolutely no impact switching from one knife to another because he can't really maximize the potential of his weapon (without training of course). It's like giving someone a gaming mouse: unless they are a high end competitor who is bumping up against the limits of their hardware, they are unlikely to see massive, if any, improvements from utilizing 'superior' options. The Fighter on the other hand, thanks to a combination of factors, is able to get the most out of many types of weapons, at least ones with strength as a primary attribute, because his ability is higher but he's also uniquely fit to use it: given the same proficiency with a mace, for example, the Fighter is likely to outclass any other character due to his superior strength. The same goes for armor, you can hide your Black Mage under steel plates, but their low stamina means you'll tire them out faster. The Fighter is less burdened by the armor and also has a bigger stamina pool, but given they tend to do more melee combat this means in some cases, less armor is more. It's important to size up your enemies and equip your party accordingly.

Still working on fleshing everything out of course, but progression should be based on player knowledge, preparation and, of course, time invested. I just want to move away from it being entirely time based, and try to put more emphasis on the importance of combat and the wearing down of a party over time. That way when you go to the marsh cave it isn't just a gauntlet of terrible enemies, it's a test of preparation of fortitude.
 
Last edited:
N

Necavare

Guest
The latest build of the engine is considerably more optimized, so hopefully! In fact, it's the reason I started over: the old render was okay but didn't scale well and, as I feared, some people had lag and such. The new engine is much, much faster.

But, to help me out, can I ask what your specs are?
Windows 10
RM750 Corsair PS
16gb ddr4 ram
2tb drive + 250gb ssd
Intel skylake 6700k i7 4ghz
Amd radeon 480 graphics card
 

Hyomoto

Member
I figure since I've been talking about it anyways it's probably best to give a better overview of what I'm working towards with the game. In the original Final Fantasy there is a very linear power curve to how you progress through the game. Given the nature of XP and the like it is possible, even if not enjoyable, to max level yourself before you ever make it out of the starting area. This is just one of those things that plagues RPGs, but that linear progression in power that you earn from fighting Imps seems somewhat ridiculous, as if fighting small woodland creatures somehow prepares you for fighting skeletons, dinosaurs and even a Kraken beneath the sea. I just don't see the overlap. Sure, maybe you learn to use your weapons and magic and that can help, but literally speaking eventually all you are doing is learning to fight Imps, there is an upper skill cap on how much they can teach you.

And that's sort of the backbone of a lot of the types of changes and ideas I'm prototyping right now. It's not impossible, or even particularly difficult to make a more thoughtful RPG, but it does take time to consider, plan out and test how various systems are going to work together to achieve a desired goal. Slapping an XP requirement on your next level and scaling enemy XP has generally been a way to control progression: if you find the content too hard you can stay back and grind a few levels. The issue, however, is that this really isn't representative of player skill. Anyone can hang back and grind out levels, including people who are 'good' at the game. It isn't a handicap for 'casual' players, it's a crutch for everyone. More importantly it isn't fun and it detracts from the experience: is grinding really an activity the player should want to pursue? Or more specifically: is grinding for XP fun? Maybe. As @DividingByZero pointed out, progression in RPGs is largely tied to the power your party attains through the battles they fight. This is definitely true and not something I want to do away with, in fact that's pretty much where my current impasse is. How do you remove the rewards from combat such as XP and gold and still ensure the player will want or need to fight some battles?

My current solution isn't all encompassing but the short of it is that I'm not doing away with all forms of XP, though I am doing away with gold for the most part. The idea is pretty simple: being able to grind out gold from enemies largely trivializes the gold you earn from exploring and doing quests. First on the table is doing a sort of loot table for enemies which really just boils down to most of enemy possessions are junk from an outside world perspective, but sometimes they do have things the party might want: items, weapons, gold. Whatever, and you can rummage through their belongings when you complete the battle and take what you want. As I said, most monster possessions are worthless to the wider world, but some things may be valuable to some people and provide a more exploitable way to make money, but you won't just be picking gold up off the corpses of your enemies. As for XP your characters do earn proficiency as well. For weapons what you earn is limited by the level of your enemies, thus you'll never become a master swordsman fighting Imps in the woods but you can get pretty damn good at killing Imps in the woods. For spells, it's limited by the level of the spells you cast. Again, you'll never master the arcane arts of MEGAHEAL because you got real good at casting CURE. So using your weapons and spells matter, and depending on the magic you'll need to be in combat to use it. Additionally you do earn experience which directly improves your health and stamina, sort of akin to working out. The higher your level, the harder you have to work out to improve. That hasn't changed, but the effect that a single or even handful of levels has is reduced over time. There is a benefit to maxing out at 50, but the difference between 40 and 50 is about half that of 1 and 10.

And lastly, there is another idea I've been playing around with: threat. Essentially when you begin the game the world is in trouble: the seas have gone placid, the winds have stopped, the earth is rotting and the sky has darkened. The animals have become violent and monsters are now attacking. The world is unpleasant to say the least. So what impact are your heroes actually having? Well, the impact I'd like them to have is essentially the more you fight in an area such as a dungeon or region of the world, the less dangerous it becomes and the fewer monsters that actually appear there. Every region has something or someone who is contributing to this problem, and defeating them will also reduce the threat level of the whole area. As an example, the Kingdom of Elfland is being terrorized by Astos. As fight in that area you thin out the monsters, but once you've defeated him the whole area becomes safer. Thus there is a benefit to fighting. Trying to grind your way to the Marsh Cave may be quite difficult before you've taken down some of rabble around the city. In this way, running also comes with a sort of penalty. Yes, you avoid combat: but the threat level remains unchanged. To be honest I'm also playing with the idea of a 'soft threat', in that the more battles you fight the lower the threat, and running away from battles raises this threat, but in this case it's always trying to return to 0. So if you run, threat is temporarily increased (ie: you are being chased) and if you win, it's temporarily decreased and instead major milestones will decrease the global threat.

And lastly, to go along with all of this and sort of diversify the classes a bit I'm doing away with the flat scaling that the original game used for attributes. As I've talked about before, most of the stats don't do anything, or do very little. Strength and constitution do the most and the Fighter gets the most of both of those, which is why the Fighter was the strongest class. Instead I'm currently using a 6 attribute 6-18 system of strength, dexterity, constitution, intelligence, wisdom and luck. To give an example of the type of difference an attribute makes, at 6 constitution a Level 30 hero would have 125 health. At 18 constitution they would have 536. The benefits of a system like this is that items or events that improve, or reduce, attributes are more striking and important. And this stuff compounds, so if your Fighter is hit with a debuff that reduces their constitution, it has a lot of effects. Not only is their max health lower now ( their current health is unaffected ), the size of their threat band increases. To a Fighter, their larger pools of health and stamina, and higher engagement count is what allows them to stand at the front and trade blows. A single point lost in constitution can represent up to a ~6% increase in their chance to take damage. For someone like the Black Mage, they are generally vulnerable to begin with and use characters like the Fighter in lieu of their defense, so losing constitution isn't quite as bad for them. The same could be said for intelligence for the casters: their magic potential is largely affected by their intelligence. While the fighter can take a ding to intelligence with little, if any, consequence, for the wizard that can be a large drop in the chance to apply a status effect or a reduction in damage.

So yeah, there's my ramble for today. Hopefully that gives a decent look at the sort of overarching ideas I'm working on right now. As always comments are welcome and until next time!
 
I am totally on board with all your ideas! It sounds like you have a good plan and it should make for a very interesting take on the game. I look forward to seeing some of these ideas come to life. I love the way skills are built in the Elder Scroll games, I think it will make this game even more exciting.

I am also a D&D player, so having stats fluctuate and potentially cause your harm or bonuses based on your class is great!

I also really like the idea of areas becoming 'safer'. It almost makes me think of Act Raiser (if you have played) - where you basically have to clear out an area of all bad guys to progress. To expand on that idea, it COULD be interesting if the areas you previously cleared out has the potential for new threats to come back, maybe at random or gradual (maybe when you aren't there, a threat percent is slowly building up... until it explodes to needing the heros again)? Or take it a step further and maybe you can help areas build defenses/armies by providing resources? ... ok, maybe some of this is getting crazy... but fun to dream.

What is your plan for enemy progression? Will they be static to their area (like original) or level with the character? You reference Elder Scrolls as your inspiration, but Oblivion did that part wrong. The way they handled enemies, it caused you to almost lose all sense of progression due to nearly the entire world leveling with you. Meaning you can go anywhere at level 1, the enemies and everything else match a level 1 character. If you go back to the same place at level 50, it matches you then. You could pretty much beat the game as a level 1 character if you wanted, due to this mechanic. It was still a great game, but I always thought that was a flaw with it. I feel like there needs to be those moments where you go somewhere new and you realize "****... I am not ready for this..." because some giant ogre (or something) slaps you around pretty hard. - I am not sure if you are planning for your enemies to work in this manner, so this whole point might be irrelevant.

Keep on keeping on, man! - I am digging the fact that you are blowing it apart into a new system.
 

Hyomoto

Member
@DividingByZero - Full disclosure: I have played all of Bethesda's games and I have enjoyed them for what they are. Daggerfall specifically was well ahead of its time, and the Daggerfall Unity port has me excited. However, starting with Oblivion at best they would top my list of 'meh' and generally reside much lower. The core problem with those games IS the leveled content, as you have so directly pointed out: you can go anywhere at level 1! That's not wrong in and of itself, but the fact the game actually gets harder as you level is counter intuitive and makes leveling and upgrading your gear wholly unsatisfying (not to mention I hate their art direction since Oblivion). So no, I will not be doing that. I prefer Dragon's Dogma or Dark Souls: you can go there but good luck. An interesting part of those games: even 'under powered' heroes can succeed because the game takes into consideration your skill. I have toyed with enemies having some variation but honestly I don't think it's needed. In fact, I'm trying to 'temper' the randomness in the game to avoid that XCOM-style feeling where you get punished because of bad luck, not poor preparation. I want the difficulty to stem naturally from the abilities and composition of your enemies. For example, a pack of werewolves would be a death sentence without the aid of some magic or silver weapons, or slimes that can dissolve your weapons and armor must be confronted properly. However, either of these could prove frustrating if left up entirely to chance. I don't have a specific answer for that yet, as it will tie at least somewhat into the threat system. I've considered using preemptive attacks to represent catching the enemy unaware, in that it allows your party to choose whether or not to engage but basically, I'm trying to find a way to combat 'random battles'. I really want the player to have more understanding of when and where combat can or will take place but I haven't come up with a good idea yet. Surprise attacks are fine, but despite what the game says, in most jRPGs ALL attacks are a surprise.

As for your comment about being able to reinforce areas: I have considered this. My thought on the subject was that the heroes show up, reinforce the town, confront the boss and 'free' the area. In fact, I've gone so far as to code in the ability for, as well as consider, the ability to have more than four members in your party. And the idea would be that you could leave some of them behind to help guard the town and for training, and upon freeing an area there would be a few potential candidates to add to your party roster. I don't think I'm going to do that, at least not initially because I do like the idea, and am mostly focusing on the big items I've already laid out.
 

Hyomoto

Member
Right, so today's update is kind of small because I want it to be. I did a lot of visual work today, which is a prime target to put up a GIF or a video or something like that but this is what I've decided to provide.

Just noticed there is a bug in this picture. It isn't supposed to draw a 1 when there is only a single enemy of that type.​
So, today I mostly worked on finally consolidating all of the battler draw effects. In the previous engine, all battlers are a single sprite, so manipulating them is super easy. However, thanks to trying to do things better and the fact that your party now has multiple layers (you can choose clothes, skin and hair independently now), this would've been a headache. To top that off, the draw code was divided between animated battlers, your party, and the enemies. But the thing is, there's nothing stopping the enemies from being animated. I do not intend to animate them, the point is simply that that I want all of the battlers to be dealt with in the same way. I watched @Fel666's stream yesterday and one of the very important things he seems to focus on is ensuring that he reduces code redundancy and maximizes object flexibility. This is something I also like to do but the drawing of the battlers are a place where it wasn't done very well and I set out to fix that today. The short version is that I've re-implemented all off the various effects needed to animate the battlers including the hit dust, flashes, blinks, shakes, and movements. To go along with that I also wrote a bit of code that sorts the enemies by their 'level' and size. In the old engine each formation of enemies had to be specified in a very specific way or it would break formations. Now I can throw an arbitrary group of enemies at it and it will just figure it out. Additionally I spent a little bit of time working on the interface to make it more Final Fantasy like as well. As @DividingByZero pointed out it was not, and after playing around with it I think one of the strengths of Final Fantasy is it's simplicity. Even though the backbone is more complicated, the interface does not need to be. So I went to a nice simple 'HP' readout and the enemy names. I'm trying to make the whole experience less busy so that means doing away with a lot of the visual noise and using more direct visual language. For example, when you hit an enemy for damage it will use a damage floater instead of a message window. I'll also be going to a description based system to add some intensity, hopefully, loosely inspired by various MUDs and the wonderful Steve Jackson's Sorcery games.

Besides that I did a bunch of background work. The game is entirely data driven so it's pointless to work on code without the data it needs. However, when I was designing the first engine I went with a sort of 'direct injection' of code into the game which meant I had to unravel it later on. So a lot of work is stuff that basically props up everything else I talk about, the quiet and unsung lines of code. Oh, and I added rudimentary mouse support. Right now only the debugger uses it, but the information is exposed to the game now. Not a bad bit of work for the day. Until next time!
 

Hyomoto

Member
Another quick update. Something I've been working on for quite a while in regards to game maker is coming to terms with an internal resolution that is different than a screen resolution. GameMaker doesn't explicitly handle this type of behavior, rather relying on some basic scaling and there are some issues here and there with that. Console games almost universally adhere to a 'safe space' in which you can place HUD elements and the like to account for varying standards in television sets. Back in the NES days there were 16 pixels at the top and bottom of the screen, as well as 16 to the left and right that were a reserved overscan area. It's why when you play these games in an emulator you can often see 'odd' color bands and other strangeness. Anyways, long story short I've been trying to find a way to scale the screen effectively within a varying window size. So today I did a little bit of work to update how the resolution is handled in game, and here's the game at it's original 256x240 resolution running in a 640x480 window:

4:3 in all it's gloriousness.​
The importance of this is that the SCANLINES are being drawn at a 640x480 resolution, and are therefore 'accurate', while the graphics are at 256x240. I also left in some of the 'mouse' code so you can see me pointing at an Ogre. As I said, right now this is for debugging purposes since I can say, delete this Ogre from battle or adjust his HP or whatever, but that also means that click on the Ogre for your target would be a very, very simple addition as well. Most importantly is the mouse cursor is normalized to the internal resolution which means no matter the size of the window, it will still work. In fact, you can actually step DOWN the resolution though I don't know who would be playing in a smaller than 256x240 window. The most important take away is that the internal resolution is divorced from being rendered to the back buffer. And most amusingly, the scan lines will be drawn to the screen resolution rather than the window size.
 

Hyomoto

Member
I've mentioned this a few times but here's a proof of concept. There's a lot of work that goes into controls in general, so it's not as simple to just say "I'm going to add mouse support to a game that traditionally uses a controller." That said, I do have a bit of experience with this thanks to an over engineered, but ultimately quite fun, Tetris clone I did a while back. I have had rudimentary mouse 'support' in the game for a while, but originally it was part of the debugger. A little while ago, and I believe I mentioned this somewhere, I went ahead and moved the code into the controller object, where it belongs, and exposed those values directly to the engine which means that anything can use it. At this point some might wonder, "What's the big deal? Mouse controls are super easy." Well, because of the way my game is rendered the built-in mouse_x and mouse_y variables are not accurate AT ALL. They have to take into account both the size of the window and the aspect scaling of the screen especially if overscan is involved. It's not hard, but it has to be done. Next, depth sorting and having the engine figure out not only what object you are pointing at, but if they overlap which one it should be is a helpful addition. And finally, I went ahead and implemented logic for mouse clicks, holds and double clicks as well. Honestly, this is all pretty basic stuff, it's all pretty easy once you know how to do it or even just what you want it to do, but it has to be done to get a reasonable useful mouse system in place.

However, that's really just getting the mechanics of using the mouse in game. The way that the controller functions is not so different than the mouse in that the game will tell it which object is currently using it. This prevents multiple objects from responding to controller inputs and that being the case, it's actually then pretty trivial to finally add mouse support in. In this case I've hooked it up to the menu object which requires just a few more additions. The first is it's not really good enough to know just that the object is being pointed at, you have the define the area in which the menu options are displayed. That way, ideally anyways, the options are only selected when the player points at them. And lastly there is one more quirk I chose to address and this falls into that category of what I like to call, "Giving a **** about player experience." The big mistake, in my opinion, that small games tend to make is they avoid small, quality of life improvements. These fall largely into the category of 'things people don't notice unless they are missing'. In this case, if I were to just calculate the menu item based on the cursor position it would cause an issue where when the player is pointing at the window, the controller would no longer respond. It's not that the controller stops working, it's that the mouse is overriding the controller behavior. So the last thing I needed was to track whether or not the mouse has moved, and only update the cursor position if it does. Anyways, here is the result:

Also a little preview of the current status screen prototype.​
 

Hyomoto

Member

I have no idea why the recording is so fast.​
It seems like a lot of my background tasks are finally starting to pay off. I fixed some inconsistencies with mouse controls and then started working on consolidating movement. In the previous engine something that always drove me nuts is movement for the player and NPCs was largely identical but a separate routine. This was mostly because I didn't want events to be able to trigger each other, obviously only the player is supposed to be able to enter buildings, loot chests, etc... but it also meant keeping two code bases updated which is a pain. So, to fix both issues I implemented a way of handling triggers that is called from the triggerer, and it knows who the triggeree is. Because of this it's possible to ignore the event easily so if NPCs walk into the inn it doesn't trigger a scene transition. However, this also means I can define another event such as having them actually walk into the inn. Not using this right now, but it's a nice platform later if I want to use it and means I can finally consolidate movement for all actors. Now the only difference between an NPC and the player, code wise, is that the player is basically an NPC with no movement AI.

After getting that up and running and putting in the rudimentary event handling for doors I decided I might as well give pathfinding a try. I've done it before, and honestly pathfinding isn't horribly difficult, but it's a case of making it work with how my data and events work. Fortunately the consolidated movement came through wonderfully, it turns out that the checks I already do for movement just needed to be slightly adapted to handle being called from any tile. Thanks to my previous mouse work, all I needed to do was hook up a A* routine and voila. I'm actually pretty happy with how this was implemented as well since it doesn't make use of a node grid like I might normally go with. Anyways, this accounts for around 90% of mouse logic needed so right now I feel pretty comfortable saying it'll probably be an option.
 
Last edited:

Hyomoto

Member
I'm still messing around with some ideas, and I started building the equipment screen and it's pretty much fully up and running ... the problem is I ran out of space. I really need somewhere to put a USE option, but unfortunately I just can't find a spot. So first off let's talk inventory changes to the game. In the original you have four weapon slots, four armor slots and a shared inventory. As you can see below I've decided to go with a four slots for equipment and eight slots of inventory for each character. The armor slots are 'general' which means you can equip anything in them though there are some restrictions. For example, you can wear a wooden plate and cloth armor, but you cannot wear a wooden plate and iron armor. You can wear a helmet or a hat, but not both.

I feel like this is self-explanatory.​
To avoid going into great detail but to quench curious spectators, armor is a little more dynamic now. First off, the weight of your armor affects not only how much you can carry, but also how strenuous some activities are. So loading your mages down with iron armor has quite a few drawbacks. Second, while all of your armor contributes to your defense, your equipment can also 'absorb' attacks. This reduces the severity of that attack, possibly even negating weaker attacks, but also reduces the durability of that equipment. A piece with 0 durability loses this trait and can potentially break, so strong foes can tax not only your characters, but your equipment. Given that certain weapon types also work better against certain monster types, having an extra weapon or piece of armor in your pack could be a valid choice, especially for those on the front line. The goal here isn't for you to add micro, instead it represents the wear and tear that adventuring causes and is another consideration. A few battles with imps isn't going to ruin your equipment, but a few hundred imps might.

You may have noticed your characters inventory is space limited, but also weight limited. Something that has always intrigued me, and should be somewhat evident from my earlier comments, is I'm at least partially interested in adding a type of 'survival' gameplay and to clarify I mean in the vein of something like Oregon Trail. Travelling from point A to point B is important, stuff happens. In RPGs like Final Fantasy this is combat. I've been toying with the idea of some kinds of randomized events besides battle, and I'll talk about that in a moment, but there's another aspect to that game that appeals to something I've spoken of before: preparation. The journey is as important as the location you end up, and I want it to be punctuated with more than just a slog of battles in between. The act of making combat matter a bit more does quite a bit by clearly and effectively demonstrating danger to the player and giving a better sense of progress and place. Areas of low danger and weaker foes feel ... valuable to traverse, whereas high encounter rates or powerful enemies carry a more pronounced flavor.

However, something else that I feel is important is scale. The use of smaller characters on the world map already gives a nice separation of scale: the world is big, towns are smaller. However, I'd like to take this one step further and also include a form of time. To go back to the Oregon Trail: you prepare your supplies and head out into a potentially hostile world, perhaps even with a destination in mind, and this is where RATION, TENT and CAMP come in. The world map is large and traveling around it takes time, some destinations may be days away. Where you walk affects your rate of progress so finding optimal routes can speed up, or even add safety, to your journeys. As I discussed before, every character has short-term health, medium-term stamina and long-term injuries but your party also needs to subsist on something: rations. As you travel your party automatically consumes rations, and as long as they are fed they will recover Stamina as you travel. However, even a well-fed party needs to stop every once in a while and this is where 'camping' comes in. You can set up camp most anywhere on the world map and while camping, your party can tend wounds, recover stamina, memorize spells and other actions. What is available, how dangerous it is, etc... is affected by where you choose to camp, but also what items you camp with. A TENT or CAMP will provide better results than simply roughing it.

Dungeons and towns, on the other hand, represent a larger scale of time and do not wear out your party to traverse. At least not in terms of food and camping. This is also where Inns come in as they are 'ideal' places to rest.

So your preparation includes camping, healing, equipment and even just left over slots for looting. The difference between exploring local and setting out into the great unknown requires a very different mindset. Things like TENT and CAMP are quite heavy and do not stack, and you must decide just what, and who, you will take with you. This doesn't just diversify the traversal gameplay, it also helps differentiate classes in more ways. Of course, as I said this is still just an outline and tweaking and changes will probably occur but that's what I'm working on. Something you may have noticed is I want to use portraits for the characters as well so, here's a picture until next time!
 
Last edited:

Hyomoto

Member
So, I was trying to get a mac build up and running and since my current project isn't game-worthy, I figured I'd go back to the original and use that. It honestly is in much better shape than I remember, and generally seems to work fine. So since I never released a final build of that, I've decided "why not?". And I'm making it available. The major features are it has the new dialogue system and the various cut scenes I talked about previously. So, if you wanted to have a look at what might have been, here you go:
Final Fantasy Beta 1 for Windows
 
Last edited:

Hyomoto

Member
Very small update today. After fiddling and fighting I was able to get a macOS build up and running as well. It's the same Beta I made available to Windows users. Just to clarify, however, I am not intending to continue this build. This was partly an exercise to get the game working on Mac as well as PC, and I thought it might be cool to release the work I talked about in previous updates but never ended up releasing. Maybe something to tide you guys over while I work slowly on the new design. I don't suspect this build will be exceptionally popular, of course, since macOS is still sort of the bastard child of GM, let alone gaming as a whole, but I do think it's cool to be able to provide both options. That said, if you are a Mac user and you DO try it, please give any feedback you have. I am not a Mac user, in fact I absolutely hate using them, so I guarantee there are platform specific things I have completely overlooked and have no idea about. You are my gateway to making my future work on the platform better. Until next time!
Final Fantasy Beta 1 for macOS

EDIT: So there's an issue. OF COURSE, there is an issue. For some reason when I download the file, and others, it says it cannot find the game. You can either run it from the desktop or remove the extended attributes to fix this but I've yet to find a way to prevent it in the first place. So while the build IS up, and it DOES work, I feel like I might as well pull it because it should 'just work' when you download it.

That said, I'm leaving it up since the Mac userbase here is pretty low and I'd be glad to help you run it if you are interested.
 
Last edited:

Samuel Venable

Time Killer
Couldn't someone just play the original game in an emulator and gain the same satisfaction? Is this meant to be a clone of the original game or are you adding some of your own content to make it play differently?
 

Hyomoto

Member
Couldn't someone just play the original game in an emulator and gain the same satisfaction? Is this meant to be a clone of the original game or are you adding some of your own content to make it play differently?
Maybe, sort of and yes. I prefer to play my NES games on NES, not in an emulator so for me it would not bring the same satisfaction. It was meant to be a bug-fixed, graphically adjusted, and at times different. However, as time went on I decided to start over thanks to some feature creep and problems in the render. Now, and you can scroll up and see for yourself, I am aiming to remake the game. It will look mostly the same, play similar but hopefully pay homage to its roots while still addressing some of the limitations of RPGs of the time.
 
Maybe, sort of and yes. I prefer to play my NES games on NES, not in an emulator so for me it would not bring the same satisfaction. It was meant to be a bug-fixed, graphically adjusted, and at times different. However, as time went on I decided to start over thanks to some feature creep and problems in the render. Now, and you can scroll up and see for yourself, I am aiming to remake the game. It will look mostly the same, play similar but hopefully pay homage to its roots while still addressing some of the limitations of RPGs of the time.
I know I have given a fair amount of feedback, but I just wanted to reiterate how happy it makes me the way you are 'remaking' this game. I love the original, and recreating it exactly was a commendable task for sure. I probably played it from beginning to end a dozen times as a kid. But, it very much shows it age, it has a lot of things going against it that make it not so great anymore. The things you are doing directly address many, if not all of the things I take issue with (now) in the original. I guess what I am saying is... thanks and keep up the good work!!
 

Hyomoto

Member
I haven't updated in a little bit because I haven't really gone far in terms of progress. In fact, I've sort of gone backwards. I took a few hours over the past two days to rewrite the render, again. Some of you might raise an eyebrow at that, but it has to do with maintaining separation between game logic and system logic. When I wrote up the new engine I consolidated a lot of functionality into a 'scene_helper' which handled the transitions, and the map display, and camera and etc... While this isn't horrific, something my time with TETRIX taught me is WHY THE HELL IS THE MAP PART OF THE SCENE HELPER??!? The thing is, GM is pretty unique in a lot of ways that it has this sort of baseline functionality that allows you to get a project up and running quickly and have graphics and sound with little trouble.

On the other hand, all GM really does is provide you ways to handle data. What you do with that data is up to you. So when I wrote the scene render it seemed natural to make it part of the room, since it is in a manner of speaking. But the way the render works is ... perhaps a bit bizarre. I'm not sure I've ever really touched on this but it is kind of unusual. When a room is started, each layer is given a script assigning it to a particular surface, and when draw time comes around those layers are drawn to those surfaces. These layers are then hidden to prevent them from drawing again. The world also has two sub-renders, the instance render and the system render, that also draw themselves to surfaces. During the draw end step, all these layers are composited together to the application surface to produce the scene. This is why the engine runs so much faster than it did before: it only draws the map once (and refreshes it if called or the surface is dropped from VRAM). The problem, if you will, is that that is the ENTIRE render and literally everything else draws to the system layer. This makes that layer .... a bit dense. The way I handled this previously is basically whatever 'scene' you had open had full run of that layer.

The problem is this creates a situation where everything is hijacking the system layer to draw to, and to make it more annoying the debugger ALSO has to hijack render. To compound that, something simple like: I dunno, hiding the map, becomes far more convoluted that it should. I should just be able to hide the world. The way TETRIX works is by defining 'scenes' and each one is basically it's own private render. Those renders are then sorted by priority and drawn to the screen. For example, the background is one render, the foreground is another render. This ensures there are no issues with overlap, and most importantly if I want to hide something I can literally just hide that render. So I wanted to put this in my Final Fantasy engine. The world render is a bit more complicated because it interacts with the room and handles two sub-renders, but what it really boils down to is if I want to hide the world, I simply hide the world render and voila. This also means that while everything else still shares the system layer, the way everything else is rendered is per it's own scene. The inventory is a scene, shops are a scene, hell dialogue could be it's own scene. And when you destroy or hide a render it takes all of it's children with it. In fact, the debugger is now it's own scene as well, making it completely agnostic and transparent to the normal render. Hooray!

That's what I did yesterday, and today I was reconnecting all the other stuff I worked on. Movement and mouse controls are working again, and I finally divorced player control from the player 'object' and moved it into the world render so that player control is also object agnostic. I also cleaned up the NPC draw pipeline a bit. After I put in the ability for the player sprite to be layered I had a lot of legacy code floating around, and I wanted NPCs and the player to share the same draw call. This means that any sprite can theoretically use palette layering, though it is only intended for the player character. I also killed all the legacy code and variables, some of which I didn't even realize were still floating around!

Last but not least, however, is I also did all this because I decided to throw all the menu work I've done in the trash. To explain the numerous problems would take a while but suffice to say my goal has been to have a solid framework to be able to easily add and change functionality in menus. In succeeded halfway with my first attempt here, but the problem was that while the parent scene handled HALF of the logic, the menus handled the other half and that was precisely the type of behavior I was trying to avoid. So since I had to throw all of that in the trash anyways, I decided it would be worthwhile to fix up the render as well.

Anyways, text update and sorry about that! I could post pictures but they'd be of stuff you've already seen I'm afraid! I'll try to have something more interesting soon enough! Until next time.
 
Last edited:

Hyomoto

Member
Today I got a chance to really sit down and get some work done, and I'm pretty happy with the results. Almost everything is related to system level code but the back end is finally stabilizing into something really, really cool and finally really starting to work the way I want it to. The updates for today are all pretty significant so let's talk about them:

The Controller - All inputs are handled by a controller object wrote it a few years ago. Since then it's been ported to GM2 and had small changes and additions applied, but what it does has largely remained unchanged. What it does is consolidate gamepad and keyboard inputs together to return a single value that can be checked. It's game independent and self-contained so it's one of the first things I import into a new project. It can handle button states, press, hold and repeat, and differentiate between holds and repeats by using & instead of ==. It handles the connection, disconnection and assigning of gamepads automatically. Something more recent is the addition of handling mouse inputs as well, tracking double-clicks and holds similar to how buttons work. In short it's a very robust object, very simple and requires very little effort to set up. However, it has always led to a flawed implementation. Generally only one object on the screen should respond to controller inputs at any given time, a problem I solved by simply having the controller track what object has it's focus. The problem is, objects just checked the inputs from the controller directly and this means every object, perhaps dozens, check if they should be responding to controller inputs. This adds some overhead, but more importantly when one object passes control to another, there is a chance inputs can overlap a single frame and two events will fire. There is a workaround for this but what I want is the controller to handle all controller logic, so there is never any chance of this happening.

This creates a problem: like I said, the best part of the object is it can just be dropped into any project and work. Adding game code to it would break that. Today I found a good answer to that conundrum: the controller already keeps track of which object has it's focus, rather than having the object call it's own code in a step event, the controller will call a user event on the object. This means if the object has no controls, nothing is called, if the object has no controls but a parent does, it will inherit them, and lastly the object itself doesn't actually call the code at all: the controller does, so there is no overlap. Anyways, I've considered releasing this object as an asset on the marketplace for some time but this is the first time I thought it might actually be worthwhile so who knows. For now, it's in my project and I'm super happy with it.

The Render - The render got two major improvements, the first of which was making the render frame independent. This is boring so I'll sum up and say the program can run at any frame rate and everything will work, yay. Combined with the new render methods and the divorced internal and external resolutions, this is by far the most capable and interesting engine I've built to date. I also did a cleanup of the scene event handler to more logically arrange it's actions. For example, to set a wait used to be WAIT_FOR_TRANSITION and WAIT_FOR_TIMER. Now you simply call SCENE_EVENT.WAIT and pass whether it should wait for the transition or the timer. This means I can add events as easily as before, but more easily expand events that already exist. It's technical, it's boring, but means actions that used to take quite a bit of time to put together are comparatively trivial now. I was able to get the shop scene up and running in about ten minutes. Well, graphically, obviously logic takes more time, but I no longer have to tinker with transition timing, fuss with controller focus, or deal with scene cleanup. At the engine level things are all handled in general blocks of logic that can be extrapolated into many types of tasks. For example, when you enter a shop the following block of code is called:
Code:
    scene_event_add( SCENE_EVENT.LAYER, [ LAYER_HIDE, 2 ] );
    scene_event_add( SCENE_EVENT.TRANSITION, transition_make( transition.color, c_black, one_second ) );
    scene_event_add( SCENE_EVENT.WAIT, [ SCENE_WAIT_FOR_TRANSITION ] );
    scene_event_add( SCENE_EVENT.TRANSITION, transition_make( transition.blank, c_black, one_second ) );
    scene_event_add( SCENE_EVENT.SCENE_STATE, [ world, false, false ] );
    scene_event_add( SCENE_EVENT.SCENE_STATE, [ _shop, true, true ] );
    scene_event_add( SCENE_EVENT.TRANSITION, undefined );
    scene_event_add( SCENE_EVENT.CONTROLLER, obj_shop.id );
This is the type of action that would have taken a page of code in the old engine and more than anything illustrates the improvements that are coming out of the rewrite. This simply would not have been possible before. While in terms of game logic I still have a lot of stuff to do, at least I don't have to fuss with the engine layer to get it done anymore.

I also finally fixed a major issue I had that I simply couldn't solve before. The renders are set to be cleaned up when destroyed, but whenever I would close the program it would crash. I know generally what was causing the crash, but I couldn't figure out why it was causing it. To me it looked like objects were being destroyed improperly, I considered it might be weird GM behavior but I had a workaround and I was like, I'll just ignore it for now. Well, while getting scenes implemented I started having odd errors and crashes every time I would destroy a scene. For some reason, instances managed by the renders weren't being destroyed. This meant they were leaving behind orphaned instances would make a call to a non-existent render and crash the game. This is one of those things that's hard to track down but completely obvious once you see it. Each render keeps a list of all the instances it manages, and when and object is created or destroyed it is added or removed from this list. The idea is the render doesn't have to manage the instances specifically, but what I realized is when I was destroying a render I was using a for loop that checked the size of the instance list. What was happening is every time an object was destroyed, it removed itself from the instance list. When the for loop checked to see if it was done, the list was smaller and would terminate prematurely, leaving behind the orphans. While I'm sure there are more embarrassing bugs out there, this is one I am well and truly relieved to see go. Originally the renders did manage their own instance lists, in which case the for loop made sense so this was a case of having a piece of code that didn't evolve with the new methods. Anyways, the engine should be about ready to start building scenes again. Which I have nothing to show for. Well, not in-engine but I said I'd post a screenshot so here's a mock-up that I did for the new store layout (which is why it looks weird):

Trying to make better use of screen real estate.
Anyways, not bad for a solid day of working on it (I didn't spend all day, I also watched Blade Runner (the original) again), and until next time! I look forwards to being able to show off game progress again!
 
Last edited:

Roa

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

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

Hyomoto

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

I64 argument is unset
############################################################################################
--------------------------------------------------------------------------------------------
called from - gml_Object_parent_battle_actor_Draw_0 (line 9)
called from - gml_Object_obj_system_render_Draw_0 (line 21)
called from - gml_Object_obj_render_Draw_77 (line 108)
Which build is this from? PC or Mac?
 

Hyomoto

Member
Goodness, it's been a minute since my last update and ... I've gotten very little done. Have some more pressing career business to take care of, but that doesn't mean that I'd simply leave the project to ruin ... just that there isn't that much new to show off. I believe I mentioned above that I was working on getting the mouse control working and such, and that I threw all the old interface code right in the garbage where it belongs. Well, I worked on it some more and I finally have the interface code up and running in a very nice sort of way. I also took a bit of time to condense some functions that were being called in multiple places, converted the world map into a scene type rather than a pure render (WHICH IT SHOULD HAVE BEEN ANYWAYS), and fixed a bug in the path finding code. Here's a really, really short video showing mouse controls in action.
Very mouse, such controls.​
The good news is that is a pretty big chunk of content out of the way and it's at the point where now the majority of scene-related code is in the right spot and is mostly functional code. The big thing I'm constantly wrestling with is reduction of duplicated code. And I do this by finding things that are done a lot and rolling them up into larger ideas. For example, a window works as such:
Code:
obj_parent -> obj_window -> window_generic -> window_generic_menu -> shop_menu_items
Basically each object serves as a layer of abstraction. While the object grows in complexity as it sinks to the bottom, it also has layers of management removed or overwritten. By the time you get down to shop_menu_items, it only contains the code that makes it unique from any other generic window menu, which can vary from object to object. And that's the core of why mouse control is now possible to add quite easily, it is no longer a unique function of particular windows, rather it's a baked in layer of interaction that sits right alongside the controller inputs. Which, by the way, behave the same way. A menu is defined as:
Code:
contents    = [ "Buy", "Sell", "Exit" ];
And voila, I have a fully functioning menu with all the bells and whistles. In fact, I probably have too many bells and whistles, or perhaps the default behavior isn't quite right. Well, in that case I can define a few extra variables to make it behave exactly as I'd like:
Code:
paneMenu.contents    = [ "Buy", "Sell", "Exit" ];
paneMenu.keyUse        = KEY_VERTICAL;
paneMenu.wrap        = WRAP_VERTICAL;
The other big consolidation and simplification is 'scene' handling. Basically, everything you see on screen is a 'scene' of some type. The simplest way to image a scene is a bunch of objects that have been thrown in a box together. For example, a shop consists of menus and graphics. But what if I want to hide my shop? Or maybe I want to throw it away? Scenes are a way for me to deal with data in bulk without having to touch each individual instance and know it will all behave correctly. However, like how a render handles the sorting and drawing of objects, a scene also provides a layer of interaction between all these different objects. This makes things especially easier because if I want to add or remove something in a scene, I can just do so and there's no additional changes necessary. The scene serves as a go-between for the different objects, as well as a consolidated place for menu interaction. Now that scenes are up and behaving how I would like them to, and the user interface code is all sorted out quite nicely, I might actually start working on something fun.
 
Last edited:

Hyomoto

Member
Right, another little update. I worked on the menus a bit more and got the buying and selling interface working. Probably still needs some tweaking but there's probably a few things you'll notice. Namely the animation. I've said from the beginning of this project I've wanted to preserve that NES feel, and that includes the way that the interface works. However, I just really liked how these animations looked and helped add a bit of expression to the scene. However, there was something that just wasn't quite right about them. When I did the first engine I had programmed all the windows to be able to do a sort of blanking operation that was meant to look similar to the way the menus would refresh after you interacted with them. In this case though, the engine works differently. The menus themselves are written directly to surfaces in VRAM to ensure that the scenes run as quickly as possible by reducing redundant redrawing of screen elements. And, like always, I wanted a simple, brain-dead way of accomplishing this effect without having to resort to a bunch of lines of code.

The end result is the engine is a bit less elegant, but it works out nonetheless. What happens behind the scenes is when you call for a vblank, it does something like this:
Code:
if vblank > 0 && didBlank == false { cache = true }
else if vblank == 0 && didBlank = true { didBlank = false; cache = true }

if vblank > 0 { vblank-- }
So that way I just call for the blank and it will redraw the window, then when the blank ends it will call it again. While it's subtle and hardly a focal point, it does add a lot of character to the menus and helps it retain that original feel.
Yay.​
Again, small. Right now I'm in the middle of moving so I haven't really put a significant effort in but I figure you do enough tiny things, I'll get there eventually. Until next time!
 
I don't like the "vblank" effect. It's very harsh, and feels tacked on just because it's what someone thinks retro looks like. It doesn't feel authentic at all, unless there was some port I don't know about of FF1 to the Commodore 64 written in BASIC. Never mind the fact that your graphics and menu design is much better than FF1's makes it stand out even more, and that the original itself doesn't do whatever you're calling "vblank". For boxes in shop menus, it uses the same effect that textboxes use, albeit much faster.

I believe it looks vastly better without it. Please reconsider the effect.
 
I don't like the "vblank" effect. It's very harsh, and feels tacked on just because it's what someone thinks retro looks like. It doesn't feel authentic at all, unless there was some port I don't know about of FF1 to the Commodore 64 written in BASIC. Never mind the fact that your graphics and menu design is much better than FF1's makes it stand out even more, and that the original itself doesn't do whatever you're calling "vblank". For boxes in shop menus, it uses the same effect that textboxes use, albeit much faster.

I believe it looks vastly better without it. Please reconsider the effect.
It is actually fairly accurate to the original - go to about 4:30-ish...


Not exact replica, the slide and text drawing is a little different, but I played this game and many other of the day and it feels pretty good to me.
 
It is actually fairly accurate to the original - go to about 4:30-ish...

[video]

Not exact replica, the slide and text drawing is a little different, but I played this game and many other of the day and it feels pretty good to me.
You're right. I retract my statement. I literally just played yesterday; I don't know what's wrong with me. I must've been having a bad day when I posted that.
Sorry, @Hyomoto.
 

Hyomoto

Member
You're right. I retract my statement. I literally just played yesterday; I don't know what's wrong with me. I must've been having a bad day when I posted that.
Sorry, @Hyomoto.
It's no problem but even still I would defend it because the reason it came about was actually when you bought something it ... sort of just happened. My first attempt has you buy something and the menu would close and return to the list of wares. That made the transaction ... feel incomplete or confusing, so I changed it so it simply allows you to purchase again, that way the player could process the action, and recognize that they party member had received that item. Still, it just happened so it wasn't entirely clear whether or not you had actually purchased something, so I wanted a better signal that yes, the inventory had changed. That's when I realized the blanking effect would be useful. For the original that served as a good visual representation that something in the shop had changed. You completed the transaction, you cancelled an action, etc... I have gone a bit further with it, but that's partly because the effect seemed out of place if it hadn't been established as how the menus respond.

Nonetheless, I certainly don't mind your response. Sure, it was a bit direct but when you are building something it's always useful to see it through someone else's eyes.
 

Hyomoto

Member
So a little update. Still in the process of moving so actual coding is slow, but that's not to say I haven't been thinking about other aspects of the game. Namely: the plot. One of my favorite parts of the original game is the many memorable places you go and things you do. Why FF has stuck with me all these years is debatable, but to be quite blunt: the plot is pretty bare. I don't specifically have an issue with that, but one of the limitations of the time that spawned the game is that stories most certainly weren't as rich or important as they are now. They generally served as a reason to do something, not really looking into the wider ramifications or impact these events might play. And that's somewhere that I've been thinking about putting in some work while my computer is in limbo.

The game is ostensibly about Chaos and the four fiends. At it's most basic, the fiends are stealing the energy of the future elements to feed Chaos in the past so he can live forever. The plot is much, much more convoluted than that and contains perhaps one of the earliest 'twist' endings in gaming history. That said, the twist is not particularly good and some parts of the plot are confusing, so I've been considering ways to sort of clean that up, expand the plot a bit and tie things together a bit better. Some of this is easy, I have a ton more memory available and can include more plot if I want. But I'm also not a writer by trade, so I've enlisted the help of a friend who is to give me a few pointers here and there. While that larger picture develops I'd like to talk about some of the more micro (or macro) ideas I've been floating around.

The first is the Warriors of Light. The original game glosses over where you came from: entirely. But the odd part is, Coneria is not exactly a trade hub. The bridge is down, there's no other towns, cities or villages nearby and while there is a port, no ships are known to be sailing because the seas are dangerous. So just where did you come from? Given that the original plot centers around time, I've been considering using that as a sort of explanation. Anyone familiar with Bravely Default, Chrono Trigger, or other worlds like Zelda: Link Between Worlds, or even any other fantasy story that deals with time, will probably have some idea of where I want to go with that. For sake of keeping things vague however, there's a tangible benefit to exploring this. When you first start the game you are thrown into the world, the only two places you can go are Coneria or the Temple of Fiends, and given how dangerous it is to go without equipment, you are naturally drawn to the town you start in front of. While that is definitely a clever mechanism to ensure the player starts on the right foot, it also gives you very little idea of what the heck you are doing without reading the manual. In fact, the manual seems to know this as it literally walks you through the game up until you get the Airship and defeat both Lich and Kary. What I'm getting at here is a lot of this can be transposed into the game. And one of those ways is better establishing who you are and what you are doing to begin with, that way when you take your first steps into the more familiar world you have a little bit more to go on.

The next thing is the Four Fiends themselves. Something that has always sort of bothered me is that they don't actually do anything. We're told the world is screwed (though the game's palette certainly doesn't suggest that) and it's likely they are busy draining power from the planet. That said, that makes for only a mildly compelling enemy. The reveal is cool, finally seeing this horrible creature, but the lead up is pretty benign. So something else I've been considering is the idea of 'thralls'. For example, you have enemies like Astos and the Vampire which technically have their own agency. While there's nothing wrong with that, I'm sure evil exists in the world, I think it would be interesting if the Fiends had tasks they were unable to complete, or saw as beneath them and therefore had corrupted members of the various races into working for them. From that perspective, I'd like to weave Garland and Astos into a wider narrative, as well as add some new players. Those of you familiar with the game probably spit out your coffee just then. I am fully aware of Garland's place in the plot and it's stupid, confusing and sounds like it was made up literally when they wrote that scene. Hard pass. Forgive me for my transgression.

So let's talk big picture then. Basically I like the idea of Chaos being a large, scary entity doing evil. He has created/enlisted/awakened the Four Fiends to help do that evil. The Fiends themselves employ corrupted thralls to spread chaos and ensure that the various races are unable to mount a good offensive to stop them. Cue heroes. To that end I'd like to add a 'prequel' which serves to introduce and explain your party and the world. I'd also like to expand the fiends plot and quest lines a bit to better tie them into the state of the world and what they hope to accomplish. Much like my work on Pravoka I'd like to do little quest expansions that better flesh out specific quests. And finally, I do intend to make changes to the end of the game since the original was perhaps shocking for it's time, but by today's standards it's shockingly bad. I've also been inspired somewhat to pull a "Breath of the Wild" or "Dark Souls" and let the end of the game be largely accessible from the outset. A couple of other ideas I've been considering is a sort of 'soft timer' where the world becomes worse the longer you play, and having some events tied directly to that to give some diversity to anyone who plays through more than once. Also, one of my favorite features of the original was the freedom to tackle the game in the order of your choosing, despite it's intended path, and like letting you go to the end from the beginning, I'm also looking at other ways that might be possible to embrace.

Anyways, that's enough rambling for now. Feedback is appreciated here, so if you have thoughts let me know! This is all in the planning stages, so I appreciate any perspective you'd like to share.
 

Bentley

Member
I love this game. The machine I played it on would regularly delete my saved data. It made it that much more epic when I finally beat the game.
 

2DKnights

Member
Well i always wanted to explore the world in the past, but you're locked into the temple. You could have an altered story that makes the temple inaccessible when you first travel back, and you need to find the younger fiends (perhaps in the past they were guardians who were corrupted by chaos) remove their corruption (by stabbing them of course) and returning a crystal to each, which unlocks the temple, and you then fight chaos.

By exploring the past you could visit Corneria when it was just a village, see the wonders and clunky robots of the ancient civilization, or visit the mermaids in their heyday.

I also wouldn't allow the light warriors to return home after defeating chaos, i'd have them make new lives after being stuck in the past. then in the present they are only legend,
 

Hyomoto

Member
@2DKnights - Pretty close to what I was thinking except with Chaos in the future. Essentially the Warriors of Light would try to stop Chaos in the future and learn that by defeating the fiends in the past they can weaken him, thus the world in which the game took place would be the past from the Warriors perspective. And basically you could return to the future at any time to confront Chaos. Since the game doesn't have an emotional arc like Earthbound, I'm not sure the narrative weight preventing their return would have. Especially since if successful they will have returned to a future that no longer exists, severing the timeline and creating a new past and future in which they do not exist.

Love the feedback!



As a little extra here, I was working on putting together 'quest' logic. When I did the Pravoka scene, basically everything had to be done by hand. In this case I'm trying to flesh out a fairly simple logic machine that can be used to build simple cut scenes as well as handle setting up rooms. The difficulty in doing this, as opposed to the other method, is that GM2 as far as I know has no particularly great way of accessing other variables during run time.

In something like C++ you could simply pass the address of that variable, and it would be exceptionally easy to use that in evaluations. Here however, in order to make sure the variable is correct I have to use a pretty inelegant workaround which is to essentially define what variable it should look at, then reference that by name. Right now a quest machine is basically an array of actions, not unlike the other state machines the game uses elsewhere. However, unlike those machines, this one needs some helpful logic which means I need a simple logic system, namely 'jump' and 'jumpif'. So, for example, the pirate quest might look something like this:
Code:
questQueue = [
  [ "start" ],
  [ QUEST.JUMPIF, "bikke", [ [ CONDITION_EQUAL, [ QUEST.STAGE, 4 ], 4 ] ] ],
  [ QUEST.PAUSE ],
  [ QUEST.JUMP, "start" ],
  [ "bikke" ],
  [ QUEST.DESTROY, [ [ obj_pirate ] ] ],
  [ QUEST.SPAWN, [ [ obj_bikke, 14, 13 ], [ obj_pirate, 13, 13 ], [ obj_pirate, 13, 13 ] ] ],
  [ QUEST.DESTROY ]
];
The logic is pretty simple but basically the quest checks how many pirates you've defeated, if it's not 4, the quest is paused. Otherwise Bikke appears and the quest destroys itself. The pause is really where the machine gains a lot of versatility. When it is paused, it will stop executing altogether until it's told to continue. In the above example if it were to resume, it would hit the 'JUMP' logic back to 'start' and perform the 'JUMPIF' action again. So, rather than actively checking every step of the game, when you defeat a pirate around the town the quest can be incremented and the machine unpaused, causing the check to be run again. If it still isn't fulfilled, it goes back to sleep until you've defeated enough pirates to cause Bikke to appear. In this case it's just a simple logic machine, but when it comes to spawning, destroying, and animating the world, that's where it really starts to pay dividends.

Anyone who has done low-level coding or even played with a game like TRS-100 or Human Resource Machine will be pretty familiar with the basic JUMP and JUMPIF functions. In my case I considered using line numbers since it would be faster, but since there is no automatic way to count lines in the array from the code editor I decided to just use labels instead. That way if I want to add or remove lines it doesn't require the extra work of counting again.

And like the other machines I've written, with the foundation in place it's pretty easy to add new actions as needed. Working together these systems should allow quite a bit of flexibility and make building scenes a bit easier.
 
Last edited:
Not sure if it's exactly what you were talking about, but Studio 2 has functions to get and set variables by passing their id as a string. Not at my computer at the moment, so I don't have the exact function names.
 

Hyomoto

Member
Not sure if it's exactly what you were talking about, but Studio 2 has functions to get and set variables by passing their id as a string. Not at my computer at the moment, so I don't have the exact function names.
You know, that is a good point. I usually avoid those functions but that would definitely be more flexible.
 
Last edited:

Hyomoto

Member
No. I'm still tinkering and such, but not much to share. I had a major move, new job, etc... but it's still a passion project and I'm still invested.
 
T

tetherline

Guest
This seems super ambitious but really cool. I wish you the best of luck man.
 
R

Red_Wing

Guest
Dude, this is solid. I love the original FF, and now I love this. I dig the custom colors you can give the party, and the sprint feature is brilliant! Unfortunately I didn't get to play very far. I get the same error as Roa Mentioned above. It happens right after the first random encounter. Tested on a Win 10 PC.
 
Top