Author: danieltjewett

After six years of development, we are excited to announce that The Violets of Amicus™ demo is now available to play on Steam! You can play the game for free on Windows or Mac here! So grab any modern controller from your game console(s), connect to the computer, and Steam will do the rest!

The demo can last anywhere from 4-6 hours—there is a lot packed in! Our demo showcases a good vertical slice of the game mechanics / loop, story, music, art and even a dungeon! Please let us know what you think of it on social media or in the comments below. We are always looking to improve our game and would love to hear from you!

The game is intended to be played in one sitting. However, we are aware of some rare crashes. In the case of a crash, we do have an auto-save feature that will come in handy to load progress back. We only save major progress, like inventory, cleared forts, and story progression. We do not save defeated enemies, cut grass, trees, etc. We also don’t save dungeon progress. The full game will do a much more thorough job of saving, but we only implemented this feature recently.

With this major milestone, we wanted to take a trip down memory lane and showcase different art on the site over the years (cue Time of Your Life (IYKYK)):

As always, thank you so much for your continued support into our game.  We appreciate it more than you’ll ever know.

– Dan

We have one more week before our demo releases on Steam!  This past month has been crazy.  With final touches, polishes, new features and a trip to Cedarville, I (Dan) have been working overtime on my side hustle.  We’re excited to show off what we’ve been working on.  And soon enough, you’ll be able to play what we’ve been working so hard on the last six years!

One thing to mention before we get into the meat of our update.  We are in need of boosting our pre-launch numbers.  To help us with these numbers, please visit our Kickstarter page and click “Notify me on launch”.

Now, onto game updates!

Cedarville Trip

At the beginning of December, we were invited back to Cedarville’s 2024 Video Game Exhibition.

We got to meet / talk with about a hundred individuals interested / excited about the game.  We had about 15 people play the game.  The majority of these folks played a good 30 minutes or so, getting a good idea of what Violet will be about.

Overall, it was a good experience and we received a lot of good feedback that has already been implemented in the game.

We had one individual who was really into our demo!  As he was playing and we were chatting, we didn’t realize that the showcase was over!  We appreciate all of the support and feedback at the showcase!

Pixel Art

Tony has been working hard finishing all of the final touches / polishes on pixel art.  However, we do have a few new art assets to share.  First, if arrows are shot perpendicularly they will stick in enemies and Asteric.  Below are a few animations of Asteric removing the arrow from an enemy or himself:

We also spent a lot of time in December working on polishing the horse animations.  Below are a few of those:

And finally, a prototype of our Centaur Enemy!

We were hoping to get more done in December with the Centaur!  Unfortunately, we only got to still frames.  We were hoping still frames would work to fight against the Centaur in the demo, but it does not.  We’ll probably be taking the Centaur out of the demo.  But, we wanted to show what we’ve been working on in regards to the Centaur!

8 Weeks Remaining Updates

In the conclusion of our last post, we said:

“Believe it or not, this post doesn’t even cover the last two weeks!”

And, we weren’t kidding!  In those two weeks we had completed the following:

1. Demo Content (including many side quests)
2. Added NPC Generic Hair
3. Added Talk Circles (to indicate how many more unique dialogs an NPC has left)

This actually encompasses a lot!  We decided to showcase these with video clips!

Forest Town

We spent the last month or so polishing up Forest town.  This included adding new NPCs, side quests and main quest objectives.  We also started working on Forest Town’s theme as well.  We can hear this in these video clips below:

The Forest Town NPCs have their own clothing style that reflects the atmosphere — a cozy / laid back town nested in the forest.  However, a wizard lives in this town that can grant us the power to automatically merge:

Once we have received the power to automatically merge, we can remove the gate that blocks our path into the Ancient Temple:

There are quite a few other things to do in Forest Town!  Be sure to explore it thoroughly:

Saving and Loading

One major feature request we have been receiving is the ability to save and load the game.  We understand this request, as the demo is pretty lengthy.  However, because of the complexity of saving and loading, as well as our data structures and gameplay to change in the future, we originally did not want to invest time into this.  Plus, the intention of the demo is to be played through in one sitting, taking about 4 hours or so.

The problem though is that players have been occasionally getting crashes.  This is a pretty rare occurrence and unfortunately we haven’t been able to reproduce these (and trust us, we don’t take crashes / bugs lightly).  If we could, we’d fix these in a jiffy.  However, with the amount of time before the release of the demo, we realized it would be in the best interest of our players, in case of a crash, to have some kind of saving / loading system.  That way, progression isn’t completely lost if a crash happens.

Thus, we have spent the last few weeks working on a MVP saving / loading feature.  This feature is actually much more elaborate than we were originally planning (we were just going to restore a players inventory).  However, we were able to save story flags, completed forts (removing enemies from these forts), heart pieces, inventory and more!  Plus, we added an auto-save feature that automatically saves in the background.

You’ll see a couple of additional things in this video clip as well:

• We updated the Title Screen to include our concept art, as well as a Continue Game, New Game, Options and Quit Game.
• We added some text during the loading screen while the game loads.  We also updated the loading audio track, for those who have really slow machines, so that my (Dan’s) voice communicates to the player that the game is still loading and that there are no issues.
• We added a Main Menu screen, that has the Save button, as well as a Quit to Title Screen button.

All of these features were important and were necessary to make saving / loading work seamlessly for the player.

Correct Button Labels for Controllers

Our controller button labels were correct, for the face buttons.  However, our names were inconsistent across other controller types for the bumpers, triggers, sticks and pause buttons.  Therefore, we went through and cleaned this up to be dependent on the controller the player is using:

Encrypting External Data

With the release of the demo, the public would have access to the game.  This also means that any files / data in these folders are going to be scrutinized and we can’t just tell people “don’t do that”.  Therefore, we decided to spend a week encrypting external data, such as the text file and world assets.  That way, if people starting digging into these assets, all they will see is gibberish.

We also wanted to encrypt our audio files as well.  However, we couldn’t figure out a good way to do this, in the limited amount of time we have.  Unfortunately that meant moving these files into Game Maker / RAM, making memory usage for the player about 100mb more.  Once we figure out a good way to playback audio files from disk that are encrypted, we will move these audio files back outside of Game Maker.

Apple / Mac “Fun”

Apple does not make it easy for developers to make software.  In order for self-made software to work on another computer / device, Apple requires a process known as Code signing.  Unfortunately, we wasted a few days trying to get our builds to work on Macs.  However, we found this guide by Game Maker which helped us get our builds to work on other machines.  We adapted this guide into our own step-by-step process.  Hopefully this can help any other developers deal with Apple’s “Fun”:

1. Let’s make our build by clicking Create Executable (CTRL+F8) and then choosing Package as Zip.
2. This will begin compiling the game with Xcode. Once this is done, this will create a zip (Archive) and run the game, as well as having the “Xcode” project handy, but we need to do a few things.
3. In Xcode go to Signing & Capabilities and then select the +Capabilities section. From the window that opens, double click on the Hardened Runtime option.
4. Of course, we’ve already created an Archive (which can be deleted), but now we need to create ANOTHER archive, by going to Product > Archive.
5. In Window > Organizer > Archives, we should see our build / archive we just created (probably two, but like in step 4, we can delete the older one). Click on the Distribute App button.
6. Click the Direct Distribution (aka Developer ID) option and click Distribute.
7. We will then need to Upload. The gods at Apple will notarize. This seems to go really quick, though they do say “less than an hour”. There is supposed to be a notification, but we have not seen this.
8. We will see our Developer ID status in the organizer window at the bottom right. Once this is ready, it will say “Export Notarized App”. Wherever we put this is were our app will be. We can copy and bring to our Steam upload process.

