Project Phases Update 9: The Final Stretch

New Sprites/Tiles

Right off the bat we have a very big change, the new graphics (again)! This is the third and final time I have updated the graphics, but this one looks better than any of the other ones. The tiles have increased in size from being 16×16 to 32×32. I tend to have a hard time with drawing art, but I am really happy with how these tiles turned out. You’ll see more of the new overworld sprites and tiles as we go through the update. Here are some looks at the updated tiles for the overworld and cave. I also want to give a quick thank you to MidnitePixel for giving me a few pointers on how to make good-looking tiles. Here are some mock areas using the new tileset…

There is also a new sprite for Daryl with proper animations! I definitely had a harder time animating Daryl than I had with any of the tiles but I think it looks pretty alright. Here is a comparison of the old and new, the old one is laughably bad.

Welcome to Arlette

Where are we anyway? The starting town has been named Arlette. It’s a peaceful town with a few houses and villagers roaming around. It’s split up into multiple areas: the main town center and areas in each direction, north, south and east. It’s still a work in progress, but it’s coming along.

Updated NPCs and Textboxes

Arlette has many villagers roaming around. NPCs now have their own animations and walk around within a given range. They will even turn to face you when you talk to them! Talking to NPCs also shows the updated textboxes. Textboxes now have portraits and names for whoever/whatever you are talking to. This applies to anything that uses the textbox. For example, if you are talking to Alex, the textbox name in the textbox will be “Alex” with a portrait of him. However, if you are opening a chest, the name will be “Chest” and it will be a portrait of the chest. Finally, textboxes have sound! This isn’t something I can show off in a gif, but make sure to check out the Update 9 YouTube video (at the top of this post) to hear it.

Houses

And where do these villagers stay? Well, in houses of course. There are a few houses scattered around Arlette, all of which have special properties. First, sometimes the house may be locked, and you will not be able to go inside. You wouldn’t want a random person in your house! Some houses cannot be opened at all, but some can if you have the right key. Going inside a house shows another new tileset, with nice wooden floors and white walls. You may even see a painting or two. As an example, let’s show how to break into Alex’s house…

North Cave

Heading up to the North Cave, you will see that the graphics have changed to the tileset I showed earlier. It looks far better now, with more colors than just grey. Here is a before and after…

Cave Door

Going down a few floors in the cave, you will find a vault door blocking the path. The door is locked, however, you can unlock it if you have the correct key. Once you find it, the door will fall back into the ground allowing you to walk through. Obviously in the real game, the key would be in a harder to reach location.

Saving

A big (and long overdue) addition is the ability to save. You may see flags waving around the overworld. These are save flags, and interacting with them will save your game. Flags with a red cross on it will also heal your party! To load your game, simply hit the new load button on the title screen and you will be placed right where you left off. All of your stats, defeated enemies, etc. get carried over as well just as you’d expect.

Quests

The game now has a quest system. When you start a quest, a notification will appear in the top right corner. If you click on this notification, it will take you to the quest tab in the menu and open that quest. You can also get here manually by opening the menu and pressing the quest tab. In this tab, you can see what current quests you have and what you must do to complete them. Once you have successfully done everything for that quest, the quest will be complete and taken off the list. Here is a gif showing a mock quest in action. The quest progression is finding Alex’s house locked, finding the key and then talking to Alex.

The system is pretty flexible and quest objectives can be all sorts of things like finding an item, talking to an NPC, defeating a certain enemy etc.

Cutscenes

Another overdue addition is cutscenes! Once you trigger one, black bars will come from the top and bottom and the cutscene will begin. Characters can move, animate and more automatically during cutscenes. However, there is still some player input since it is up to the player to advance textboxes.

This cutscene system works very well and should help quite a lot when it comes to developing stories and characters during the demo. Shoutout to FriendlyCosmonaut for creating the basis for this system.

Transitions

There are also new transitions between scenes and rooms. In the past, whenever you enter a battle or a new area, it would just suddenly appear. Now we have two transitions: a basic fade-in/out and a battle transition. I’ll show you the battle transition when we get to the battle section, but here is the fade. This transition plays whenever you go between areas or at the end of a battle. You may have already spotted it in some of the other gifs, but here it is again.

