Author: danieltjewett

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?

It seems like yesterday was the end of September, and now it is the end of October!  We’re sorry for the delay in posting.  The good news is we have a lot to share!

The Violets

We are excited to finally share the titular enemy, the Violets.  This was one item that was mostly completed around the end of July, but had a few more polishing items to finish.  Thus, we decided to wait to share in this post!

As mentioned 5 years ago in the about post, the Violets behavior is similar to the splitting and combining of the game agar.io. The Violets in their defensive form have no concept of good or evil.  They have one task:  to defend at all costs.  Violets survival is completely based on feeding off of their enemy to grow bigger.  The larger the Violet, the more health it has.  The problem is, the bigger the Violet, the slower it moves.  Thus, they attack when a threat is nearby by splitting off, thus getting smaller and can move quicker.  When Violets take damage, they also shrink in size.  Violets like to group together to swarm their enemy.  When same sized Violets group together, they can combine to grow bigger (albeit being slow again, but having more health).  The AI of the Violets makes them the deadliest of foes, similar to how Metroids are for the Metroid series.  The Violets pose a huge threat if they are not properly handled.

As the title of this posts insinuates, the Violets are completed functionally and artistically!  Tony did a great job capturing what we were wanting in designing the Violets.  Below are a few design concepts:

We ended up combining designs 1 and 2 which produced these designs, ordered from oldest to final:

As mentioned, the Violets have variety of sizes.  Thus, we had to design all of the different animations around the many different sizes.  We aren’t going to share all the different sizes or animations.  However, we did want to share our first public screen capture, demonstrating the Violets in action:

I (Dan) make light work of destroying the Violets.  But keep in mind, I have a lot of health here, with all the best weapons in the game!  Playing the demo of the game will demonstrate just how deadly these Violets are!

Concept Artist

Also at the cusp of the last post, we were working on getting a concept artist to design a few of our characters. It is our pleasure to introduce our newest team member, Corinne Schwallie.  Corinne is a freelance concept artist based in Ohio with a few years of concepting passion projects.  She has already brought a few of our characters to life so far (which we will be showcasing in a future post) and we’re excited to see what else she can bring to the table!  We are excited for what her talents will do for the project.

New Items

Below are a few more items that can be picked up during the game:

We also decided that consumable healing food comes from Globs in this world.  Below are those items:

Each of these “Gluits” are native to specific provinces in the world.  For example, globs will drop Glushrooms in the swamp province.

Tutorial and Fog

We made some updates to what we’re calling the “tutorial border” as well as fog in the game:

NPC Updates

One of the biggest updates we have done to the game in the month of October was updating our NPC‘s art.  Though we haven’t done most of the main characters, we did create all of the “bit” characters.  You maybe wondering “I know the team is making progress on the game, but making hundreds of animations for bit characters vs. the ratio that you have been creating enemies / etc., there is no-way!?”  And you’d be right — except we didn’t create our bit characters the same way as everything else.  We created a layering system.

We ended up creating an almost bare base, which then we can layer on hair, beards, and clothing.  We created six bases: adult male, chubby adult male, adult female, chubby adult female, child male and child female.  With these bases, we can palette swap skin tone.  With the clothing layer, Tony drew these in such a way where each color distinguishes a part of clothing (e.g sleeves, chest, pants).  We can then palette swap the clothing to make the character have many different variations of clothing types.  Beards and hair had to be created distinctly for each type of hair / beard style.  But, we can palette swap hair colors easily.  With all of these different layering / body types / skin colors / hair colors / hair types / etc., we are able to make thousands of different variations for our bit characters.

Below is a screenshot with some of them:

In addition, we also updated the dialog for these characters to reflect the direction of the story as well as new game updates.

Game Design

There have been some additional game mechanics the last couple of months, as well as some tweaks to existing systems.

The first is the ability to learn new combat skills.  Before this, the player had essentially “all of the best combat skills” from the start.  But we asked a main question: “what if we limited the amount of swings / thrusts a player can do?”.  Which led into these questions: “How does that change the game?  Will the game feel unbalanced or just feel ‘bad’?”  Strangely, the game didn’t feel bad or unbalanced.  In fact, it felt good to learn these “new skills”, and made progression feel all that more rewarding.  In our opinion, it changed the game for the better.  But, we had to figure out a way to “unlock” learning these moves.

Originally, before the real tutorial was implemented, the Dojo master “taught” the player a few of the moves / skills / etc. as the tutorial.  Now, we have the Dojo master teach the player these new skills by trading in Skull Pendants (the icon shown above in the `New Items` section).  These Skull Pendants can be obtained by clearing out forts of enemies.  Essentially, the player is proving to the Dojo master the mastery of their skills and the Dojo master rewards the player by learning (or unlocking) the new skills.