Other Notable Updates

We’ve had three streamers play our game so far!  It’s been exciting to see people enjoy our game.  We can watch these clips / streams at these links below (Content Warning: there is some language in these streams):

• KirbGoneFishin (just clips)
  • Going in guns a blazin to a fort
  • Bats attack in formation
  • Never fight birds in any game
• Guinnanth
• Pause and Effect

These playthroughs were invaluable, as it introduced a few bugs we needed to fix as well a few game play issues.  Luckily, we were able to fix / update the majority of the issues seen in these streams!

In fact, one bug we have been encountering for about 4 years was caught on stream, and I (Dan) was finally able to fix this bug!  We can see it here.  At 1:24:47, we burn ourselves, and then our temperature gauge malfunctions.  We were finally able to figure out that it was because the very first frame a fire spawns was incorrectly setting its percentage (how potent the flame is) to 0, instead of what it should be.  Percentages of 0 are assumed to be fires that are being put out / removed.  Well, if we happened to take burn damage on the exact same frame as we spawn a flame (that has a percentage of 0), our temperature becomes NaN (because we divide by 0, and this is how Game Maker does division by 0) and would break our temperature gauge permanently!

Below are some other notable updates:

• We added a fortune teller, a character than essentially tells the player what to do next, if they are stumped.

  

• Dying in the dungeon sends the player back to the beginning of the Dungeon.  That way, the player isn’t trapped in a boss battle they can’t beat and can stock up on supplies and items.
• As you probably saw, we made our trailer!  During the months of October and November, we added some hotkeys to make getting these shots easier / better, as well as disabling certain UI / HUD elements.  This will be inaccessible during normal game play though, because we’ve disabled keyboard cheats in our builds now.
• We finally got around to adding text to signs.  That way, if we get lost in the world, we can at least follow a road back to a town, or some other notable landmark.
• We added the Ancient Garden.

  

• Kennedy renamed all of our current NPCs to their actual names.  I (Dan) was currently using names like Grandma NW, so I’d remember where these characters were located / what dialogue they have.  It has been quite different to see these characters with names!
• We fixed a major bug with our RampTile (an invisible trigger that increases / decreases what layerDepth we are on). There was an assumption that the point of a mask / hitbox will always be INSIDE of the rectangle.  Well, our character’s swimming mask is NOT inside and the assumption was off (and therefore not getting off ramps properly).

Conclusion

As you can imagine, this month has had an extreme amount of polishing and fixing.  So much so, that in our notes for writing this post, we ended up throwing away roughly 3 pages of features / bug fixes.  And this post is already quite lengthy!

Please wish list and share (especially our Kickstarter page) with anybody who would be interested!  We appreciate you reading and keeping up-to-date with the development.  Be sure to follow the socials and stay tuned for the release on January 3rd!

At last! It is time to finally reveal the official demo trailer for The Violets of Amicus™:

But wait, there’s more!  Our Steam Store Pages are now live!  Please Wishlist our demo and the main game!  We plan to release the demo on January 3rd, 2025.

We Need YOUR Help

This project will only be successful if YOU help share it with others.  We are going to be hitting the social media platforms hard in the next few weeks.  Whenever you see our posts, please share!  The more eyes on this, the better chances we have of being successful!

For those who have followed along and have helped contribute, whether with game assets, testing, or simply being supportive, THANK YOU!  We couldn’t do this without your support!

Our Pre-Launch Kickstarter Page is now Live! Please share with those you think will be interested!  The call-to-action is to use the “Notify me on launch” button.  Having these preliminary numbers will ensure a smooth start of our Kickstarter in February.

That’s all!  Short and sweet today.  We have more development updates coming soon!

These last few months have been extremely busy.  There has been a lot to polish as we prepare for our Kickstarter and Steam demo launch. This includes updating the design to our dungeon, watching testers in real time play alpha builds of the game, last minute additions and even redoing some of our concept art.  It’s been a lot — so much so that I (Dan) have spent basically the last month working overtime on the game (and that’s on top of a full time job).  I actually took the day off from my full time job today (Nov 8th) to catch up on some tasks, as well as write this overdue post.

There is one bad news item.  The original plan was to release the demo at the beginning of December.  That is no longer happening.  We sort have had January 2025 in the back of our mind, just in case (hence our post title 47 Weeks Remaining, and this post 8 Weeks Remaining).  Unfortunately, the “just in case” is a reality.  With everything going on (including playing through The Legend of Zelda: Echoes of Wisdom in two days on release!), and all the updates from testing feedback, there is simply not enough time between now and December to get all of that done.

However, the good news is that we do plan to release the demo at the beginning of the year, as well as we’re still on target to launch our Kickstarter in February 2025.  Keep these dates locked in!

Given that it’s been a bit longer between posts, and our rambling about how much there’s been to do; the good news is we have A TON to share.  Grab some coffee, or whatever, sit back and enjoy!

Pixel Art

At this point, it’s a given that Tony is always crushing it!  The pixel art requests have been all over the place as of late.  We’ve mostly been focused on the dungeon aesthetics, but these past couple weeks have been basically “polish everything”.  Since we have done a lot of polishing, we’re not going to re-share each of those items.  But just know even those this list is shorter than usual, the amount of art being done is much more substantial then it appears.

First on our list our some animals:

All of these animals we can spot in Castle Town, now named Jasper.  But, be careful attacking honks…

We also added shallow water.  It was needed in both our dungeon, and out in the wild.  A screenshot can be seen here:

Dungeon Art Updates

There’s plenty of design and functionality to talk about with our dungeon, but let’s first go over some of the new art additions.  You’ll probably notice a huge difference since our work-in-progress of our last post:

In our entrance, we encounter a new enemy, the Arrow Trap.  This enemy is resistant to most weapons, and is a pain to deal with.  Why don’t we show you what we mean!

This statue is constantly looking for targets to shoot and when it spots a target, the Arrow Trap will snipe with arrows!  These buggers take a lot of hits and can be quite the pain to deal with!

Designing the Arrow Traps to be “annoying” is intentional.  We eventually get the special item of this dungeon, the bomb glove!

We make quick work of that annoying enemy with our Bomb Glove!  And yes, the bomb and explosion are other art pieces we completed as well!

We also added a new moveable block type, as seen below:

These blocks are not only moveable, but they are breakable too!

Finally, the last art update to show, that is within the dungeon, is struggling to pickup something that is too heavy:

We added one more frame in the animation, if the object is too heavy.  This was to help players make the connection that “this is indeed too heavy”!

Text Proofing / Content Updates

Not only is Christina our Social Media Manager, but she is also our proofer of our games’ text.  Christina went through ALL of the text recently, providing proofing and content updates.  This was quite the endeavor, especially because it’s not just “going into Word” and making these edits.  She has to use a special tool we’ve created to make these edits in!

We wanted to share a new scene that happens immediately after the Remembrance Ceremony.  Kennedy has been working on writing these scenes, as well other story-driven elements in the game.  SPOILERS – this will spoil the introduction to the game.