Updated Sprint

The sprint in Phases has gone through many changes. For the longest time, you would gain a giant boost of speed when you pressed shift. In my last dev-log, I mentioned that I updated it to not be such an abrupt change in speed by giving it more of an acceleration and deceleration curve. However, one of my friends saw the sprint and said, “That’s dumb, why not just have it speed you up slightly whenever you hold down shift?” And you know what? They’re right. So now you speed up slightly when you hold shift. Gone is the burst of speed. However, in the future, this may change again because I can never make up my mind on this (especially if we can get a roll animation). You can barely tell the difference in speed in a gif, so just take my word for it.

Updated Camera

I have also updated the camera. I never really messed with the camera much before; in fact, I used the camera built into Gamemaker for a good while. However, I needed to update the camera to allow it to work properly with cutscenes. So I took the opportunity to overhaul the camera system. You may have noticed that some of the gifs have had panning shots. This is because I can now move the camera freely. I can also move it to follow any object I want. Don’t know how useful that is but that is cool. Once again, thanks goes out to FriendlyCosmonaut for being the foundation for this system. Here is a gif of crazy camera shenanigans.

Updated Chests

Chests have once again been updated. They are a bit smarter now. If a chest is holding an item that you can’t carry for whatever reason (either you are holding too many items or you don’t have enough space for it), the chest will close back up and not allow you to get items. Now, the maximum number of unique items you can have is 99, so the odds of this ever being an issue are small but it’s still good to have.

The chest now also properly supports being upside-down and can only be opened in one direction. Overall, there is less bugginess when dealing with chests. An upside-down chest looks a bit off because of the shadow, but a quick sprite change should fix it. To knock out multiple birds with one stone, here is an upside-down chest, only able to be opened in one direction, not allowing you to take the items because you have too many.

Depth System

For those unaware, a depth system is the system that determines when you should be in front or behind objects. This is necessary to create the illusion of depth within the game, and it works perfectly. Also, sometimes, when you are behind something large, you can’t see Daryl. In these cases, the object will become transparent, so you are still able to see where you are going. This occurs with objects like trees and houses.

Background

The boring black background is no more! The new background is based on the overworld area and takes heavy inspiration from the overworld tiles. There are many other elements at play here too. The trees in the background are randomized, so you will never get the same layout or swaying of trees. There are also randomized clouds floating by in the background. You may also notice a few swaying flowers on the ground which are also, you guessed it, randomized. I think you can see the trend here.

Our objective with the new background was to make it visually interesting enough where it could look pleasant, but not too over the top to take your attention away from the battle. I think we did a good job on that overall.

As you may have been able to figure out, there will be area-specific backgrounds in the future. So if you have a battle in the cave, there will be a different cave background. As of now however, we only have the one background so please stay tuned for more!

New UI

Another big overall change has been the UI. Almost everything has gotten a complete overhaul visually and functionally. Allow me to list them out…

New Timelines

Timelines now have a gradient within them and a border surrounding them. They are also more dynamic, able to change color depending on various timeline effects and even crack when your defense is broken. The new looks let them blend in much better with the overall style.

The way timelines are made has also been updated. Before, every timeline was a sprite that I made outside of GameMaker. I would then have to import the sprite, make a timeline parent object, and make three unique hitboxes for each phase. So, by the time I had six characters on screen, I had 24 different objects just for timelines alone! Now, this has been changed. Timelines are now completely made in-engine using code. All I have to do is plug in what phases I want a character to have and in what order, and it will create the timeline for me. Instead of four objects (a timeline and three hitboxes) for each character, there are now five objects (enemy and player timelines plus 3 hitboxes) that can be used universally, cutting out a lot of unneeded complexity.

Also, this change allows timelines to be created using numbers, which means they can be randomized which is perfect for enemy encounters. I still don’t entirely know how enemy encounters will work in the final game, but this new mechanic will most certainly help. It also allows me to make some wacky timelines like this one…

So that’s fun.

The timeline arrow also got a slight redesign. It’s nothing to major, but it does have some added “texture” and of course all of the arrow colors and numbers have gotten similar updates as well. Timelines can get absolutely loaded, so these really help break up what’s going on.