The second update is better weapon assignment to our Soldier enemies.  Before, they were all randomly generated.  Now, we can specify what type of weapon they carry.  For those type of Soldier enemies that are still random, we limited the amount of randomness based on the player’s inventory size for that type of weapon.  For example, if the player has only two capacity for balanced weapons, Soldier enemies that are of balanced weapons type can only have Sword.  However, if the player’s balanced weapons capacity increases to three, Soldier enemies that are of balanced weapons type can randomly choose Sword or Rapier.

What this helps with is the weapon merging mechanic.  When we decreased the capacity, we noticed a lot of players not merging or picking up weapons because the weapons were all sorts of different.  Now with enemies dropping more common weapons, the player is more easily able to merge their weapons.  So essentially, the greater the capacity, the more available weapons that are out there randomly.  We still can assign weapon assignment specifically to Soldier enemies.  So, we could still add weapons that aren’t in the random selection pool, giving some mystic / value to the player.

The third is overhauling our enemies hearing system.  Before we started adding sound effects to the game, the way an enemy “heard” the player was by how fast the main character was moving.  This had a lot of limitations, but worked for us very well early on in development.  But with all the newly added sound effects, this system was severely outdated.  Thus, we decided to overhaul the hearing system.  The good news is the properties that the enemy determined if they “heard” the player moving was all reusable.  For example, each enemy had a hearDist property, which is how far an enemy can hear something.  So if the player was moving so fast within the hearDist property, then the enemy could hear the player.

When updating our hearing system, we wanted to replace “how fast the character is moving” with “what sounds are being played, where at and how loud”.  “What sounds” are being played was relatively easy, we cached the sound until it is no longer playing.  “Where at” was relatively easy as well.  We keep track of the starting position when the sound is played.  If the sound is attached to a moving object (like an arrow), we can get its current location as well.  “How loud” was an interesting problem to solve for.  We didn’t want to use the playback volume for a given sound effect, since that is relative to the human player / mixed with all the other sounds / music.  Therefore, we assigned a “loudness” property to each sound effect using this hearing system.  There are five thresholds: quiet, noise, normal, moderate, and loud.  Quiet / noise sounds are like footsteps, Normal sounds are like speaking volume, Moderate / Loud sounds are like things breaking / explosions.  With these relative volumes, we can not only make use of our hearDist property on our enemies, but also “gate” quieter sounds for enemies with bad hearing.  This system is very simple but also provides robust amounts of enemy configurations.

Other Notable Updates

One other feature we had mostly completed at the cusp of the last post was a cutscene / sequence system.  In our minds, a cutscene is just a sequence of scripted events that should happen.  Therefore, what was really at play was a sequence system.  We wanted this sequence system to handle not only the aforementioned cutscene problem, but something like “when a block is moved onto a switch, pan the camera to the gate, show it unlocking, pan the camera back”.

Interestingly, Game Maker Studio just released a sequence creator as a feature (which is partially why we waited so long to implement this).  However, there were some limitations of Game Maker’s sequence creator with our engine that we won’t get into here.  Therefore, we rolled out our own solution.

To solve for this, we added to our global object a function called addSequence that registers a callback, or a list of actions that should run.  The instance that registers the function can then run that sequence when it is ready, or use another function called runSequenceWhen that provides a logic callback.  When that logic callback is true (e.g. “a block is on a switch”), the sequence will then run.  There can be multiple sequences ran sequentially, as addSequence takes a time delay of when the next sequence should run.  In our above example, “pan the camera to the gate” takes some time to actually happen.  We don’t want to run “show it unlocking” until a certain amount of time has passed for the camera to get to the gate (or we could use another runSequenceWhen the camera is in position, but just illustrating a point).  We also have a few other helper functions, like sequenceHasRan, which checks to see if a given sequence has ran already, as well as pauseSequenceWhen, which pauses a running sequence when a certain logic callback is true.

This system has a few other bells and whistles that the average reader probably won’t want us getting into the weeds of.  But this sequence system is going to be the backbone of mainly other systems to come.

Below are the remaining notable updates:

• We found another issue with our Recorder / Playback system for watching a player’s session / debugging.  We found out that the audio system in Game Maker is asynchronous.  Well, we knew it was asynchronous, but we didn’t realize it was affecting our recording / playback system until now.  The Game Maker Studio functions audio_is_playing and even more specifically audio_sound_get_track_position are not guaranteed to be the same each playback (due to computers running different tasks on each playthrough).  Therefore, we added functionality in our Recorder to capture these values so that our Playback can return these values as they were for a given session.
• We made some updates to our map generator.  In our last post, we mentioned that we had begun building the real game world.  Our old map was out-of-date, but we haven’t made updates to the map generator in a while.  Therefore, we spent some time updating our map generator to account for all the different new things (e.g. TileLayer system).
• We fixed some issues with our moveable blocks introduced in our last post.  There was some snapping issues / moving through blocks if the player positioned themselves correctly (or incorrectly).
• Since we added a concept of moveable blocks, it only made sense to have these moveable blocks be pushed on a switch.  We therefore made some adjustments to our gates to be able to go from an unlocked state back to a lock state (e.g. the block was on a switch, and now we moved the block off).
• September saw us fixing many, many TODOs.  We had up to 110 TODO items.  Yes, we’ve been a bit busy adding new features that we haven’t really refactored much.  Now we’re down to about 45, the majority related to updating old sprites with new ones.
• We also have been doing a lot of play testing.  This is because we are getting demos out to a few people to help with the future Kickstarter.
• Because we are going to start handing out the demos to people, we’ve begun making use of tagging / releases in Github (where our source code is hosted), for better tracking.  We’re going to be creating minor releases from here on out.  Along with this, we’ve been essentially committing to one branch this whole time.  Now we are getting in better habits of making pull requests for our bugs / issues / features.  This helps with tracking / searchability / tagging / releases as well.

After the disappointing month of March, we took some time to recalibrate once again.  After a long couple months of silence on our end, we are pleased to announce some long overdue updates.  On the name front, we can’t quite reveal this yet (per our lawyer), but we can at least share the good news that we’re still able to use Violets in some capacity!

Even though we had some time of recalibrating, we also can’t deny that the months of May and June have been busy for us outside of this project.  As you may know, a little game called The Legend of Zelda: Tears of the Kingdom came out.  Being that Tears of the Kingdom (TotK) is a direct sequel to The Legend of Zelda: Breath of the Wild, a game we took a lot of our original inspiration from, it was critical that we took the time necessary to play through and understand what the game was about.  Many choices, ideas, and game design moving forward (some which will be covered in this post) was definitely impacted by playing through Nintendo’s latest Zelda game.

Part of the recalibration effort these past couple of months was actually game planning / coming up with the tasks needed to be completed to make our game.  All of this planning, especially after TotK coming out was no accident.  We are certainly glad that it came out when it did.  Giving a review / our opinions of TotK is beyond the scope of this blog.  However, our biggest learning as it relates to this project is that there is a sense of traditional Zelda that is no longer present in Breath of the Wild (BotW) / TotK.  Perhaps we’ll touch on that topic at a later date.  For now though, let’s move on from high level talk and get into the updates!

Minotaur Updates

Since we last posted, we shared some Minotaur updates, and we have even more to share below:

The minotaur has extreme strength, and Tony did a great job capturing this with these swings!

Soldier

(Not to be confused with the enemy type Soldier).  Castle town contains soldiers that protect the royal family and the population from danger.  There’s also a special type of soldier that exists in the game to protect a special place (this is a bit vague, but this is the most we can explain for now without spoiling anything)!  We wanted to save time and not design two different types of soldiers.  Therefore, we made use of the palette swapper and made one version of the solider and swapped different colors to make two different types of soldiers out of one design.

Like anything new, we came up with a couple designs (in pairs) shown below:

We ultimately went with the last design and came up with this final version:

And we even have some walk and run cycles completed:

Yellow Enemy Variants

We decided that we needed another variation type that was on the medium difficulty side to help the pace / difficulty curve of the game.  Therefore, we added yellow enemy variants, shown below:

Other Art Updates

Below are a few screenshots of a few other new art assets, including updated glows, signs and icons, boulders, pots and moveable blocks!

Game Design

One of major items we have been working on the past month is nailing down the answer to the question “What is Violet”?  As mentioned in the introduction of this post, one of our learnings of playing the latest two Zelda entries was that the traditional Zelda experience is no longer present.  Therefore, we believe in order for this project to standout amongst the vast crowd of games is to separate ourselves as much as possible from the “modern” Zelda formula and really deliver on “the traditional Zelda experience”.  To us, this means many things.  But to summarize it succinctly, it would be a “simple, progression based, laser-focused scope”.