You may have noticed that some words are in a different color.  This was another feature we added (special thanks again to Hyreon) to Draw Container, the open source text engine we wrote being utilized in our game.  Text that is between the * character in our text file will be interpreted as “emphasize this”.  This lets us be strategic in showing the player what words are most important to pay attention to, and helps those mashing the B button to at least “get a sense” of what is being communicated.

Finally, we’ve been updating game code so that words that get injected into the text. For example, given this line “You have 5 Weapon Scraps. Which inventory’s capacity would you like me to increase?”, the 5 and the Weapon Scraps are variable, and should have the correct plural form applied.  This meant going back to elementary and remembering grammar rules, rewriting functionality to apply the right plural form for words, and accounting for things like one item (i.e. not making it plural), zero items, and weird edge cases with the English language.

Music

Eugene has been crushing it on the music front!  You may have heard the cave theme in the videos above show casing the updated art in the dungeon.  This theme is intended for the cave, but we are repurposing it for the dungeon, for now.  We’re hoping to update this by demo time, but that might be a tall order, given the amount of music we are currently working through!

The other main track we’ve made is the fort theme.  Give that a listen below!

As always, we distort the quality a little, for security.  But this should give a good idea what the vibe is that we’re going for.  This is the day theme, and when the enemies haven’t noticed you.  When the enemies do notice, the energy picks up!

Concept Art

As mentioned in our previous post, we’ve begun hitting social media.  With that, we presented some of our concept art for the game.  Some of the reception was mixed, and many were confused by the type of game The Violets of Amicus™ is.  Many didn’t realize it was a pixel art game.  This was unfortunate, and we ended up having to do some last minute concept art in our pixel art style.  Given that Corinne is not a pixel art specialist, and that Tony was already at capacity with sprite work, we contracted Marcus Dewdney to help us out.  He did a great job, and what you see below will be on our social media headers / promotional art on Steam / Kickstarter moving forward.

We’re hoping this alleviates some of the confusion of what type of game we are making!

Auto Merge Feature

One of the main features of our game is the ability to merge degraded weapons into better weapons!  This works great, but after a few hours of gameplay, can become tedious and redundant.  We were well aware of this, and have always been planning a auto-merge feature.  Well, we finally got around to implementing this feature and artwork.  Check it out below:

By pressing in the R-Stick, the weapon that we are holding will automatically be merged with weapons of that type in its list, circumventing the inventory menu.  However, it is still useful to auto-merge all your weapons in a list.  By going into the inventory menu, and pressing X, we can auto-merge the entire list!  This will help the gameplay feel snappier after the novelty of merging has wore off and the player understands the concept.

Testing

We’ve currently hired two contractors for testing our game.  Testing is a critical part of game development, and honestly, we may have started this a bit late!  Luckily, our testers are doing a great job finding all sorts of issues, so that our audience won’t encounter them.  Here’s a screenshot from a bunch of issues we fixed from their testing:

A lot of our time in the month of October has been spent taking our testers findings, determining where the bug is, and then squashing it!  It’s great, we end up squashing one bug, and two more appear :D.  This is also an attributing factor as to why we are delaying the demo.  We want the best experience for our players, and we believe we get one good first impression, so we want to make it count!

Along with our bug finding testers, we have also had several people play test our alpha builds.  The intention of these tests was to make sure that the design of the game works (as oppose to looking for bugs / crashes).  This was super helpful, as we were able to see what did / did not worked with players in real time.  Another part of the reason we are delaying the demo is because the feedback we were receiving, especially on the dungeon, was that it needed a little more thought and care put into it.

For example, the 2F Rafters, everyone complained that the holes were too forceful and that it was cumbersome to traverse up there.  We eventually settled on two things:

1. Making the holes a little less forceful / adjusting the speeds when interacting with the hole.  But we have to be careful, because not enough force will cause people to “cheat” and run through the holes.
2. We made the 2F top speed slightly less.  Once we adjusted this, we heard no more complaints.

Another interesting scenario that came out of play testing was one player ended up pseudo teaming up with the Violets.  As mentioned, the Violets have no concept of good or evil.  Therefore, the Violets will attack other enemies.  A resourceful player ended up luring the Violets into multiple enemy camps (which is intended).  However, the Violets kept on spreading, and spreading, and spreading.  Ultimately, the goal is to destroy ALL the Violets.  Given that this is a semi-open world, and there being no guard-rails on the Violets, it would be almost impossible to find all of these “loose” Violets that have multiplied.  Therefore, we put a “better limit” on how these Violets are able to spread.  It was still very funny to watch and observe in real time!

There were many other issues / features that came out of testing / real time play sessions, and will be elaborated on in the Other Notable Updates section…

Other Notable Updates

Oh, I guess we are actually at this point!  This section is actually pretty large, and will break it down in a digestible way.  Some parts of it will be technical, while other parts will be more practical.

Dungeon Map

Another feedback item we got from testing was not knowing what rooms we had been in for our dungeon.  Therefore, we quickly added a simple map feature, that can be improved upon post-Kickstarter:

The rooms that are darker are rooms we’ve visited, and the rooms that are lighter are rooms we still haven’t visited.

Dojo Master Skill Tree Overhaul

We finally got around to updating the interface for selecting what skill you want to have demonstrated / mastered.

We had a few suggestions that we’ll probably implement before the Kickstarter, that being adding better names and descriptions of these skills.

Activation Bug

One bug our testers were uncovering was our NPCs would appear under the ground, or in other odd places.  I (Dan) looked and looked and could not figure out what was causing this problem.  Then one day, I was showing Kennedy a new feature and she happened to stumble upon a crash I hadn’t encountered in three months, where the first log in the dungeon would start moving and eventually be unloaded.  The first log can never start moving until a certain event happens, so this was strange!  Well, the problem was that we were talking to Ellixsis on the EXACT frame we were unloading / loading zones.  Lucky Kennedy!

When we talk to NPCs, we go into a placeholder state, which essentially takes a snapshot of all the instances in the scene, unloads them, and draws the current frame of the instances’ animation, essentially “pausing” the game while the player interacts with the textboxes.  The problem that was happening was if we went into placeholder state while we were concurrently loading the new zones / instances, we could get in a state where the newly loaded instances would be in their actual form, but should be in placeholder state.  This ended up being because of a cached variable not being updated properly.  In the case of our log, it had turned into its real form, not being blocked by the event that was in its placeholder form.

Game Design

As we observed players playing our game in real time, other design notes were made — whether problems with certain systems, or just things that needed to more clarity.  The dungeon was a major part of this, but we’ve already discussed the dungeon quite a bit.  So for now, here’s a screenshot of a bunch of issues related to the dungeon we addressed.

One problem that arose was when the music is muted / low volume.  Ellixsis sings, which is on the music volume.  If this is turned down, the player can no longer hear if they are getting closer / further from her.  Therefore, we added music notes to show the player the direction of where she is located, as well as showing them more frequently the closer you get.  Pair this with the music, and the system has been much improved!

We also updated our interactable system.  When people get done play testing, we always ask “what do you like about the game, what do you not like about the game, and did you have fun?”  We always stress to people that they’re not going to offend us by not liking something.  Truth be told, this interactable system was something I (Dan) did not like about the game.  The problem was that interactions were based on a priority, instead of how one would instinctively think it would work, by the distance we are from the interactable object.