Selection Arrow

Speaking of arrows, another arrow that got a redesign is the selection arrow. This is the arrow that appears whenever you hover over a character to select them as the target of an attack. Before, it was literally a timeline arrow doubled in size and rotated 90 degrees. The new arrow is much more unique, resembling an actual arrow more than the triangle-shaped timeline arrows. It even animates slightly, moving from side to side as you hover.

Updated Menu

The main menu in the middle has also been updated. The old design had a lot of wasted space since I didn’t know what exactly would fill up the menu yet. I designed the new one around the UI elements to make a smaller and sleeker design. The font has also been updated to be overall smaller as well. This font change applies to pretty much all the text in the battles. Here is a before and after…

Player Stats and Health Bar

Above all of the characters, you will see a brand new layout for viewing all of the character information. Before, player health, point and time were simply listed under their respective symbols in number form. It didn’t look very good. Now, all of these stats have been neatly organized in a collage.

The main attraction is the new health bar. This health bar is quite dynamic and has a lot of cool features. First, if you select an enemy with an attack, the amount of damage that will be dealt will be reflected on the health bar. This also applies to healing allies. The color of the health bar will also change depending on what type of attack it is. If you are dealing damage, it will turn purple, pink for healing and if the attack does a random amount of damage, it will turn orange. The following gif shows all the types.

Surrounding the health bar are the player’s points and time. Those are much more simple; they simply turn purple when they are set to be changed in the future. The counter for time also gets grayed out when you are not in your attack phase since it will not change otherwise.

Freezing

Freezing is a pretty neat visual effect. Whenever a character starts their attack phase, every other character will freeze and become grayed out, while the character who is selecting the attacks remains unfrozen. It’s an effect that helps sell the “time has stopped” nature of selecting your next moves during the attack phase. It also makes it even more clear who is attacking, if it wasn’t already obvious enough. Some of the frames that you can freeze on look really neat, some are a bit more awkward. Overall though, it looks great.

The Death of Small Skip

The final UI change is actually a removal. The beloved small skip button has been removed. This was the button next to a player that said “Skip” that allowed you to skip the phase whenever you wanted. Let us have a moment of silence for the small skip button…

However! The legacy of the small skip button still remains! The small skip has been combined into the player sprite itself. To skip a phase, simply right click any of the players to skip their corresponding phase. Hooray!

Gameplay Changes

Now let’s move onto some big gameplay additions and changes that have been added in this update. We already mentioned a few as they pertained to the UI but here are a few more.

Other Menu

One of the biggest battle changes is the new Other menu. This menu was here in the past, but it was empty. That is not the case anymore though! Clicking the Other menu will present you with three new moves. These aren’t really attacks, but are more like special actions that everyone can choose. Let’s go over them…

Other Menu – Skip

You may be asking yourself, “There already are 2 ways to skip, right?” and you would be correct. This is a new way to skip your attack phase. Clicking this action will add “Skip” to your order pane like an attack. This allows you to skip the attack phase immediately after you are finished attacking. If you want to get out of the attack phase as soon as possible, this is a reliable way to do it. It takes 1 time and 3 points, so pretty much the same as doing it manually. Once you select Skip, you won’t be able to assign any new attacks, so keep that in mind.

Other Menu – Inspect

Inspect allows you to inspect the enemies to gain the ability to see their points. Previously, you were able to see the enemy points by default, but now you have to work for it. Inspecting takes 2 points and 2 time. Once you have inspected them, the enemy’s points will show up to the right of their health bar.

Other Menu – Run

This allows you to run away from battles. Running takes the entire attack phase to execute, meaning you cannot do any attacks in the same turn as you run. Running will also take away the ability for anyone to attack while you are running, regardless if you are in your attack phase or not. To successfully run, the character who is running must not get hit during the lead up to the run. If they do, the run is cancelled. Manage to not get hit however, and you can leave the battle. In this example, we successfully run then it is followed by a failed run…

The running system is quite unique. Running is a risk since you limit your ability to attack. However, through careful planning, you should be able to run successfully whenever you want. Pro-tip: characters who are faster and have shorter attack phases are the best for running since they have to wait the least amount of time to run successfully, minimizing the chance of getting hit. So characters like Clint are ideal candidates. Good luck running with a speed-debuffed Oliver though…