Over the past month, we’ve began thinking about the design of the game.  We’ve been brainstorming different collectibles, where they exist, why they are collected, etc.  We’ve been deciding what areas we want to build in the game, why they exist, what purpose they serve in the game, etc.  We’ve been thinking through what additional mechanics should be in the game, how they are obtained, for what reason do they serve, etc.  Basically, we’ve been determining the purpose of the game.  Originally the plan was to make this game a huge, 2D, open-world adventure.  After playing TotK, I (Dan) don’t think bigger is always better.  Therefore, we decided to get “laser-focused” on the areas we want to create and make sure these areas are full with fun, unique, and engaging content.

As discussed in our previous post, we pushed back the Kickstarter date.  Part of these past couple months was actually beginning to build out the actual world.  Before the events of the previous post, we were planning on making a Kickstarter demo that would throw away the world we’ve created.  In order to deliver the project in a timely manner, we decided it would be better to create part of the world for the demo, that would be refined as development continues.

Before our previous post, we were experimenting with the actual world and how big it was going to be.  The original world was going to be 18×18 sections (a section originally contained 6×6 zones and a zone was 480x480px).  We even started building castle town, which was going to be 2×2 sections large!  After realizing we needed to make this game smaller in scope, we ironically, we went back to the room size of the original Kickstarter demo, which was 9×9 sections.  However, we found that to be a bit small (mainly with the fact that houses / dungeons / caves / etc. are as big on the inside as they are on the outside (breaking a convention here)).  With the math involved, there wasn’t a divisible way to have an in-between size that encompassed 3×3 provinces (a province would contain n number of sections) with 81 sections that we were wanting.  However, a thought eventually popped into our heads of “what if we made the sections contain 8×8 zones”?  This made the original Kickstarter grid of 9×9 sections not feel as small anymore, while the world also didn’t feel too large either.  Essentially, making the sections contain 8×8 zones made our 9×9 section grid feel like an original 12×12 section grid (6×6 zones), but utilizing the 3×3 provinces that we wanted from a world building standpoint.

Concurrently with building out new sections, we’ve also been coming up with the scope for the game.  This has been a long and hard process.  Much of the reason why this has been hard is that determining what should be cut, and what should be kept is painful.  Up until now in my career, I (Dan) have always been on the other side of the conversation when it comes to cutting things.  It’s much easier to say “no” when it isn’t ultimately your product.  However, now being in the role of “the client”, it’s really hard to remove good ideas, for the sake of time and budget.  With that said, getting “laser-focused” on what we are building will ultimately be for the best of the game.  We’ve had a vision for the game (and honestly, we really haven’t strayed too far from this vision), but haven’t had any need for boundaries or rails up until this point.  But with time and money entering the picture, it’s very important to put into words what this definition of the game will be, and of course, sticking to it!

Coming up with the scope of the game has also been tedious.  We currently have notes and ideas in many different places.  We’ve had to do a lot of consolidating on our part!

One of the more tedious parts was determining what resources (items) we wanted.  We originally were planning on having many droppable resources with a few different inventories to organize them.  However, a common shared complaint in TotK, was the cluttered, and annoying to sort through inventory system.  Part of the problem in our opinion is that there is just too much stuff in that game.  Therefore, we decided to scale back what was collected and why.  For example, we were going to have resources in the game that served multiple purposes.  Instead, we decided to give a resource one purpose, which makes the game “simple” and “laser-focused”.  A good example of this is we decided to combine the Fire, Ice and Water Cores into one Element Ore that can be used as ammunition for the elemental rods.  We originally wanted the ability to have the Fire Core be used for Fire Rods, as well as other purposes.  But, cutting this idea in favor of removing extra clutter will help streamline the game.

Other Notable Updates

It’s been satisfying to start designing the game now that we have many of the game’s systems developed.  We still have a lot more design / work to do, but we’re getting closer each step of the way!  Below are a list of other updates we’ve worked on:

• Since we have another year of development, we finished worked on the horse from a functionality standpoint, and it works great!  Now we hope we’ll have enough time to implement the art for the Kickstarter demo for the player to be able to ride horses!
• We mentioned yellow enemy variants above.  With that addition came increasing the highest ranking from S to SS.  Now the ranking is as follows: F, E, D, C, B, A, S, SS.
• As we were building new Castle Town, one thing we thought was “wouldn’t be cool if we could get on the roofs, jump off of them, etc.?”  So, we decided to implement that feature.  It required some updates to our tileLayer system, but it ended up being for the better.  For example, one thing we realized was house walls were acting much like cliffs!  Therefore, we refactored house tile layer into the cliffs, and cleaned up a bunch of unnecessary systems around that.

  

• Along with our tileLayer system updates, we also added two other types of tiles: holes and shallow water.
• We added a No Controller Dialog (to help the player know if their controller is connected):

  