This was mainly due to how we implemented the system many, many moons ago.  Long ago, we used to only interact with one thing.  So, we threw that check / logic in Asteric’s main loop.  Then, we interacted with another thing, and put that check / logic in Asteric’s loop.  Eventually, this became a list of if this object, or this object, or this object, etc.  This was a pain to deal with from a programmatic standpoint, but also a pain to deal with from the player’s side because if that first object became “to pick up something”, but the intention was to “read a side”, then we’d pickup the object instead of reading.

The fix was to refactor this system so that it looped through the entire interactable list instead, but sorted this list based on the distance from Asteric.  There’s a little more going on under-the-hood than this, but it’s essentially what we’re doing high level.

One final item related to design feedback was balancing the game.  We noticed that enemies may be too difficult.  We weren’t going to change the difficulty of our enemies, as we worked too hard on that.  But, what we could do is make them spawn with weaker weapons.  We adjusted the formula for computing what level rank weapons an enemy spawns in with.

In the same vein, we also decreased the maximum ranking starting out from E+ to E.  One might think “wouldn’t that make the game harder”?  And, in a way it does.  However, part of the formula for enemies determining what level rank they should have is based on the ranking the player has.  It’s based around an average of all the player’s weapon ranks (a little more involved, but a good summary).  With the starting rank lower, it actually makes the enemy’s weapon rank less, making them do less damage, and therefore, making the enemies easier.

By making the start rank to E, we also made merging a F + F weapon become an E- instead of an E.  Normally, weapons of the same rank would rank up a full letter.  However, F ranked weapons shouldn’t really be considered a “letter” rank, and more trash.  Therefore, trash + trash = lowest quality not trash, i.e. E-.  One might think “wouldn’t that also make the game harder”?  And this part does make it a little more challenging.  However, this design balance puts a bigger emphasis of the early game to “always be merging”.  Therefore, a resourceful player will be wanting to merge their weapons to E as quickly as they can.

It should also be noted that the Soldier enemies were all designed around the damage output of E ranked weapons, many, many moons ago.  All-in-all, these balances are to help make merging more prominent and making enemies starting out easier.

Bullet Points

There are many, many more things we could list here.  But, we don’t want this section to grow larger than it already has, and I (Dan) tend to make Other Notable Updates way longer than it needs to be.  Therefore, we’ll list the remaining bullet points that don’t fit anywhere else:

• We are now reading ALL buffers as Float 64, to help with desyncing of our playback / recording input.  We’ve had less issues with this tool since!
• Weapon Duplication Bug – one of our testers was essentially button mashing, perfectly, to get our weapon animation instance to duplicate.
• We added many updates with projectiles, whether shooting into a roof around a layerDepth trigger, or if the projectile spawner’s collision is within a wall, the projectile correctly spawns not in the wall.
• We fixed an issue where if Asteric dies, he kept moving (not visible to the player), and could sometimes move far enough to trigger the load / unload zones (i.e. a similar situation to the aforementioned activation bug).
• We fixed a softlock (i.e. the “black screen of death”), where we weren’t removing weapons properly after the Remembrance Ceremony, and instead removed Asteric, permanently!
• The B button now cancels a drawn bow.
• We added Violet Leaves in the inventory, showing how many more needed to rank weapons up.
• We made clouds invisible during night time.
• We added SFX when a weapon of F rank is used, to help communicate to the player that they are using bad quality weapon.  This SFX is a rubber squeak toy, which we are still in the middle of refining so it doesn’t become obnoxious.
• We tried to update to GMS 2024.8.  However, we encountered this bug.  We were able to work around it, but eventually downgraded back to the February build because of collision issues.  Ugh!  This might be the build of Game Maker Studio we stick with for the demo.

Conclusion

Believe it or not, this post doesn’t even cover the last two weeks!  There’s still a lot coming up in the next few months!  We appreciate you reading and keeping up-to-date with the development!  Be sure to follow the socials and stay tuned for a few updates in December!

 

As mentioned in our previous post, with the amount of time that had past since our posting, and the amount of new content completed in the timeframe, we decided to break our posts into two parts.  In this second part, we focus more on the behind-the-scenes elements of the game.

Concept Art

Corinne was tasked with three pieces since May:  Asteric, the hero; Minhaga, the unhinged; and our social media cover photo.  Below are these illustrations:

We wanted to pose Asteric in an action / heroic pose.  Asteric is the hero after-all.

Minhaga eventually becomes the villain in our story.  You’ll have to stay tuned to find out how and why!

The last task was for Corinne to make a collage that included all of the concept art so far.  When she sent this to me (Dan), I was super impressed with how well it turned out.  We’re super excited to start using it for our social media pages.  Speaking of which…

Social Media

We’re excited to announce our newest member of the team, Christina Lange.  Christina is a freelance marketing guru based in Ohio with a few projects she oversees and has published six novels under a penname.  She is going to be our social media manager and is currently creating all of our social media pages as well as getting the graphics prepped for them.  We are excited for how she will bring eyes to the project.

Speaking of social media, yes, we are on those now.  If you are interested, please follow us on these platforms:

Composer

In our May post, we also mentioned that Tyler would be stepping down from his role of composer on the game.  Since then, we were searching for a new composer to fill his shoes and we’re excited to announce our new composer, Eugene Fortier.  Eugene is a guitarist and composer who plays with a large variety of groups in different professional settings.  He is going to be taking over where Tyler left off, updating older tracks and composing new themes as well.  We are excited for what his talents will do for the project.

Eugene has already been hard at work composing a new shop theme.  Below are a day and night version:

Shop Theme Day

Shop Theme Night

Conclusion

There are some exciting things on the horizon as we are a few short months from the release of our demo and our Kickstarter.  Please follow us on social media for immediate news, and subscribe to our blog for more detailed summaries!

Given that it’s been a bit longer since our last post, this post will be a part one of two, since the amount of content that has happened since our May post is more than usual.  In this first part, we focus on our progress on the first dungeon of the game.  If you couldn’t tell by the title, this dungeon’s theme is an ancient temple that was abandoned.  Over time this temple was renovated into a sawmill.  Then, as monsters began emerging, the sawmill became abandoned as it was overrun.  There is some interesting lore here that we can’t get into quite yet, but we’re hoping it’s enough to keep you interested.  Let’s get into it!

Pixel Art

These past few months have been mostly focused on the Velarian Soldier / Dojo Master / Ancient Guard sprites.  However, before we get to those, Tony also finished up the Skeleton animations during the latter part of May.  Below are some of those remaining animations:

We decided to showcase a little fight with the skeletons out in the wild:

We also worked on a few compasses and icons.  Below are some of those sprites:

Now the aforementioned Velarian Soldier / Dojo Master / Ancient Guard sprites:

The Knights have taken up the majority of June and July.  Tony did a great job on all of these animations, and we’re sure he’s ready to move on to other pixel art!  Speaking of other pixel art…

Jawab’s Ancient Temple and Sawmill

The month of June I (Dan) mostly worked on the Forest Dungeon concept.  There was a lot of code updates so that we could build dungeon rooms and other dungeon concepts out much faster down the road.

One of our major updates was to our sequence system.  We added an abort_sequence function, that would stop a sequence from running entirely.  For example, let’s say we stepped on a switch and the pillar starts moving down.  However, this switch must have some weight on it in order for the pillar to stay down.  Typical games stop the players movement while a sequence is panning the camera to show the result of stepping on the switch.  However, in The Violets of Amicus™, the player is still free to move while the camera is panning.  Because of this, the player could theoretically step off of the switch while the pillar moving down and sneak through it before the animation begins of the pillar moving up.  Therefore, it was important to add something that would trigger the stopping of the animation of the pillar to prevent the player from “sequence breaking”.  Hence, why abort_sequence was necessary.

