Author: danieltjewett

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!

We wanted to give an update on the game front, since it has been a couple months since our last update post, excluding the previous post of revealing Asteric, Minhaga, King Archon, and the Kingdom of Velare.  Before we dive in, we wanted to quickly share about our experience at Cedarville’s Video Game Exhibition.

We got to meet / talk with hundreds of individuals interested / excited about the game.  We had between 10 – 20 folks play the game.  One, who played for 2.5 hours.  He went to classes and came back wanting to play more!  The experience was overwhelmingly positive and overall we’re more confident then ever that Violet is going places!  Thanks again for all of those who played and / or checked out the game!  We appreciate all of the support and making my (Dan‘s) childhood dream more of a reality!

And in case anyone who was at the exhibition is wondering… yes, we did do our drawing and Joslyn was the winner of the $50 Amazon Gift Card.  Congratulations!  Alright, now onto actual game updates.

Cedarville Feedback

One advantage of doing a showcase is watching people play in real time, which results in finding out all of the things that work, as well as the things that don’t.  We’re happy to say that of all of the features actually completed, most of it did work.  But there were a few things we have adjusted.

We noticed that people didn’t notice the lock gate in the very first room of the cave.  Once they obtained the key, they didn’t know where to progress from there.  We first made the room layout one tile smaller all around, making the locked gate more visible.  Secondly, since we wanted the player to learn how to pick up things in that first room, we decided to rearrange the random arrangement of rocks into an arrow formation, pointing at the gate.

The player will more instinctively check out the locked gate, finding out they need a key to pass.  Five minutes later when they get the key, the player will remember this moment and remember to go back.

Another Tutorial Cave item we addressed was learning the agile weapons.  We noticed that a player opened the chest and used the agile weapon once, then switched back to their balanced weapon.  Well the code, via the designer (i.e Dan), assumed the player would check out the agile weapon for five seconds and then globs would drop from the ceiling.  This assumption was remedied by adding agile switches to the wall, something we were planning on doing for dungeons anyway.

Now the player is forced to use an agile weapon to activate the switch, which in turn drops the Globs from the ceiling.  It’s much better designed and teaches the player more organically as well.

We also addressed four other smaller items:

1. We have noticed for a while that collisions with the agile weapon while facing left / right visually didn’t work.  It became more apparent while showcasing that this needed to be fixed.
2. Players would defeat the final enemy, which would drop their weapon, but right near a chest.  Dropped weapons had a higher priority of picking up than opening a chest, which was really frustrating for players.
3. After the tutorial, in the first loop sequence of the game, players (who we assume weren’t super familiar with Zelda conventions) didn’t realize they could push a block onto a switch.  We addressed this by teaching the player in three steps.  The first a simple step switch, which they will be lured to by a certain character singing.  The second, another step switch, but this time doesn’t function until a block is pushed on, which there just so happens to be one in eye sight.  The third, the original puzzle, but with a slight twist.
4. A dropped weapon would halt movement of a player from pushing / pulling blocks.  Much like the chest priority issue, this was frustrating because the only remedy was to pick up a weapon.  But, if the inventory was full for a weapon, the player would have to go into their inventory, drop a weapon, pick up the weapon that was in the way (which they probably didn’t want in the first place), and then continue pushing / pulling.

Castle of Castle Town

We decided to finally get around to finishing the art for the Castle and the Court Yard (where The Remembrance ceremony takes place).  We unfortunately didn’t have this ready for the showcase, but for those who remember the cutscene, this should look so much better now.  Tony did a great job, as always, fully realizing what we were going for.

Tile and Particle Updates

We also updated the rain / snow particles.  We got a lot of good feedback of showing the Violets in action in video form, so we plan on making this a regular occurrence.  Below are those particles in action:

We still need to adjust the depth of the particles, but overall, they turned out great!

We also worked on a waterfall effect, which can be seen below:

We still need to address that hardline seam between biomes, but that’s a task for a different day!

Overworld Night Music

Tyler is still composing from time to time. The reason there hasn’t been much done on this front is it is hard to compose for something when the art isn’t final.  Well, now that we have much of the art complete, we have restarted and are going in big.  Below is one sample:

Overworld Night

Map Updates

This is still a work in progress, but we made enough of a dent in this feature that it seemed worth sharing.  We added compasses to maps!  There are three types of compasses:

1. Compasses that function without needing a map for an area
2. Compasses that only work with a map for a given area
3. Custom Compasses, that can be set by the player

All compasses, by hovering over it and pressing A, can toggle a waypoint.  When a waypoint is on, the compass will remain on the minimap, albeit it on the edge.  We can actually see these functioning in the waterfall video above.

In the screenshot above, the chest that is currently hovered is a custom compass we set.  These can also be removed by pressing X.  Pressing A anywhere on the map that doesn’t contain a compass will bring up a menu to set a new custom compass.

The art was made by Dan, so it is a bit rough still, but functionally it is working great!  Oh, speaking of functionality, we also let the player quickly select between compasses by pressing the Dpad.

Other Notable Updates