Those are the three other options. I hope you will be able to find good uses for all three of them. We have space for two more so maybe we will fill those up too.

Hover Mechanics

There are some new mechanics that I call the hover system. Whenever you hover over an attack hitbox, several things will happen. First, a hover arrow will appear on every relevant timeline to show where that attack will land. So, if you are choosing Slash, an attack that targets the enemies, the enemy’s timeline will get the hover arrows. Second, the damage will be calculated and the health bar will update accordingly to show the new damage. It will also take the phase the attack lands into account such as if a Slash is projected to land in the defend phase, it won’t show any damage being done on hover. Lastly, if you are selecting an item (or an attack with healing properties), those effects will be shown as well. This includes adding points, time and health to players and showing buffs and debuffs. Let me show you what I mean in action…

There are some new mechanics that I call the hover system. Whenever you hover over an attack hitbox, several things will happen. First, a hover arrow will appear on every relevant timeline to show where that attack will land. So, if you are choosing Slash, an attack that targets the enemies, the enemy’s timeline will get the hover arrows. Second, the damage will be calculated and the enemy’s health bar will update accordingly to show the new damage. It will also take the phase in which the attack lands into account. For example, if Slash is projected to land in the defend phase, it won’t show any damage being done on hover. Lastly, if you are selecting an item (or an attack with healing properties), those effects will be shown as well. This includes adding points, time and health to players and showing buffs and debuffs. 

Carry Over Mechanics (or at least the start of it)

Adding the hover mechanic also gave me a chance to start implementing a mechanic I’ve wanted to add for a while, carry over. Let me give you an example of how it would work. If you select a Fury on Clockman, the enemy’s health bar would update to reflect the damage. Now, if you get into another attack phase before the Fury happens and time stops again, the damage that will be done by the Fury will show up again since it has yet to happen.

That is the basic idea of the carry over mechanics, to allow all the future mechanics to carry over from player to player. I hope that makes sense. I wish I had something more to show, but it’s still just a concept. The big issue with it is consistency. Let’s go back to the same example. That Fury attack isn’t guaranteed to hit, many things could happen to avoid it. The player could skip over the attack phase or maybe the enemy skips into a defend phase. How do I track whether an attack has happened or not reliably? I can’t just reset it every time you skip, since in most cases that won’t change the outcome. It’s a work in progress indeed.

I have started to implemented a little bit of this system. If you are set to get a buff/debuff through an item, the buff/debuff icons will appear faded between attack phases. It’s small, but it’s a start. Hopefully we will be able to get more things carrying over later, but it honestly might not be feasible, so I will keep you posted.

Animation System

Though you may not realize it, but the animation system for Phases (and most games out there) is a lot more complicated than it may seem. For Phases in particular, the animation needs to work around the unique gameplay. If we start an attack animation right when the attack lands, it will be too late since most animations have a wind up and don’t start with the impact of the attack. To adjust for this, the animation system will start the animation early. In the code, I give the system an impact frame, which is the frame of the animation where the actual attack happens. The game will then do some math and start the animation at the correct time so that the impact frame will play when the attack is executed on the timeline. Pretty neat!

However, there is another element that throws a wrench in the system, speed. We have to make sure we take it into account when playing the animation. Luckily, the system has been programmed to be able to speed up an animation if needed. For example, if Oliver has a plus 50 speed buff, it may need to speed up his punching animation to make sure it lands properly.

Every character’s attack phase and moveset is different and we based the animations off of this too. Since Oliver has a long attack phase with long, drawn-out attacks, we can make his attack animation longer than Clint’s, whose attack phase is quite shorter.

Experience

You can now gain XP and level up your characters. This is a pretty overdue feature. It works as you’d expect; once you win a battle, you will gain a certain amount of XP. The amount you gain is based on which enemies you defeat and how many, similar to the gold system. Once you finish a battle, a message saying how much XP you won will fly out of the characters. At the moment, ending battles are really jarring, there isn’t any end screen or anything. I plan to add a more elegant battle results screen later, but this works for now.