The good news is this can be reused for other sequences as well.  For example, perhaps we want to “skip” cutscenes outright.  This function gives us the possibility of doing so.

As mentioned, there were several other updates that happened as a result of the Forest Dungeon.  However, we won’t go into all of the details, and a screenshot will have to suffice:

Finally, without further ado, let’s show off some screenshots of our Forest Dungeon concept:

Some of the art in the screenshots are still a little rough around the edges, but it should convey the concept of an abandoned ancient temple, renovated into a sawmill, then became abandoned as it was overrun with monsters.  We have the general structure / puzzles mostly figured out.  However, the details and layout will change as we add more art and get some play testing in.  We’re happy with the results so far!

Below is a short clip of the Dungeon in action:

One other item we’ve worked on is a second floor (2F) concept.  This is still an early prototype, but we’d thought we’d share the progress thus far:

If Asteric were to go off the tile pattern, he would “slip” and fall into the 1F.  Therefore, we added a concept that would make an interactable object fall to a lower floor.  This will obviously add some old school puzzle elements to our dungeons.

Ancient Guard Boss Fight

Finally, here’s a video that combines the two main elements so far — an Ancient Guard boss fight in our Forest Dungeon:

We wanted to include this in our previous section with the Knight, but it also spoiled the Dungeon aesthetic before it was introduced, so we decided to wait until now in our post.

The Ancient Guard is proficient in defense, being able to parry offensive attacks, or dodge threatening blows. The Ancient Guard is also a melee specialist, skilled with Balanced, Agile and Heavy weapons.  The Ancient Guard understands that Heavy Weapons > Balanced Weapons > Agile Weapons > Heavy Weapons …, and therefore switches out the melee weapon based on what its enemy is holding.  This makes for a great combat challenge, testing the player’s mastery in one of the central mechanics of the game: switching weapons.

Title Screen

If June’s task was working on a Dungeon concept, then July’s task was working on the Title Screen.  One might think “a whole month to work on a title screen?”  And one would normally be right.  However, it is a little more involved.

The main problem is that before the addition of the title screen, the game would simply boot into the world.  This meant that all of the sprites, enemies, tiles, walls, etc. were loaded and then parsed into their appropriate sections.  This would take a few seconds to thirty seconds, depending on the room size and how fast the computer playing the game is.  If we add a title screen, we don’t want to wait to load all of the aforementioned assets, especially down the road where the player could choose to begin a new game or load a previous save.  It would be a lot of waiting to then rewait again.  Therefore, we want to put a title screen before all of this loading.

This is where the problem begins.  If we put the loading screen before everything, that means we need to figure out a way to only load the absolute necessary elements to “boot” a title screen.  Therefore, this means a lot of gutting, rearranging, and refactoring — especially around assets that are used in both the title screen and the game world.  For example, our SoundBoard object, which is responsible for playing music and sound effects, would be needed for both the title screen and the game world.  So, we need to figure out a way to move that into a boot function that would be required by both.

As we were building out the functionality that abstracts our instances to load after our title screen, we recognized that this could be abstracted out even further, that would meet the goal of a post-Kickstarter task — only load sections surrounding the section we are in, and then unload the sections not needed.  Right now, we are loading all of the sections into memory.  This is fine, for now, as the demo will only have about nine sections.  However, the real game will have 81 sections, and this would simply be too much.  Nine sections at any time is about the maximum we’d want loaded into memory.  Therefore, we decided to take our abstraction a step further.  We decided to save the section instances to a file, so that could be “streamed” later.  Right now we are still loading / streaming all of the instances (as previously mentioned nine sections isn’t hurting anything).  However, with the instances loaded to a file, we could easily down the road set this up to stream from a “section” file, instead of everything at once.

There were several other problems that needed addressed, but we’ll simply bullet point them here, for the sake of interest:

• When creating instances in our game rooms, Game Maker Studio creates a constant that can be referenced in game code, to uniquely do something with that particular instance.  We are making use of this in several place.  With instances being loaded from a file, this constant is no longer the same reference.  However, we got around this problem by writing a mapper.
• Many of our global objects were being referenced by its object identifier instead of its instance identifier.  Either works, but the instance identifier is faster.  Since our global objects are being referenced thousands of times per frame, referencing our instance identifiers through global has increased performance.
• We moved elements of obj_Camera into _SuperGlobal, which in a way acts as a display manager now.  This was necessary since we don’t need a camera on the title screen.
• Our “No Controller Dialog” was needed in the title screen, since we can be in a state where the controller is not recognized on the title screen.  We ended up moving this text renderer in our obj_HumanInput object, so we didn’t have to maintain two different objects.
  • As an aside, we now automatically pause the game if the controller gets lost during gameplay
• Our ugly options page in game also needed to be utilized in the title screen.  Therefore, we overhauled our options page, and make it functional in both the title screen and the pause screen:

  

With all of that out of the way, we were able to implement our title screen, which can be seen in this video clip below:

There’s a few elements (e.g. the buttons and logo) still to polish up and after the Kickstarter, we plan to add some sort of eye-catching animation.  But it is functional and has a good foundation to build off of later.

You may have noticed a ticker at the bottom.  Our idea here is those who back the project at $30 (actual value TBD) will get their name on the title screen!  Those who back the project at $60 (actual value TBD) will have their name at the start of the list (i.e. their name shown first).  These lists will be randomized so every time the game boots up, it won’t be the same list each time.

Other Notable Updates

Believe it or not, this section also contains quite a bit of content!  We’ll try to keep it brief and concise though (and sprinkle in a picture here and there).

Playback Input / Recorder Fixes

As you may recall, we have implemented a input recorder / playback system that records a players inputs and then afterwards, can play them back exactly.  This makes debugging easier, as we get can get to an exact state if a game crashes, as well as simply watch a players gameplay session.  However, we were encountering some errors.

After a good solid week, we realized our problem.  The numbers that our RNG creates uses Game Make Studio’s real number, which are double for those who are computer science geeks (for those who are not, it can loosely means double precision with the amount of decimal points than that of a float).  I (Dan) think this must have changed in the update to removing 32bit support in Game Maker because these numbers used to be float.  Anyway, long story short, we were storing these numbers as float instead of double.  This generally works fine, but after a while, the loss of precision of these numbers would eventually cause unexpected behaviors and crash.  Storing as double seemed to fix the issue and the random (no pun intended) crashes we were getting!

Mac OSX Epsilon Issues

Another related floating point issue!  Different architectures handle decimal points slightly differently.  Because of this, to support “identical” behavior between platforms, Game Maker Studio has this thing called Epsilon, which when comparing if two numbers are equal, it actually loosely compares them behind the scenes, and if they are within the epsilon range, then they are equal.

We had an issue where we were getting an infinite loop on the Mac platform.  This is because the Mac was incorrectly calculating arctan due to some rounding issues.  Therefore, we set the value of epsilon to be a bit bigger, which fixed our issue.

Map Screen Polishes

We also updated our map screen to be a bit more polished.  Below is a screenshot:

This uses some of the updated interface items / layout from our UI / UX project mentioned back in our March post.  There’s still a bit of room to add more things, such as objectives or maybe even floor markers for our dungeons!

Bullet Points

