Author: danieltjewett

Today is the day! After six years of development, we are excited to announce that we have officially launched our Kickstarter Campaign for The Violets of Amicus™! We have 30 days to reach our funding goal of $80,000. A breakdown of the funding is as follows:

Once our goal is met, I (Dan) will be working on the game full time, while the rest of the team will ramp up in work. The goal is to have the game completed in 2027, releasing sometime in 4th quarter. Though we have quite a bit left to finish, we have a strong vision and dedication to this project that will see it through to the finish line. We would love for you to be part of our success story in the launch of our official game!

Our campaign is an “all or nothing” – meaning we need to raise all of the money in order to have had a successful Kickstarter. If you are graciously planning on funding, please consider backing today, as that will help with a smoother launch, and a better chance of being successfully funded. Those who support (based on the amount supported) will be rewarded with credits in the game, a copy of the game, the OST, and much more!

We can’t thank you enough for backing our project! It’s also just as important to share with as many people as possible. Word-of-mouth is going to be what carries this campaign to the finish line, and we can’t do it without your help! Please share on social media, text, email, pigeons, whatever your preferred means of communication!

Thank you so much for following along. The next phase of Violet has begun. We can’t thank you enough for your support!

At the beginning of January, we released our demo on Steam!  Overall, it was a successful launch and we are excited that so many people were able to checkout The Violets of Amicus™ for the first time!  Reception has gone over well, with all recommendations at the current time of this writing on Steam.  We appreciate each and everyone playing our demo.  If you haven’t got a chance yet to play the demo, or review the demo, please do so here.  It helps boost our game so that other people will see it!

During this past month, things have been a bit slower, comparatively to the craziness of December!  That doesn’t mean we haven’t been busy though as we have been hard at work marketing and preparing for our Kickstarter launch.  As mentioned in our previous post, we are a week out from launching our Kickstarter campaign!  If you haven’t clicked the “Notify me on launch” button, please do so!  Again, it helps boost our project so that other people will see it.

Now, onto the updates!

Art

Tony has been currently finishing a few animations that were low priority for the demo, that didn’t quite get in at launch.  These were some breaking animations; a bear statue and sawmill junk:

We also began work on the big bad Centaur!  We showcased the stand frames last month.  Currently, we have been working on the walk and canter animations:

We are hoping to get these into the demo before the launch of our Kickstarter.

Speedrun and Commentary

A couple of weeks ago, I (Dan) decided to try doing a speedrun of our demo.  I test the game a lot and decided to give myself a challenge (as well as try to uncover any bugs).  The current world record is 25:08.  This is a pretty steep challenge, but I am already aware of about 3 minutes that could be shaved off from optimization.

We didn’t want that video / challenge to go to waste, so about a week ago, Tony and I decided to do some commentary about the development on Violet while the speedrun was playing in the background.  You can watch that video here: https://youtu.be/-pZi7ifh7T4

Streamers and Youtube Video Highlights

We had a streamer, Bashfulday, scheduled to play our demo the day after release day.  It was a lot of fun watching her play the demo.  We can watch this stream here (Content Warning: there is some language in this): https://youtu.be/3sQ-rEMenOo

Meanwhile, we also found three Youtubers who played our demo — one which we presume is from Italy!  It’s been exciting to see people play through our game.  We can watch these videos below (Content Warning: there is some language in these):

Matt Plays Indies https://youtu.be/QEPwa71Pgm8

GogetaSuperx https://youtu.be/H4mDTa5dbCk

Sid Ruxell Gaming https://youtu.be/FcMrrkmo4pE

Updates from Gameplay Observations

Now that the demo is out there in the wild, and we have gameplay footage out there for all to see (including us), we are able to watch these playthroughs and make any adjustments / tweaks.  For example, we found a common issue of people not realizing that the West Gate is the way out of Jasper (Castle Town).  This can be observed in Matt Plays Indies’ video above.  Therefore, we made a few adjustments, to help the pacing and get people playing “the action parts” of the game:

• Make the Fortune Teller Open 24/7 – Luckily, people who were getting stuck did find the fortune teller, and she explained where to go next.  However, her shop wasn’t always open.  Therefore, we kept it always open.
• Make the West Gate more Obvious by Adding a Sign and NPC – We noticed in a few playthroughs that people tend to through the South Gate of Jasper.  Therefore, we put a sign out there explaining that the path is blocked off and only the West Gate is available.  We also put an NPC outside of the North and East Gate, explaining the same thing.
• Make Picking Up Weapon Scraps not go to Assets Inventory – This actually came directly from a review on our Steam page!  Essentially, when picking up a weapon scrap, while picking up dropped weapons, pressing start would take the player to the assets inventory page.  Most cases, the player actually wants to go to the inventory of the weapons they are picking up.  A easy one-line code change to make player-experience all the better!
• Auto Save Loads at the Hospital – Because saving / loading was a last minute feature, we weren’t able to thoroughly implement how it will be in the real game.  This lead to people getting put in positions upon loading that would cause them to softlock.  Therefore, loading will always take you to the hospital.