• We added a position editor to help us position weapons / items on the Living objects.  Before we were doing this manually by going into the art canvas, positioning the sprite there, and manually calculating the offset, and typing it into the code.  Now we have a debug in-game editor that does all of this and outputs a json file with this data:

  

• You may have noticed that the HUD contains icons for the L / R Shoulder buttons now.  We decided to combine rods as a group of weapons (much like balanced or agile is its own group).  We also found that it was easier to not swapped the “Dpad pages” with the shoulder buttons.  Therefore, we assigned the rod / special weapon selection to the shoulder buttons.
• We overhauled our buildings system (inside a house, cave, etc.).  In this post, we mentioned that buildings being as big on the outside as they are on the inside.  To make this work, the “inside” of a building exists in the same game room as the outside.  Therefore, we need a way to determine when a Interactable object is inside or outside.  The old way of making this work was to draw primitives that created tris (triangles), and these tris would create rectangles, or tiles that we could use to determine if something was inside.  Here’s a simple example:

  

  If you look closely at the red line, it makes two triangles, which form a rectangle.  Pretty neat.  But, what if we have a complicated building, or a cave system like below:

  

  This creates all the rectangles we need, but is an utter mess to maintain.  For example, as we were designing this cave system, we changed the layout multiple times, which required us to update this primitive.  We decided that this needed to be simplified.  Now, if we want to create a building, we basically lay down a tile overlay of what the boundaries should be:

  

  It’s quick to update and easy to maintain.  We had to write some code around how to actually interpret these tiles to create actual “insides”.  But now that this work is done, creating additional buildings, cave systems, etc. will be a breeze.

Conclusion

We recognize it’s been a while since our last post and we appreciate the patience!  We’re hoping we can share some bigger news in our next few posts.  You know… things like what the story is, the name of the game, what our characters name is, who the villain is, and some art of different things that we haven’t been able to share yet.  Stay tuned!

Last Year we shared our plans about Violet from a logistical front.  The TL;DR of our post was we’d be shooting for a Kickstarter in February 2024.  And unfortunately we have some bad news:

Our original, high level plan was to launch our Kickstarter in February 2024.  I (Dan) would continue working full time until January 2025 where we’d develop the game for two full years.  In 2027, we’d polish the game and release.  After meeting with the advisor, it was encouraged for us to set a lower target dollar amount, as well as to spend less time post Kickstarter developing the game.  With less budget and less time (the double whammy), we decided to postpone the Kickstarter.  Though we know we’d have a good demo / be ready by Kickstarter in 2024, my (Dan’s) gut was telling me to wait another year (2025) for personal financial reasons.

Above everything else, I (Dan) need to make sure my family is provided for.  And second, I want to make sure those involved on the project don’t have to worry about if / when they are getting paid.  This is a big risk and I need to make sure everyone involved can get through two years without my full time salary.  Of course this is disappointing, but I think the pros might be better in the long run (I always say slow and steady wins the race).  For one, this gives us another year of development / design / art, which should help reduce time post Kickstarter developing the game.  It also means we naturally wouldn’t need as much from a Kickstarter, making a lower target actually workable from a budget standpoint.  And obviously, one more year will make the demo even that much better.

From a logistic standpoint, the timeline stays the same, but we are just shifting the Kickstarter out a year.  The Violet team was graciously more than accepting with postponing the Kickstarter.

However, the “bad news bears” doesn’t stop there:

Shortly after we decided to push the Kickstarter out, our lawyer informed us that not only is Last Life Studios (the LLC I (Dan) am operating under) is trademarked, the game name of “Violet” is also already trademarked.  Essentially what this means is the name of the game is going to have change, as well as some of the branding we have developed (e.g. the website, violetthegame.com, our logo, etc.).

March has not been a good month for Violet.  It has really got me (Dan) discouraged.  Tony, our artist did give me a little encouragement and said “For what it’s worth, those are all normal setbacks. If it means anything, none of those have discouraged my faith in the project.”  The next couple of months will be a bit of a rebranding time, so we may go a bit silent as we try to figure out what to rename / rebrand too.

Setbacks yield pruning, and then growth.  Right now the pruning phase sucks.  But we believe the growth will be exponential.

This is another one of those hodgepodge of updates posts.  However, we already named a post “A Hodgepodge of Updates”.  Therefore, we decided to name the post with one of the main new features we added in the last couple of months — the beginning of the game (i.e. the tutorial)!

I (Dan) hate tutorials in games.  I’m the type of gamer who just wants to play the game and figure things out on my own.  Therefore, we made the tutorial succinct and to the point (and there’s even a way to quit early if an experienced player knows how!).  We believe the tutorial shows the game loop well, while explaining the basics of the game.  The best thing to do is experience it for yourself!  Until then, a few screenshots will have to do:

A couple of other updates you may have noticed in the most recent build of the game:

1. The minimap icons have been updated.
2. We have a cave tileset, with a looping cave texture that repeats for those “out of bounds” areas (i.e. the void).
3. We added a concept of gates and locks, which require unlocking by clearing out enemies, a key, or by some other means.
4. We added hit effects (slashes) as well as changed the damage color an enemy takes.  This in turn means we removed the blood particle effect.
5. We made the rounded corners in the UI for drawn shapes (i.e. programmatic art, like circles) more pixelated.  Game Maker apparently draws its shapes at screen resolution and not the surface resolution, which ended up taking a week of reworking fonts / code / etc.

We also added many UI sound effects to help the player know which buttons / inputs are being pressed / used!  Unfortunately, those are not observable with these screenshots.

Minotaur Updates

We made quite a bit of progress on the Minotaur these past couple of months.  Firstly, the Minotaur dying:

Next, we’ll showcase the Minotaur’s dash attack:

As usual, progress can create setbacks.  After we created our stun animations and tested with a few players, we realized the startup of both the dash attack (as seen above) and the stun animation were very similar, causing players to be confused whether the Minotaur was going to attack or be vulnerable.  I (Dan) personally don’t like in games when an enemies telegraphed animation is similar — especially in making split second decisions.  So, sympathetically, we decided to change all of our stun animations to correct this problem.  Below is an old version (which we’ll see how similar it is to the left dash attacks above):

And below is the current, updated Minotaur stunned animation:

Other Art Updates

While taking a break from the Minotaur, we also did a lot of color and effect updates.  We’ve mentioned some of these updates already (the slash effects).  Therefore, the rest of this section will show off the remaining updates:

Clouds and cloud colors

We removed the cloud effect particle and replaced it with our own “cloud particle”.  We won’t go into all the details of how the clouds work, but we will show off a few updated screenshots:

When it is sunny, clouds will cast a nice, dark blue shadow.  When it is cloudy, these colors become a mix between a nice dark blue and a cloudy gray.  Inside, we change the void color to be a mix between dark brown and cloudy gray.  That is a great segue into:

The Void Color

When we are inside a building, and we don’t have a texture, we will use a void color.  This color used to be black, but we decided to give it a little flavor, depending on the building.  For example, when we are inside a house, we get this nice dark brown:

As we saw above, when it is cloudy, we mix the two colors.  When it is night, we replace the void color with our night time dark blue:

This is a good segue into:

The Nighttime Color

Much like the void color, we were using black to represent night time.  However, we changed this color to be a dark blue as shown below:

The difference is night and day… or, comparatively between some of our other nighttime screenshots, more pleasant looking.

Removed the Fort Fog

Fort fog was one of those things we added very early in development with Violet to test being “inside a building”, before we actually had artwork for buildings.  Now that we have buildings and concepts of being inside / outside, we decided to remove the fort fog.  The difference is night and day:

Cliff Decor

Finally, we added some random decor to the cliffs to give it a little less of a pattern look:

Other Notable Updates

Unlike our two recent posts, there isn’t as much to share in detail within this section.  Below is our bulleted list:

• Performance Increases.  These past few months have increased performance in our game dramatically.  We added a couple of optimizations as well as a few fixes.  For the first time in a while, I (Dan) feel proud to show off the game.
• Slow Motion Debugging.  We came across a function game_set_speed that let’s us toggle the framerate at which the game is running.  Before, we’d change this value in the game settings if we needed to see if animations we’re running correctly / at the correct speeds / etc.  However, running at 2 frames per second made this very cumbersome to test.  With this find, we can toggle the framerate at the moment we need to!
• Fix Playback Input.  With the updates to our path finding, we broke quite a bit with the input recorder / playback.  We finally got around to fixing this (again).  It was really cool to “watch” someone play through the tutorial without having to sit next to them!
• Made Picking Up “A Too Heavy Object” Not as Punishable.  One thing that was frustrating me and other players was that if A were pressed to try to pick up a dropped item, and instead we were close enough to an enemy, we’d try to pick them up instead!  The game would not let the player move until the “too heavy” animation was done.  For really heavy enemies, this could last a couple of seconds, where the player would then get punished.  We made this so the player could “interrupt early” by simply moving during any “too heavy” animations.  That way if an accidental A press occurs, they won’t be punished by it.

These past couple months have seen many art updates, font cleanup, stability fixes and performance increases.  We’re excited to showcase the highlights below.

Minotaur