• Our can_hear_it system was crashing randomly and predictably.
  • The predictable one was easy (since it was, well reproducible) — we forgot to check if a property existed on a mass object, like obj_LongGrass (which can produce sound when cut).
  • The random issue ended up being found because of our fixed input recorder playing back to the exact frame it crashed.  It ended up being from an enemy taking damage twice which resulted in death.  For example, let’s say an enemy took damage from a stuck arrow, while also taking damage by removing the arrow.  The first damage would destroy the enemy and cancel any sound effects that would result from the enemy.  The second, however, would add a null owner to the sound effect.  When another enemy was trying to “hear it”, it couldn’t find the already dead enemy.  We fixed it by not adding sound effects to already destroyed objects.
• We made some text revisions to our intro cutscene.

  

• A bit lower level, but we are now using sprite names for our sprite layer tiles instead of indexes.  Whenever we added / removed a sprite from our library, these numbers would get all out of whack, and would return gibberish tiles the next time it was loaded.  We are now storing the names of the sprites (since these don’t change) instead of their indexes.
• Another lower level item, but also important for performance!  We found a few places that were not cleaning up dynamic resources, such as mass sprites from fromTile walls, obj_RampTileMass and obj_WaterTileMass.  We also weren’t removing the audio after using audio_create_stream for our music tracks.
• When using the Quick Switch menu, when the joystick would snapback, it would cause missinputs.  We alleviated the snapback issues by only checking for inputs every other frame.
• We buffed the water rod in rain, as well as added some other buffs and nerfs for elements.
• We added an NPC Sitting concept.  There currently isn’t any animation, this was more to fix the functional problem.  We set the NPC that are supposed to be sitting in-between a chair and the table.  If an object gets stuck in a wall, it will try to push it out.  Well, since the chair and table are both considered walls, on one frame the NPC gets pushed up by the chair and the next frame the NPC gets pushed down by the table, causing an endless jittery look.  Consequently, by fixing this, this also fixed an abundance of memory getting used as well!
• Finally, we tried to update to the latest version of Game Maker Studio, 2024.4 and then 2024.6.  However, 2024.4 had a bunch of collision issues introduced to it, that got resolved in 2024.6, but then 2024.6 introduced a problem with loading instances from our stored file explained in the title screen abstraction section.

Conclusion

We know that was a lot of material to go through!  If you stuck with it until the end, thank you!  Part two will be a bit lighter on the reading, and will hopefully be out by the end of the month!

 

The last couple of months have had some highs and lows in the development of The Violets of Amicus™.  The highs being that we’ve accomplished quite a bit; a lot of new art, three new sections to explore, and loads of new / updated functionality.  The lows being some bad news about our composer, spinning our wheels with Steam and Apple, and just a general feeling of being behind.  I (Dan) hope that as I write this post, that this will get my hopes up in that the good outweighs the bad and the bad is just a temporary state.  Anyway, let’s get to it!

Concept Art

Corinne was tasked with two pieces since we last posted: Ellixsis and the Dojo Master (working name).  Below are these illustrations:

Ellixsis, AKA “Map Girl”, is a quirky lady who finds herself lost much of the time.  However, she as taken it upon herself to chart the land of Velare.  Ellixsis, upon a successful trade, will chart part of your map, as well as trade compasses that point to valuable locations on the map.  Don’t worry, finding her will be mostly straight forward, because she sings a lot, and we can simply follow her voice to get to her location!

Dojo Master (working name) is in charge of training the soldiers of Velare.  Dojo Master’s role in this quest is to train Asteric on different skills and moves that the player can learn throughout their adventure.  In order to master these skills, the player must prove their worth by trading Skull Pendants, which are found in enemy forts.

Pixel Art

Tony has been knocking it out-of-the park with the quantity and quality of the pixel art!  First, will showcase Ellixsis pixel art:

A continuation from last time, the Advisor character, now known as Meminitus, also received pixel art:

We also began work on a Skeleton Enemy, a Soldier type of enemy that appears at night:

Intro Cutscene

One of the major items we worked on the last few months was the Intro Cutscene.  We were able to make heavy use of our Sequence system introduced in this post.  We also had to add a couple of custom animations for Minhaga, King Archon and the Advisor, to make the scene complete.  We have about 90% of the cutscene complete, with a few polishes, writing tweaks, and art animations to make.  However, we are pretty happy with how it is shaping up and would love to show you all!  The cutscene takes place within the game engine, and is not a separate video file!

SPOILER — this will spoil the introductory story of the game.

Chest Minigame

Another one of our tasks was to add more things to do in Castle Town.  Though we still have more tasks to complete here, we were able to get the Chest Minigame complete.  Here’s a clip of the game in action:

Updated Quick Switch

One feature we’ve had in the game for a while was the ability to quick switch.  The original way of doing this was pressing and holding the R-Stick button, and the using the D-Pad to quickly switch our weapon.  This worked good in my opinion, and every player who’s played with it so far said so as well.  However, in saying that it made sense, we never saw anyone actually use it in testing.  Therefore, we decided to overhaul this completely, with something more modern.  Our UI / UX contractor, Josh Morrow, also designed an interface for us:

We were able to implement this entirely with just the R-Stick.  As the game scales, if we need to add other buttons, as shown in the mockups, we’ll do so.  But right now, we want to keep it as clean as possible.  Below is a video of it in action:

Originally we had a cursor icon that represented where we were in relation to the menu.  But in our testing, we found players were stumbling over trying to get the icon on the circles, when in reality, the functionality just checks if the joystick is pressed in a certain direction and threshold.  Therefore, we removed it and players were able to understand its concept much more easily.

Hardware Updates

In our previous post, we briefly mentioned that we hired a QA contractor in charge of hardware.  We were able to knock out quite a few things:

• We determined the minimum specs for the game:

  

• We resolved resolution / scaling issues
  • Found an issue specifically with MacOSX not setting window resolution correctly
  • Fixed toggling fullscreen
• If the window loses focus, we decided to bring up the inventory, essentially pausing the game
• If overclocking happens, pop up alerting stating it should be running at 60 FPS
• We fixed fonts in MacOSX not showing up occasionally

New Sections

We added three new sections to explore:

1. A farming section, full of vegetable fields, grass, barns and horses:

   

2. A starting forest area, with many trees and enemies:

   

3. A new work-in-progress town, that we are calling Jawab Town for now:

   

Jawab Town is more of a small village nested in the forest of Jawab province.  This is the location where the player is instructed to go.  However, the bridge that serves as the entrance to the town is currently unstable and needs rebuilt.  The player must travel back to Castle Town to find the Carpenter Brothers to fix.  The point of this sequence is for the player to realize that:

1. The journey back is full of resources, such has hidden treasure, better weapons and even finding Ellixsis to fill in our map.
2. Castle Town is important, and going back often is recommended.  Especially because we can learn new skills from the Dojo Master, or stock up on items and food from the town shops.
3. Once we come back to Jawab Town, we’ll quickly find there is an easy way to fast travel.  The pain of “walking back” should make fast travel even more rewarding.

Composer Updates

Tyler, our composer, has decided to step down from composing.  We are extremely appreciative of all of his contributions to the project and will miss him dearly.  We believe Tyler is an amazing composer and hope that he will continue to use his skills and abilities.  There was no hard feelings here and if Tyler ever decides to come back to the project, the door is always open.

The news of Tyler leaving did sting for a bit.  We haven’t fully recovered from the bad news, but we believe there is a light and the end of the tunnel.  And no, it is not a train!  We will keep you posted on the composer front.  With that said, we don’t have any new music to share.