You can check your level and your XP amount in the Overworld menu as well. Again, at the moment it’s just added on there without much thought, but we do plan on updating the overworld menus with the XP amount in mind.

Updated Back-End Battle System… again

For those who have been here awhile, this may sound familiar. I have changed the battle system on the back-end so many times at this point. However, this one is the biggest and most important out of them all and hopefully this should be the last major change. This next part is a bit technical and kind of long, so feel free to move onto the next point in the update if you want.

Let me quickly recap why I keep changing the system to begin with. The original system I made was created when I didn’t really know what I was doing. I had a lot of the basics of programming down, but I still had so much to learn. Because of this, much of my older code is extremely outdated and unoptimized, and since this outdated code is the core foundation of the game, simply changing one thing means updating everything. And when I say everything, I mean everything. It’s exhausting, but this time around I took the opportunity to completely update the battle system to make it more optimized than ever before.

The main changes I made dealt with attack creation, attack selection, and arrow movement systems and pretty much all of them had the same sort of issue. Due to my inexperience (and I can’t stress enough, I didn’t know any better) when I designed the system in the first place, almost all of the information I needed was stored in individual variables rather than the much more efficient arrays. For example, the code that kept track of who you selected was stored in five variables (1 for each possible attack) named “selected1”, “selected2”, “selected3” etc. instead of the far more logical naming of “select[1]”, “select[2]”. This awfully inefficient way of storing information was everywhere—to store what attack you used, who was selected, what item was selected and more.

The reason why this system was so bad was because in order to check for example, who was selected, I had to essentially write the same code five times with a slight change in number. If I had used arrays, I would simply be able to loop through them instead and only write that code once. My programmer friends out there are probably cringing right now, I know it’s bad, but it gets worse. I almost always, for some bizarre reason, used global and character-specific variables whenever I could. I really don’t know why I thought this was a good idea. This meant that not only did I have to write the same code five times for each variable, I could not reuse that code for every player because of a dumb global character-specific variable like “daryl_attack”.

This is terrible. Let’s make a hypothetical situation. Let’s say the code to check what attack you want to use is fifteen lines long. Now we must multiply that by five for each possible variable like “order1”, “order2” etc. Finally, since I used character-specific and global variables, we must write the same code for each character individually, so multiply it by 6. So I end up with 450 lines of code for essentially the same thing 30 times. This applied to everything—literally everything. And if I ever wanted to make just one little change, I had to update every single line. Oh, and if there was a typo in one of them, tracking it down was extremely difficult. So many of the glitches and bugs in the game were caused by this system. The game could crash with ridiculous things like using Slash on Lockman on the fourth order after an item! It was an awful system, but I honestly thought that was how most people did it.

As the game got bigger and bigger, I realized I needed to update this system. If I wanted to add even one more character or attack, doing so would take an exceptional amount of time. Though I knew updating the system would be a gargantuan task in it of itself, but I felt I was able to do it. For the record, this happened in the middle of the coronavirus quarantine, so I suddenly had a lot of time on my hands to actually get this done. So I finally bit the bullet and updated it, and boy, it was not easy.

I had to plan every change I was going to make ahead of time since the moment I changed just one variable, everything else would collapse, and I would not be able to run the game again until I updated everything. So it took days of just mindlessly finding and replacing variable after variable and slowly but surely updating all of the systems, all without knowing if it would actually work. After about a week of replacing and changing everything, I was finally able to run the game without instantly crashing. However, once I got into the battle, the errors started flying all over the place. I would say it took another few days to actually get to the point where you could actually start a battle without crashing the game.

This is how it was for about a month. The game would crash if I hovered over any attack, then it would crash if I selected an attack, then it would crash if I tried to select a target, and I think you get the idea. Slowly, but surely, I went through and fixed everything one by one. I worked through the errors and was finally able to complete a very simple battle. By simple, I mean no skipping, using items, healing, complicated attacks like Wide Slash or Living Strike etc. Finally, after about another month, the game was back to where it was before, and the difference was already huge. So many scripts went from hundreds of lines to dozens. While everything worked the same functionally, everything was much more straightforward, and changes could be made so much faster.