At the beginning of 2023, we began coming up with a few designs for the newest member of the Soldier enemies, the Minotaur.  Tony, as always, comes up with several great designs that we then have to decide which fits best with the game, story, etc.  Below are a few of the initial designs:

 

 

 

Without going into all of our rationale, we decided to go with the head of the second design and the body of the first design.  This yielded the fifth design:

After some further tweaking, we ended up with our final design:

The Minotaur has more HP and strength compared to the Orc and the Reptile.  To illustrate this from a gameplay perspective, we decided to make the Minotaur significantly larger.  We originally went with 1.5 times larger, but that seemed a bit large comparatively.  We also tried 1.25 times larger, but that seemed a bit small.  Therefore, at about 1.33 times, the Minotaur stands tall at 42 pixels (our hero is 32 pixels for reference (~5’9″)).  We also wanted to showcase the strength with its intimidating walk cycle, as shown below:

Reptile Updates

December found us finishing up some Reptile animations with the bow and two-handed walk cycle.  However, as we were preparing the Minotaur, we had realized we forgot to do idle animations for the reptile.  Below are those animations:

Cliff Updates

We also decided to touch up the cliff walls a bit, as well as add a few palette updates for the cliffs in different biomes shown below:

Target Updates

We finally decided to give an overhaul to the targeting system, both artistically and functionally.  Functionally, we added a “pause” concept that would only change the targetable enemies every one second, or when the player made a selection.  Even though the computer could calculate accurately which targets were “next”, having them change so rapidly made it really hard for the player to choose.  This delay or pause concept really helps in selecting.

Visually, we added three states:

1. Light blue bracket — the “next” target if we quickly let go of L-Trigger and press it again
2. Yellow bracket — the current target we are locked on to
3. Directional arrows — if we press the R-Stick in the direction of the arrow, that enemy will become the “next” target

Below is an illustration of what this looks like:

You may have also noticed in the above screenshots that we moved the HUD elements.  We haven’t officially decided if we like this, but moving these elements to the corners of the screen really helps with the vertical screen real-estate.

Font Updates

You might have noticed in the above screenshots that the font is much different than before.  We overhauled the font systems and used / touched up some elegant pixel art fonts, as showcased below:

Other Notable Updates

Path Finding Part Two

In our previous post, we explained our problems with the path finding / grid system native to Game Maker and our current solution of using our own grid system.  By using our own, faster grid system, we also had to use our own implementation of A*, which essentially made us break even with the performance gains (because Game Maker’s mp_grid_path function is impossibly fast).  However, we hinted at our backburner task of rolling out the path finding (A*)  on a different thread.  Game Maker Studio has the ability to pull in from external resources, and we finally got around to offloading the path finding in C++ as well as on a different thread (spoiler, this gave us extreme performance boosts).

I (Dan) finally had a few consecutive days off after Christmas where I was able to dedicate 100% of my time with no interruptions learning how to make external DLLs that Game Maker Studio could then import and make calls out too.  The journey was tough — and honestly, I thought it was going to take longer to figure out than it did.  Most of our learnings came from these forum posts / guides:

1. https://forum.gamemaker.io/index.php?threads/getting-started-with-c-dll-extension-creation-in-eclipse.73728/
2. https://forum.gamemaker.io/index.php?threads/asynchronous-c-dll-extension-creation-in-eclipse.74176/
3. https://help.yoyogames.com/hc/en-us/articles/360015676137-How-To-Create-DLL-Extensions-For-Windows-Games

We ended up going with Visual Studio instead of Eclipse, mainly because we already had Visual Studio installed for Game Maker’s YYC compiler.  After about the first day, we had a simple “Hello World” program made where we were able to talk to Game Maker and back to the DLL.  Day 1 and 2 also saw us converting our A* from GML to C++.  I haven’t touched C++ since my college days, so it took a little bit of time to remember how good ole pointers work.  After about Day 2, the A* algorithm was able to compute within a main program within the DLL (meaning, it was converted successfully).

Day 3 was the trickiest as we had to convert our aforementioned grid system of the previous blog post to buffers.  The only way to send large amounts of data to a DLL is to send the memory address (pointer) of the buffer from Game Maker.  Therefore, we had to convert our ds_grids to buffers.  Even though this was a pain, buffers are not only faster in Game Maker, but the size in memory was about half, so we inadvertently gained some performance.  Day 3 also saw us learning how to use threading properly in C++.  Even though native C++ is faster than GML, it still didn’t really make since for us to spend all of these new CPU cycles sending to the DLL if we were still running the A* on the same / main thread as the game.  Therefore, we had to figure out how to implement C++ threads.