Steam Updates

We previously mentioned that we plan to release our game on Steam.  These past couple months we’ve become a Steam Developer.  We have had semi-regular meeting with our advisor to show us the ropes of Steamworks.  We are very grateful for his knowledge and expertise, as it has saved us on a lot of upfront learning!

We currently are learning about test branches, so we can start moving our builds to Steam for our testers.  We’ve also created our application (i.e. game) and have a very rough store page in place.  Hopefully in the next few weeks we can get all of these things figured out and resolved.

We’re currently stuck on getting our game to launch from Steam currently.  It seems like we make some progress on this front, just to get stuck on another issue.  It’s been a lot of wheel spinning, but we believe we are very close.  Luckily, we started this process early, so that this is more of an annoyance, rather than a stressful “all hands on deck”.  Nevertheless, the extra amount of time figuring all of this out has got me (Dan) feeling a bit behind on all of the other tasks that are needed for the demo.

However, after a bit of wheel spinning, we were able to upload our build / game to Steam, which was a big win.  Once we were able to figure this out, we went the extra mile and added an open-source script to make our deployment process streamlined and faster.  We are hoping this script can help automate other people’s process as well!

Other Notable Updates

One other major game mechanic / feature was adding the ability for our Weapon Shop Guy character to roam in the world.  To keep our memory from leaking, any dropped weapons eventually get “cleaned up”, or deleted.  However, this didn’t seem very organic.  Therefore, we thought “what if there was a character that was responsible for ‘cleaning up’ the dropped weapons, by collecting them and taking them to a shop”?  This is where the Weapon Shop Guy character was born.  The only feature we still had to implement was making him appear.

Currently, when a dropped weapon gets queued to be “cleaned up”, it stays in the queue for two minutes.  After two minutes, if the weapon was to be destroyed, we instead move the weapon to the Weapon Shop Guy’s shop, and then spawn the Weapon Shop Guy near our player.  The player can’t barter for any dropped weapons outside the shop, but the Weapon Shop Guy’s ability to expand your inventory is very useful out in the wild.  Seeing the Weapon Shop Guy out in the wild is also a reminder that he is, well, doing his job, collecting lost weapons!

Below is a list of other notable updates:

• We updated the weather percentages for our different sections for the game
  • Our advisor was mentioning how it was raining a lot.  After looking into the probabilities a bit, we realized that it would indeed go into a rain state more than desired.  We changed these probabilities so that it rains less often, for given areas that aren’t supposed to have that climate.
• We updated to Game Maker 2024.2
  • In doing so, we realized that pointer_null is treated differently with the json_parse / json_stringify methods, and had to update our code to reflect this.
  • We also realized there was a new function called variable_clone, which we essentially are now wrapping our deep_copy around.
  • This updated reindexed objects to be alphabetically, instead of when they were created.  This messed up our instance order, which caused quite a bit of refactoring.  We decided to add an object called _SuperGlobal, which comes first alphabetically, and is guaranteed to run first.  We can then use this for our other controller objects (such as obj_Global and obj_Camera).
  • Now there is an update for Game Maker Studio 2024.4 😄.
• We fixed an issue with ai_get_random_spot, which wasn’t taking into account layerDepths properly.  Now our KnightGhost won’t “all of the sudden” stop moving randomly.
  • This was discovered when we were adding functionality for our aforementioned Weapon Shop Guy roam feature.  We fixed two birds with one stone!
• We refactored the camera load zone system into multiple frames
  • When we were creating the chest minigame, we realized a bug in the order of loading / unloading.  The building controller was getting loaded after our NPC object, and therefore couldn’t compute the “prize” correctly.
  • Therefore, we reordered the zone loading so that the order is preparation, tiles (load and unload), unload old instances, unload old dynamic managers (buildings), load new dynamic managers (buildings), load new instances, clean up / move walls zones.
• Added cutsceneSprite that we can reference that takes priority over the other sprite actions.  For example, if the engine is having the NPC walking, normally the animation would be walking as well.  However, if cutsceneSprite is set, and the NPC is walking, the cutsceneSprite would take precedence.

If you have been following along, you’ll recall that about a year ago we shared some bad news about the game name and our business name.  Well, if you couldn’t tell by today’s title, we are now able to rectify that post by revealing the updated name of the game: The Violets of Amicus™!

This project has had its ups and downs, and last year around this time was definitely a valley.  But today we stand atop of a mountain, proud of what we’ve accomplished so far, and excited for what’s to come!

February 2025 will mark the launch of our Kickstarter to fund the rest of our project.  To get there, we have a good amount of work ahead of us, but nothing that our team can’t tackle.  What we need is support and dedicated folks such as yourself to help get the word out to the masses.  A good start would be to direct people to this website!  Explain to them that The Violets of Amicus™ will be an action / adventure game similar to that of traditional 2D Zelda games.

The anticipated release of our demo is December of 2024, or January of 2025, available on Steam for Windows and Mac.  We plan to have a stand alone demo available as well (i.e. not through Steam), with some helpful guides for installation.  We also have a rough cut of the trailer complete, but this trailer will have to wait to be seen until the public demo is available.  We promise it will be worth the wait!

We Need YOUR Help

This project will only be successful if YOU help share it with others.  In the upcoming months, we are going to be hitting the social media platforms and getting pages/channels/etc. added.  When these are added, please like/follow/share with those you think will be interested in this project.  The more eyes on this, the better chances we have of being successful!

For those who have followed along and have helped contribute, whether with game assets, testing, or simply being supportive, THANK YOU!  We couldn’t do this without your support!

These first couple months of the year have been ridiculously busy.  As we prepared for this year, we knew we’d have more expenses in preparing for our Kickstarter in February of 2025.  Therefore, I (Dan) took on a second side project for a few weeks that would help offset these expenses.  Concurrently, we also added a couple of contractors that were assigned with one specific task, as we wanted to get these figured out sooner rather than later.  As much as I love working with others on this project, I didn’t realize that managing all of these pieces, on top of my full time job and side project, would consume so much of my time.  February ended up becoming one of the busiest months of my life.  To top it off, our dog ended up hurting his back, and one of our cars got into an accident that made it undrivable.

Despite all of the hurdles, we managed to get a lot accomplished in the past couple of months.  This is mainly due to the awesome team we have, crushing it, while I was getting crushed!

Concept Art

Corinne was tasked with three pieces since we last posted: King Archon, Weapon Shop Guy (working name) and the Advisor (working name).  Below are these illustrations:

On the Eve of Remembrance, King Archon’s son fell severely ill.  King Archon issued a decree that if anyone could find a remedy to heal his son, they would be rewarded beyond their wildest dreams.

Indeed, Velare has been rebuilt into a great land. The Withering did not succeed in our destruction. However, my hope is still fragile. The prince, my only son, fell severely ill on the eve of Remembrance. Surely you all have been informed about the Royal edict I made concerning the prince… If anyone can find a remedy to heal my son, they will be rewarded beyond their wildest dreams. Remembrance is a solemn holiday for us Velareans, and interrupting this is uncouth. But how devastating would it be if the future King of Velare were to perish! I beg of you, citizens of Velare… if anyone has a cure, please step forward!

– King Archon, interjecting during the Remembrance Ceremony