However, I didn’t stop. I figured I should go ahead and update most other outdated systems, so I did. I updated the arrow movement to be smoother, and many data grids have been optimized as well. Another month, and everything had changed—a complete rework. The game is the most stable it has ever been, and I am much more motivated to add new content knowing that it will only take a few extra lines of code rather than literally thousands.

I do want to point out that the biggest bug in the game has been fixed! This bug has been in the game ever since I added speed. I wrote a dev-log about how annoying it was almost 2 years ago! The bug was quite simple, when you select an enemy for your attack, the future arrow marker would appear to show you where that attack would land on their timeline. However, the bug was that the future arrow marker was extremely inaccurate. It depended on your speed, but generally the discrepancy between where the attack was predicted to land and where it actually landed would range between one or two pixels to fifteen or twenty. Here is a slowed-down gif of the bug in action (albiet a pretty tame version of it), notice where the future arrow marker is and where the arrow actually is when the attack hits.

However, after years of banging my head against the wall, I have finally fixed it! The best part, it was a super simple fix. The issue was that I was too focused on getting it to work with math. In that system,the equation would usually end up being “(attackTime+speedConversion)*5”. I explained this method of thinking in that dev-log from two years ago. I realized one day that I could just loop it instead of relying on math. So this is what I came up with…

var pa = 0; //Player Arrow
var ea = 0; //Enemy Arrow
while (pa <= attack_time*pixel_amount) //Move until it reaches the correct place in the player timeline
{
     pa += (arrow_speed+player_stat_speed); //Add to player arrow
     ea += (arrow_speed+enemy_stat_speed); //Add to enemy arrow
}
player_arrow.x += pa; //Add to player arrow x coordinate
enemy_arrow.x += ea; //Add to enemy arrow x coordinate

Basically, I move both arrows together slowly and in different amounts based on their speed until the player arrow reaches the correct point. Since the player arrow doesn’t get affected by speed the same way the enemy arrow does, we can use it as a reliable and consistent measurement. This solved it. It’s almost perfect now, and most discrepancies are fractions of a pixel so you can barely even tell. This is technically less efficient, but realistically, it shouldn’t make much of a difference.

This section is getting very long so I’ll wrap it up here. There are so many more changes I could go in depth about, but then this update post would become a really technical, boring mess. However, it deserves a large chunk of the update because this took more than 3 months to get fully implemented, but I couldn’t be happier with how it turned out. It’s still not perfect, there are still many things I wish to change, but we are in a very good place in terms of the battle system. It shouldn’t change much from now on, so I hope you’ll be able to play it in the demo release!

Battle Optimizations, Fixes and Smaller Changes

Wow, those were some big changes, but there are lots of smaller ones. Let’s rapid fire through them…

Hovering For Info

In the last update, the description box was added. It was used mostly for attack and item descriptions. You can hover over almost everything to get some sort of information about it in the description box. This update adds new hover information for characters and buff/debuff. It also gives you more information while hovering over the future arrow marker and order in the order pane. The more info the better!

Attack Cancelling

You can now cancel an attack after you selected it. Simply right click if you have selected an attack to cancel it. Before, you would have to select the enemy then clear the order pane to choose a different attack. Also, did you notice that the hitbox turns red when you have it selected?

Order Cancelling

Next up is order cancelling, this one is very useful. You can now cancel individual orders on the order pane. All you have to do is simply right click on whichever order you would like to cancel. That order will be deleted and the others orders will fill its place. So, if you have three orders and you delete the second one, order 1 will stay the same and order 3 will become order 2. It makes sense when you see it…

Order cancelling in reality is actually clearing the entire order pane then automatically re-adding the orders one by one, excluding the one you selected. It’s pretty simple and saves you from having to clear your order pane all the time. Also, did you notice that the “Wipe” button is now “Clear”? Fun fact, it was always meant to be clear, but it was too big to fit in the box with the font I chose. Thanks to the redesign, “Clear” can get it’s chance to shine!

Other Miscellaneous Changes

Those are all the notable changes in the battle system, there are a few more things I do want to cover that aren’t explicitly part of the battle or overworld systems.

Weapon and Attack Changes