There were several other clean up and fixes around this, but these were the highlights!

Music Updates

Eugene has been cranking out tunes left and right!  Below are two snippets, the first is the Enemy Variation of the Forest Town (which is already in the demo now) and the second is the Forest Temple Theme, which we plan to add to the demo before the launch of the Kickstarter:

Other Notable Updates

Game Maker Updates

We have been on the February 2024 build of Game Maker.  As mentioned in previous posts, Game Maker kept introducing bugs that were preventing us from upgrading.  With the launch of our demo approaching, we decided to stay on that version.

With the “downtime”, we decided to finally upgrade to Game Maker 2024.11, the latest version at the time of this writing.  The 2024.8 version was actually already tested, except one bug that wasn’t fixed.  Therefore, this was a quick turnaround to fix.  However, in updating to 2024.11, we found a couple of issues:

• Game Maker decided that methods should use self (this equivalent for other programming languages) explicitly instead of implicitly.  I’m still unsure why, but it’s resolved now.
• There actually was a bug introduced in 2024.8 with collisions that we didn’t noticed until we had already started upgrading to 2024.11.  This had to do with our rampTileCellData system, and how the game knows which layerDepth an instance should be in.  It was essentially and order-of-operations issue, that we resolved by adding a simple conditional.
• We also fixed two of our own bugs while refactoring / cleaning up:
  • When quitting to the title screen, there was an issue with the way we went about cleaning up our instances under certain circumstances with enemies.  We thought it was something to do with the collision_rectangle_list function (as seen here), but it turns out it was because one of our gates was not working as intended.
  • We’ve had a major issue where instances would activate in the background and therefore either be in places where they weren’t supposed to, or disappear when they weren’t supposed to.  We ended up overhauling major parts of this system, and even optimized unloading to be 3 times faster.  We believe we have squashed this bug, but time will tell!

Ubuntu Builds

We attempted to add native Linux support, as well as native Steam Deck support.  However, our findings were that Linux builds were about 33% slower than what the game ought to be running at.  In regards to the Steam Deck, we found that the Proton experience was much more performant than native Linux builds.  Right now Game Maker’s Linux tools are still in beta and just aren’t quite ready for production.  Because Linux is the default for the Steam Deck, and these performance issues hinder player experience, we decided to remove Linux support at this time.  More information can be found here.

AStar Extension Updates

As you may recall, we rolled out our own pathfinding extension, as we wanted to perform these calculations on a different thread.  We’ve been encountering some silent crashes, where the game would crash without an error report.  These are the worst kind of bugs, because it doesn’t give us any insight on what happened.  Well, we figured out a way to gather that intel, and we determined that, at least one of the silent crashes, was caused from a race condition in unallocating an AStar instance while another thread was using it.  This has been patched and fixed.

While we were looking into Ubuntu builds, we also were able to create an AStar extension that would be compatible with Linux builds.

Conclusion

Please share 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 launch of our Kickstarter campaign!

In exactly two weeks (2/15), we’ll be launching our Kickstarter for The Violets of Amicus™. We need to raise $80,000 in order for our project to be successful. $40k will be designated towards art. $15k will be designated towards programming. $5k will be designated towards SFX design. $5K will be designated towards testing. $5k will be designated towards marketing. And $10K will go towards Kickstarter fees and taxes. Our goal is to have the game completed in 2027, releasing sometime in 4th quarter.  Our campaign is an “all or nothing” – meaning we need to raise all of the money in order to have had a successfully Kickstarter.

Typically, Kickstarters are most successful when they have an good start. A good start means getting 25% – 33% of the goal within the first couple of days. If a Kickstarter doesn’t have a good launch, Kickstarter’s algorithm will most likely suppress the page, making it even that much harder to get funded. If you are graciously planning on funding, please consider backing on 2/15, as that will help with a smoother launch, and a better chance of being successfully funded.

Thank you for considering backing our project! It means the world to have you help support our game.  For those who are following along, but don’t play games and want to support, Kickstarter does have a “Make a pledge without a reward” button.  For everyone else who plans on supporting and are wanting a reward, this is what we’re offering (each previous reward is included in next reward):

• Name in Credits – $5
• Game Copy – $25
• OST – $35

These rewards include the previous three, but are each their own reward:

• Name a Minor Character – $75
• Name a Major Character – $250
• Talk with the Team – $500
• Producer Credit (Custom Game Addition) – $1000

We are also offering limited amounts of early bird rewards of “Game Copy” only, at $15, $20 and $22!

Thank you so much for following along.  The next phase of Violet is soon to begin.  We can’t thank you enough for your support!

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!