Weapon Shop Guy (working name) is an enthusiastic smith that is in charge of Castle Town’s Weapon Shop.  He is one of nine siblings, who are all brothers.  Ironically, all of them are weapon smiths, because it is the family business, but nobody in the family is really into weapons or fighting in general.  They are just really good at their craft!  Their job is to go around looking for lost or dropped weapons out in the field, and then to bring them back to the shop and make them stronger.

The Advisor (working name) is Velare’s royal advisor who is exceedingly well versed in Velare’s ancient history and society.  The Kingdom has always had a royal advisor that’s tasked with educating the king on kingdom matters.  Because of the Advisor’s eccentric style, most people, including King Archon, assume he is an archaic, senile, conspirator who wastes his time on myths and fairy tales.  One of the Advisor’s duties is to oversee Remembrance.

Music

One of the ideas we’ve had for a while is that when enemies come on screen, the music changes into a more intense version of itself.  We’ve finally began testing this theory with some great success!  Currently, in most places, we have a really out-of-place track that I (Dan) ran through an electric guitar through to test.  The proof-of-concept test worked well.  We then began replacing a couple of the bad electric guitar tracks with something real, and the proof-of-concept became a great addition to the game.  The seamless transition between the main track and the enemy track really helps sell the idea that something bad is onscreen, and that the player needs to do something about it!

Along with the enemy variations, Tyler has also been composing as well — mostly rearranging some older pieces we have had as placeholders.  Below are a few samples:

Castle Town Day

Castle Town Night

Castle Town Enemy

House Theme Day

House Theme Night

House Theme Enemy

Pixel Art

Tony has been crushing it as always on the pixel art end.  First, we decided to finish up the Minotaur animations:

When we added the Minotaur Shield Bash animation, we realized we forgot to finish the Reptile Shield Bash animations.  Below are those:

We were able to get much of King Archon and the Weapon Shop Guy’s basic animations done:

Features

The good news about preparing for a Kickstarter is there won’t be a whole lot of brand new features, as we are essentially polishing up the existing ones.  The bad news about preparing for a Kickstarter is that we are essentially making the game twice.  Therefore, much of these features that we are polishing will most likely end up getting repolished in the future.  That’s the nature of game development / releasing a demo!

What this means from a blog post standpoint is hopefully we can do a lot more showing instead of telling!  Which, projecting myself (Dan) onto the reader, is amazing, as I don’t like to read!

One of the first things we added in January was for NPC characters to essentially block the players path.  That way, the player can’t go into areas they aren’t supposed to reach yet:

One of the feedback items we received was in regards to trying to break a boulder or a crust with a weapon that is unable to.  Before, we were giving feedback that it was breakable.  We fixed this by adding some visual effects, as well as a new sound effect:

A major item we’ve been working on is making the Dojo teach the player all the different skills one can learn throughout their adventure.  We have completed all the ones that will be available for the demo.  Below is an example of a lesson:

A few months ago, we introduced the titular enemy, the Violet.  In the last few weeks, we had the ability for Violets to be in a dormant state.  As vicious as the Violets can be, they only attack when they are attacked.  We also introduced an easier Violet variation, the green variant:

Tony did a great job adding the dormant / non-dormant animations:

Updated UI

As you probably noticed in the videos above, we’ve overhauled our UI.  We hired a contractor, Josh Morrow, a seasoned UI / UX designer who has done many projects of his own.  There were a few things in our UI that we knew weren’t a great UX.  We had some ideas of our own, but we wanted to take a step back and have an outside perspective take a look with an unbiased / fresh pair of eyes.

Our main goal was to fix a couple of the painful parts of the merging mechanic of the inventory, but what we got was so much more!  We’re still in the process of implementing everything.  Most of the “so much more” parts will have to be showcased in an upcoming blog post.  But for now, here are a few wireframes that we were given, along with Tony’s beautiful pixel art enhancement:

Implementing all of this has been the task of mine for the last few weeks.  Most of it is implemented based on the wireframes, but there are a few missing pieces.  Overall, merging is going to be much more streamlined and easier for the player!  We reduced the “number of clicks” from 4 to 2!

The other important piece with our new inventory system was to make sure the player knew that weapons were merged, as well as understanding that their inventory capacity had increased for a given list.  Below are some animations that Tony created:

Mac / Resolution / Gamepad Updates

One of our investments was purchasing a new Macbook to test the game on.  One of the positives of Game Maker Studio is that theoretically you write your code once, and “it just works” on any other platform.  This generally would be true for our game as well.  Except, if we recall from our first post in 2023, under the Path Finding Part Two section, we built a C++ library to make path finding work much faster.  This was a DLL that only worked within Windows.  Therefore, the game would boot up, but our Soldier enemies would not know how to get to its’ target.  This is no good.

One of our other contractors these past few months was Hyreon, who helped take our DLL and turn it into a Mac version, called a DyLib.  Hyreon was able to figure out all the DevOps around Apple’s nonsense (e.g. Xcode) and get our game working on a Mac!  Below is a screenshot if you don’t believe us!

Ironically, the next topic we are going to talk about is the resolution and how we fixed it, and of course this screenshot above is slightly messed up.  Windows mode on both PC and a Mac still has its issues.  But, we managed to get resolution scaling to work properly in fullscreen resolutions.  We even went through the trouble of supporting 16:9 and 16:10 ratios (looking at you, Steam Deck)!  We noticed the resolution all messed up originally when we booted the game initially.  I (Dan) had admittedly only been testing on 1920×1080 resolutions up to that point, so we definitely wanted to spend some time cleaning that up for our frenemy, Apple and their weird resolutions.

Finally, when testing on a Mac, we realized that controller inputs were not all universally recognized.  The simplest way to explain this is the Xbox controllers (and XBox type controllers) use what is called XInput, where Nintendo, Sony, etc. use what is called DirectInput.  XInput has support for roughly 18 buttons, while DirectInput can support many, many more (e.g. motion).  XInput works natively on all modern Operating Systems, while DirectInput requires additional drivers and other nonsense to make it work natively.

Steam automatically makes our favorite DirectInput type controllers “just work”, which is a big reason why many PC gamers use Steam.  Don’t worry, we’re planning on release our game through Steam (more on that in a future post!).  But for now, if the player happens to play the game with a DirectInput device, a message will popup stating as much, and what to do to fix it.

Other Notable Updates

Despite what we said at the beginning of the post, we still managed to add a few other functionality updates as well:

• We’ve improved the ability for NPCs to find and stand in their starting location, if that is the intention of the NPC.
• Obviously one of the big things showcased in this post was the message box that NPCs use to talk.  Updating that dialog took a lot of refactoring, especially determining if the dialog is supposed to be for a cutscene (i.e. showing a portrait) or normal (i.e. showing a little tail).
• Since we had a few new contractors help, there were some things they found, in which we me made some improvements on.  Specifically, the beginning sequence, making it more intuitive on what to do.  We also moved some of the story exposition so there was less of a story dump right at the beginning.
• We updated to the latest version of GMS (2023-11).  And then this week, there was a new version released!
• We added a few more cheats, specifically for moving around and capturing game footage.
• Kennedy made her first round of text updates.  We built a little text editor, forking svelte-jsoneditor as a base.
• We hired a QA contractor in charge of hardware, making sure the game works on different platforms, as well as determining the minimum requirements for the game.

Conclusion

There was so much not covered in this post, that pretty much happened in the last week.  This may or may not involve the updated name / logo of the game, as well as a rough trailer.  Stay tuned!