There were two threading libraries we looked at.  The first was pthread, which we ultimately scrapped as it is meant for Unix computers.  Though there are ways to make it work on Windows (the eclipse link / we had it kind of working at one point in Visual Studio by importing the pthread library, but eventually gave up) we finally went with thread, which seems like it is native to C++ now.  After a few hours of experimenting, we were able to get threads working within C++.

By the fourth day, we were able to successfully send the grid data to the DLL, create a thread, compute the A* path and send the path data back to Game Maker!  When I first got the logs of the path data in Game Maker, I screamed at the top of my lungs and scared my wife!  A few minutes later, we were able to convert that data so that our Soldier enemies could move again!  We also were able to figure out ways to cancel computations / threads in the DLL.  For example, if an Orc dies while computing its path, we no longer need to compute the path anymore, since its dead.

Seeing the fruits of this labor paid of majorly.  We’re even thinking of moving our boid enemies (Globs, Bats, Violets) so that the computation is also threaded / asynchronous, as we eventually want tens of Violets on screen.

“Asynchronous” Zones

If we recall from previous posts, as our hero / camera moves from one location to another, we load in zones that are slightly off screen the direction we are moving and unload zones that are slightly off screen in the opposite direction.  If the whole world was computing all at once, our game’s speed would crawl.  In the spirit of async, we decided to make our loading / unloading of zones “asynchronous”.  We put asynchronous in quotes because, unlike the aforementioned A* which is truly asynchronous, the loading and unloading of zones is spread (vs. done all at once) amongst several frames.  For example, if we need to load in 4 zones, and it has taken more than 500ms to do so, we tell that system “hey, you’re taking a long time.  Let’s continue loading the next frame”.  So, instead of loading 4 zones in 2000ms (remember, a frame should compute and draw in ~16000ms), we load 1 zone each frame for about 500ms.  Since these zones are slightly off screen, there is still no need to worry about a jarring “pop in” effect.  By offloading this task to several frames of the game, we are able to prevent stutter slow.

Other Stability Increases

We also improved the frame rate of the game by removing a few particle effects that we were planning on replacing anyway.  For example, blood was a particle effect that we don’t believe was getting removed properly.  Recently, if an enemy dies, its body remains until the player unloads the zone and then comes back to that zone a few minutes later.  However, if the player never returns back to the zone, the body and its particle system remained in memory until the game ended.  By removing the particle (we’re eventually going to create a system for handling dead bodies / other objects that linger around like this), this in turned freed up memory, which in turn, frees up the CPU.

We also improved the draw_container routine for the inventory.  All other draw_container calls cached the container that is being drawn, except the inventory screen.  This was mainly because refactoring this was going to take a bit of time and was easier to just leave alone.  However, keeping the inventory from redrawing the container each frame would create hundreds of structs per frame, which would cause memory to spike.  Game Maker’s automatic garbage would eventually clean this.  However, the amount of time garbage collection has taken on Game Maker’s part has become quite burdensome for Violet recently.  Essentially, there have been stutter slow downs, similar to the aforementioned loading / unloading of zones.  However, unlike loading / unloading of zones, we don’t control Game Maker’s automatic garbage collector.  Therefore, anything we can do to help avoid unnecessary structs / memory on our part we’ve noticed helps keep Game Maker’s garbage collector more stable.

Weapon Degrading / Capacity / Shards

On Christmas Eve, I (Dan) was playing an old build from 2019.  I was mainly doing this just to see how far the game had progressed.  While playing, I realized a mechanic that functioned differently than it does now.  When a weapon degraded, it only moved down by 1 damage point.  Though there was nothing in 2019 indicating that it had degraded, it was interesting to play the game with weapons that slowly degraded vs. now where degrades go down a full letter (therefore, like 20 damage points).  We began thinking “what if we degraded by a smaller amount”?

We decided to try this theory and liked this so much better.  Now, instead of a C ranked weapon dropping to a D, it goes from C to C-, C- to D+ and then D+ to D.  We feel this really helps with the damage output in mid-battle.  However, with degrading only going down by thirds, the amount of weapon shards (which can be used to increase weapon capacity) had not changed, being way more abundant.  We decided to decrease this, as well as decrease the amount hits it takes to degrade a weapon.  Therefore, the degrading happens more (but the damage output is not cut has bad), which yield more weapon shards (but not too abundant).  With these two new systems at play, we also decided to make starting inventory capacity for each type 2.  With more weapon shards, it becomes pretty easy to increase weapon capacity.  With the primary mechanic of merging degraded weapons together for better weapons, we feel like we’ve made better a really interesting game loop with the weapon system.