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:
- 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.
- 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
layerDepthtrigger, 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
Bbutton 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
Frank 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!