Thanks to the new personalities of the characters, many weapons got changed to reflect the characters more accurately. I wasn’t going to go over each change individually, but what the heck, this update is already long, what’s a few more lines? Here you go…

• Daryl’s Sword -> Wooden Sword
• Staff of Healing -> Wooden Staff
• Rock Sword -> Leather Gloves

There are also now character-specific weapons. For example, Daryl is the only one who can use swords, while Clint and Oliver can’t. This is a good change since we can design weapons for each character specifically instead of having to account for everyone.

Also, some attack names have also changed, again, to reflect the new personalities of the characters. The ones that have changed are…

• Living Strike -> Revenge (Clint)
• Wide Slash -> Multi-Hit (Oliver)
• Smash Down -> Fire Punch (Oliver)

The description of many attacks have changed too, mostly changing the description of the attack to fit the animations and addressing the characters directly such as “Oliver engulfes his fist with flame and strike at full force at the enemy” for Fire Punch.

We have actually added many new weapons and armors, however you’ll have to play the demo to find out what they are.

Reviving

You can now use Revives to bring back a fainted character. Revives are a special kind of item since they cannot appear in battles, you can only use them in the overworld. Simply give them to a fainted party member to bring them back with 1 health, you will have to finish healing them on your own. In the future, we plan to add revives that can heal as well. Another possibility is the addition of reviving in battles, but we will have to wait and see on that one.

General Changes

We are nearing the end now but we still have a few general updates with the game to talk about.

New Resolution Manager

Way back in Update 1, I set the game resolution and created a resolution manager based on the system designed by PixelatedPope. While that system has served me well, it did make the game have some weird graphical glitches. Since, as previously mentioned, I am a far better programmer than I was three years ago, I decided to take a crack at my own system.

After a bit of trial and error, I made something I am quite happy with. Visually, it works almost exactly the same as the old system, but the visual glitches are gone. It’s a very barebones system, it lacks some bells and whistles like a zoom feature, but I don’t really need those anyways since it would just needlessly complicate things. Either way, I would highly recommend playing in fullscreen so that the manager doesn’t have to do any weird calculations in the first place. Fullscreen is certainly the ideal experience.

General Optimizations

Another big goal for this update was general optimizations and updating lots of my old code. I already mentioned this a bit for the battle system, but there are some other things I’ve done. While developing the game, I need to keep in mind not to make too many unnecessary objects. While I’ve done a good job keeping optimization in mind for newer features, the older ones weren’t up to snuff. For example, the “E” icon that appears whenever you can interact with something. Before, an instance of that “E” would be created for every object that needed it. So in the main area of Arlette alone there could be a dozen of those objects loaded unnecessarily between NPCs, signs and doors. Fixing those types of situations is the goal of optimization. Now, the “E” object is only created when you collide with an object that needs it, meaning there is only one onscreen at a time.

I’ve done a similar thing with many of the data grids. I had several instances of the same grid being loaded multiple times for some reason, but those have all been fixed. I have also streamlined how I add information into the grids, which makes adding new items, attacks etc. easier.

New Title Screen

My artist friends decided that my fun collage logo had to go. It did admittedly look quite bad, and you could barely even tell it said Project Phases. This new one is much simpler and more streamlined, however, it still has elements of the timeline, so you could say that the old one lives on. It is quite sad though, that title screen was the last surviving asset from the original Project Phases Overview video. The game really has changed since then hasn’t it?

Website Updates

Note from the future: Since I migrated in the site in 2023, basically none of this is true anymore.

Woah, website updates? Yeah, website updates! I’ve never had a dedicated section for the website, but a few things have changed. First, if you look in your URL bar you will see the new domain name, soltairus.com! You may not have noticed it since soltairus.github.io still takes you here anyway. I guess it makes this website slightly more official or something.

Second, if you go to the Project Phases tab at the top of the site, you will see that much of the information there has been updated to reflect the new changes. This includes updated battle, overworld and character images and information. Go check it out!

Third, the website has had a few typo fixes throughout the site. The biggest one was where on many of the pages it said “Solatirus” instead of “Soltairus.” Whoops.

Finally, I guess it’s not really a website change, but I got a new profile picture for my social places courtesy of our fine artists friends.