Category: Dev Log

By Brandon Coates

Hello and welcome back to another update. Today we will be doing a quick discussion on the importance of tutorials and how we implemented them into Kick Some Bass. Another topic we will cover is the importance of progression and the feeling of achievement many games try to elicit out of their players (us included).

Firstly, I want to talk about our new tutorial system of NPC’s such as Socky (seen below) who will tell the player how to move, fight and shop. Much like a shopper during Black Friday sales events. However, in our world, the only shopper is Jim Jimson. The way he receives advice is from a living sock on a stick and his extended family.

The newly implemented dialogue system which was made with the express purpose of acting as a tutorial interface, has grown into a way of delivering jokes as well as advice while keeping in the spirit of our game.

Finally, with this new tutorial system in place we decided on a simple progression system where the player must defeat the fish in a sequence which will unlock more to do on the island Jim calls home.

These are the major updates as we near our final release in the coming month. All efforts have been and will continue to be made to polish our game to a high standard. We have learned a lot from this process and personally I want to say the team has been doing a great job.

by Brandon Coates

As work continues on our project we get closer to our final release. During this time the team is dedicated to polishing art and animations while refining our combat mechanics. The framework while never truly complete has reached the required completion to refocus our effort into the feel and look of the game. Animations will soon be added as well as two new arenas – one of which is visible below as the last image.

Also, we are happy to announce that our economy and ability system are complete and being integrated into the game to offer more rewards and options to players. We have decided that the store would be a physical location in the interactive map section of our game which is the fist picture below with Jim Jimson standing nearby. However, the ability system will be accessible anywhere on the interactive map and offer the player a chance to spend their ability points earned by leveling up. Or they can spend their hard earned fish bucks at the store.

Finally, as a team, we want to thank you for following along and if you’re, new check back later for the last few updates before we publicly release our game on our website and Itch.io. While this has been a great learning experience for all of us, everything must end and we just hope you get some enjoyment out of our year long labor. Have a great one!

By Yash Chamria

In Kick Some Bass, the player has to fight his way through a number of sea creatures. These fish need to have distinct behaviors for a unique experience with each fight. To achieve distinct opponents, these opponents have vastly different models, abilities and brains. This article will be focusing on the latter and involves the process of testing different AI methods to make our opponents intelligent. 

Different AI Techniques

Let’s talk about the popular and effective options to implement an AI. Behavior tree, State machine, Machine learning and Utility AI. 

We quickly opted behavior tree out as it would be really hard to come up with all the situations in a fight. Also, to have different 9*/8 behavior for different AI we will need a different tree, so this *option involved a lot of design work and careful thinking. 

Next was the state machine and it suffered from the same issues as the behavior tree. 

The third option is to use machine learning, though that involves extensive playtesting to collect player data, and all the abilities need to be implemented for testing. Since AI development was supposed to go in parallel, it started way before the concept of ability existed, which rolled out machine learning as an option.

Lastly, we had the UtilityAI which seemed like a perfect fit for the job. It lets you tweak the values and graphs and can easily produce vastly different behaviour with some value changes.

Implementing Utility AI

Utility AI implementation went through three major overhauls.

First implementation (graph heavy) – This version allowed the designer to create various graphs for different situations. For example if the player’s health is low it will allow the AI to choose from this specific behavior pool based on graph scores. Or if the player is doing a certain action it asks the AI to select from a series of actions based on the situation. After a while, we realized this approach involved a lot of designing and tweaking – the same problem we had with the behavior tree.

Second implementation (distance layers)

The second approach is to use distance and specify a limited series of actions within a range to limit the unnecessary parameters at play. For instance, no point in punching if the player is 50 meters away, but perhaps a stamina gain might be beneficial. This however created some gray areas when AI crossed the distance layers with contradicting actions(move back and then move ahead).

Third implementation (Brute force) – The current way goes over all the present and future possibilities(at least 5 steps ahead) and gives them a score based on a graph, this results in much more thoughtful prediction and less design work. The future implementation will involve optimizing the current approach.

By Brandon Coates

We are announcing a big change today. The fishing minigame has been removed. As a team we discussed the positives and negatives for keeping or removing the minigame. Yet, due to the short development cycle and the fact that half of the development time has elapsed, we have scaled down the game scope. 

However, that does not mean the game quality will suffer any negative effects from our decision. It actually will have the opposite result and greatly improve our overworld and fighting sections. The few team members who were working on fishing now will direct their full efforts to help ensure a high quality experience overall.

If you want to see our game as it was before this decision please play the browser version on itch.io: https://goofballgames.itch.io/kick-some-bass

Feedback from that release was overall very positive, however we noticed that many people refer to our work as “the fishing game.” This is a problem because we are at the core a fighting arena game. Therefore, instead of cutting the fighting and making a purely fishing game we are doubling down on the fighting mechanics of our game and we will ensure it reaches a quality that we are happy with while remaining true to our original vision. A furious fisherman who must punch his way through an assortment of fish to save the world. 

These next few months will be the most busy and hectic development to date so stay tuned for future updates.

By Yash Chamria

Kick Some Bass is an event-driven architecture based on the hybrid implementation of Publish/Subscribe and Observer patterns. The blog will go over how I integrated the Event system in Unity and how the team is using the events to their advantage.

Why an Event System?

Before that, it is important to understand why we decided to use the Event system in the first place. Kick Some Bass has three entirely distinct phases – Interactive Map, Fishing and Fighting. On top of that, each phase will have unique abilities, weapons, scoring system, achievement metrics, input, player moveset, camera system, AI with purpose, and the list goes on. All coupled systems will be hard to deal with and make the development process slow and potentially buggy. 

To avoid spaghetti code and cyclic dependencies, the Event System comes to the rescue. The Event System allows all the systems to stay decoupled and only communicate using the events.

Integration with Unity

An Event System is a combination of events, event subscriber delegates and an event manager working together.

An event encapsulates the necessary data to execute the task.

An event subscriber delegate is used for the callback when an event of the mentioned type occurs.

The Event Manager processes events and matches them with the subscribed delegates, invoking the delegate function pointer.

C sharp(C#) makes the process of handling a function pointer simple and straightforward using the delegates. These function pointers are then associated with an event type. All the events must have an event type attached to them, where the event type is a huge event list enum. After that, any system can subscribe the function pointer for an event type to receive the notification.

Using the Events

The team is already integrating several systems into the event architecture. For instance, the Input System uses events to notify the input detection to the interested classes. This means systems interested in input don’t need to know about the Input System as long as they are subscribed for the events they are interested in, the function pointer will invoke automatically. Similarly, the ability system, fighter system, UI system and many more are event-driven structures.

This allows all the systems to be decoupled, flexible and easy to expand.