• NPC and doors now have scheduled active times, which can be set individually.  NPC characters can also have different text if you stay on screen with them while their active time expires.
• Our Input Recorder now captures certain keyboard keys for Playback.  This is so, if we “cheat” during our session, our playback will “cheat” as well.
• In our previous update post, we talked about adding generic NPCs.  We also added stun and idle animations as well.
• To make merging more streamlined, at the very beginning, enemies will spawn with only one type of weapon for a given weapon type.  As the player’s max inventory increases for a given weapon type, enemies will be able to spawn with more variety.  To accomplish this, we created a function called change_weapon_on, which was using Game Maker Studio’s instance_change function.  Long story short, we believe there is a severe problem with this function which causes some intermittent problems after hours of play.  See my bug report and this thread if interested in more details!  To fix it this, we decided to not be lazy (i.e. using instance_change) and manually “do the change” ourselves.
• Our Adviser has also been playing the game and providing feedback.  At the time, these polish items were low hanging fruit items that were quick to fix and would help make the showcase that much better.  Below is a screenshot:

  

• Lastly, we eased the pain of falling into a hole.  Before, there was a pretty extreme force that sucks the player into the hole.  Though we still wanted force to make the feeling of falling into a hole, we understood the feedback.  Therefore, we made the force not as strong, added a sound and visual effect that hints at the player that “this is not a good idea to continue standing here”.  The first time this happens, the player probably won’t react fast enough to do anything about it.  But with sequential hole collisions, the force not being as strong and the added sfx / vfx should help the player escape falling into a hole much easier.

We have been given the opportunity to showcase Violet at Cedarville’s Video Game Exhibition Friday, December 8th from 11am to 4pm in the lower lobby of the SSC (Stevens Student Center)!  We are beyond excited for this opportunity to show Violet off in its first public venue.  If you are in the area and have the time, come swing by!

As we have hinted at, with the past few months we have begun integrating story elements into the actual gameplay, which have been privileged information up to this point.  With this opportunity and keeping development on track for a future Kickstarter, we decided it would be in the best interest to not remove any of the story data.

Therefore, it was decided to give our current followers the first look at story elements, before the public at large sees it.  Up until now, we have been very careful about not spoiling any names / locations / etc.  In fact, we’d even gone as far to reupload files to mask the names of characters.  We are very excited to not have to do this anymore!

We should note that what we are revealing will not spoil any of the major story elements (i.e. this will be what we reveal in promotional material in the future / the first cutscene or two of the game).  Before we begin, let us introduce you to our writer.

Writer

It is our pleasure to introduce our writer, Kennedy Jewett.  We originally had a great story outline in late 2018 / 2019 and ironically, it involved a pandemic.  Then, an actual real world pandemic hit.  We decided it was in the best interest to rewrite this story outline to “get away” from a pandemic idea.  Therefore, Kennedy has been able to transform the original story beats into something entirely new, while maintaining the essence of the original story / gameplay that we were wanting.  Kennedy will be responsible for writing and maintaining the high level story, characters, and continuity.  We are excited for what she can bring to the project!

Without further ado, let us take you to the world of Velare.

Velare

There once was a time when Velare knew only love and prosperity.  For hundreds of years, men and creatures lived in tandem.  But at some point, darkness overcame civilization and turned clans against one another.  This corruption led to a deadly war in Velare, which came to be known as “The Withering”, which resulted in the darkness being banished.

The Velareans who resisted the darkness remained in Velare and were tasked to rebuild the kingdom, but the beasts who became corrupt were banished from the land never to return.  The rebuilding of Velare was very successful.  The Velareans created a solemn holiday called Remembrance where citizens from all across the land would travel to Castletown to remember their fallen ancestors.  But overtime, knowledge of the Withering became lost and forgotten, and Remembrance became an empty ritual.

With the passing of each generation, royal responsibilities were neglected and knowledge forgotten.  Forty generations had passed by the time Archon is king, and it was normal for the royal family to hire laborers to take on royal responsibilities.

Minhaga

Minhaga is a local botanist / alchemist and is one of the outside hires who loves to experiment.  Upon King Archon’s coronation, he appoints Minhaga to be the official overseer of the royal family’s gardens.

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.

Minhaga resonated with the king, because Minhaga’s own son was also very sick and he was already trying to find a cure.  During one of Minhaga’s garden observations, he began to notice similar regenerative properties between Velarean herbal remedies and Violets.  The king’s decree for a remedy forces Minhaga’s hand; he uproots four Violets and transports them to the palace to present to King Archon at Remembrance.

Asteric

Asteric is a young man, around sixteen years old, who acts as a regional courier.  However, Asteric has always wanted to be a soldier for Velare.  Asteric, who is always dreaming, accidently oversleeps on the day of Remembrance and becomes extremely late for the ceremony.

As Asteric is arriving late to the Remembrance Ceremony, he witnesses Minhaga present something to King Archon.  All of the sudden, chaos comes out of nowhere and the crowd starts panicking.  Without Asteric realizing, Minhaga was presenting his potential remedy for the sickness that ailed the prince.  As Minhaga and King Archon are observing the remedy, the Violets grow quickly and viciously turn on them and all who are around them.

Asteric takes it upon himself to fight against the Violets to prove that he can be a soldier in Velare.  Will Asteric be able to fight off the vicious Violets to finally prove his skill, or will he become another casualty?