Scripting Super Sellout’s Sponsors and Behaviours!

The first week of the Ludum Dare rating and judging season has passed! Time certainly flies when you’re busy playing and rating different entries, preparing material to be posted, and recovering sleep due to the unescapable claws of self-inflicted game jam crunch. Sounds like our usual way of doing things here at Whales And Games indeed!

We were expecting to post a blog post going in-depth about how the characters for our latest entry, Super Sellout (which has just smashed our last entry’s record!) were created in terms of art, but unfortunately, our artist has gone internet-less for the weekend and just recently recovered it, meaning that probably for the first time ever, our first in-depth blogpost will be about the programming instead!

So let’s dive right in! This post goes into the technical deeps on how the different Sponsors in Super Sellout were made, how the scoring system of the game works, and the overall benefits of Scriptable Objects and why we keep using Unity! Hope you’re ready, because it’s a long one!

We’re still in ? with Unity

In case you haven’t seen our latest in-depth programming post from Jazzy Beats, our team at Whales And Gamesmostly develops projects through Unity. At least for me personally, it has been my engine of choice for five years and, as expected, I’ve grown comfortable with it in terms of workflow. Our other programmer, Kroltan, has also got some experience in Unity but also has his own hand-full of qualms with it. Our IDE of choice is Visual Studio, and Kroltan utilizes ReSharper on top of it. Visual Studio is pretty much the standard IDE for everything related to programming, being utilized together with other game engines beyond Unity (such as the Unreal Engine) as well.

For this edition of the jam in specific, we decided to risk it and utilize the beta of Unity 2018.3, hopefully to get accustomed to utilizing the new nested prefab workflows that are being introduced in this version (at long last!!) for development. While we did catch a few crashes here and there, and a lot more of them than usual, if we hand’t decided to stick with this version, we probably wouldn’t have been able to properly complete the game during the allocated jam time.

While our post on Jazzy Beats was mostly about Inheritance and how different behaviours were inherited by different characters to perform different actions, with Kroltan‘s inclusion in the Whales And Games team we’ve been trying to do things a lot more through composition. This means, breaking much more behaviours into Components and more specifically, some very underrated data containers in Unity called Scriptable Objects, which allow for fast data management and insertion without necessarily affecting the rest of the game’s structure.

Scriptable What? ?

If you’ve been following Unity in the past years, then certainly you must have already seen them trying to promote the concept of Scriptable Objects through articles, tutorials and talks especially during the last year. While they certainly have been around for a while, there’s still a lot of potential case-scenarios where people could be using them but end up utilizing the standard tools instead. We were guilty of this too, and only recently with us rewriting one of our past Ludum Dare projects for a future update we’re planning did we realize just how handful they can be.

In a short explanation (you can read everything about them in the documentation), Scriptable Objects are essentially instances of classes that can be stored and re-used as if they were assets. If you’re already accustomed with C# and using it in Unity, you’re probably already accustomed to the idea that you can have classes dedicated to holding data without them necessarily having to inherit from Monobehaviour.

Scriptable Objects take this concept further by allowing you to create these data classes as if they were project assets, rather than having them be created by either code, or exposed to an inspector through Monobehaviour. These data assets can then be added to other behaviours, read from the project, etc.

Our Sponsors in Super Sellout utilize Scriptable Objects. Each different sponsor is a different asset, composed of their name, icon, explanation, how many rounds they take to unlock the sponsor, etc. While you can add logic to Scriptable Objects, we strive to keep all of the logic that is not relevant to the concept of the object itself (such as creating objects on the scene, storing runtime values associated with it) on the Scriptable Object class itself. This allows these objects to be independent on their own, serving only as data references, meaning that all of the state related to them (such as if a Sponsor is equipped or not) is stored elsewhere, and not keep with the Scriptable Object when it is serialized and deserialized.

(It should be noted that Scriptable Objects show the Unity standard asset icon by default, whereas we display icons thanks to the Asset Icons extension available on the Asset Store.)

As such, what we do is add all of these sponsors to our GameManager and then utilize that list through the game. The sponsors screen is the best example of this. All of the buttons for the different sponsors are created at runtime, and the icon and name of the sponsor are filled-in at the start. This would allow us to scale this screen and system infinitely if we wanted. We’d have to make graphical changes to accommodate, but we wouldn’t have to directly change anything in the logic itself if we were to add more sponsors.

Each sponsor is delegated to these buttons by creating their EventTrigger when the buttons are instantiated, keeping all the logic in a single place. Sponsors that are picked by the player are then added to another list that keeps track of the sponsors that the player has equipped, and removed accordingly (such as if the player changes their mind on the sponsor equip screen). This list is frequently checked, and helps establish the magic of the following section.

With the sponsor system in place, and with the UI and GameManager wired in, the next part is to wire the different sponsors to actually affect the different facets of the game related to them.

If you have played Super Sellout by now you will have understood the whole gimmick of the game is that you sacrifice movement and your comfort while playing (which we so called sacrificing your integrity) by enabling different sponsors that cause a variety of different effects and obstacles to react to you in exchange of getting an higher score when you rescue people throughout the game (and depending on some sponsors, even based on time you have left).

It’s also worth noting that most Sponsors also have different cosmetics that are overlaid on top of the character. These are stored in arrays together with the rest of the Scriptable Object, and are checked every frame to check if the cosmetic frame matches the one of the current player’s frame.

There are a few gimmicks that are standard and re-used through the game due to the limited time-frame that we had to put the whole game together. For each of these sponsors, their logic is kept in different places, most notably being the ones that the sponsor affects. Sponsors that affect a player’s abilities or controls are kept together with the player, while sponsors that affect objects are kept with those objects.

One of the most standard gimmicks, for example, is the speed reduction gimmick with different sticker sponsors you can add to you which reduce your character speed (while keeping the world speed increasing as always) in exchange of score over time. Being a sponsor that affects the player, the logic for the sticker sponsors are kept together with the rest of the player’s scripts under a PlayerAffects class.

When the game begins, the scripts checks through each of the sponsors to check if they’re activated, and applies the correspondent speed reduction, reducing the player’s speed on the spot. The same is done for other sponsors that also affect the player, such as the Dog Sitters sponsor which applies random forces on the player’s velocity at regular intervals.

As for other behaviours that are affected by sponsors, such as metal objects following you, the check is done on each individual behaviour instead. One such example is the MoveToPlayerBehaviour which causes both metal objects and the dogs to follow the player if their sponsors are active. These perform a similar check to the previous speed-affecting behaviours, checking if the sponsors that are needed to run that behaviour are equipped by the player, before actually executing it’s logic in Update.

Finally, there are the sponsors that make certain objects appear on the stage if they are enabled, such as the billboards and the different puddles. Just as you might expect given the way the logic of the previous objects is checked, these are actually placed on the different rooftop segments ahead of time (or are spawned in at randomly on places dedicated to random obstacles). Once the game starts, they make the same check on ConditionalObjectSpawn likewise to the following behaviour, and depending on the result, choose to disable the object (if the sponsor is not equipped) or leave as it is (if the sponsor is equipped).

If we were to look back and think of a few ways we could have improved the way sponsors are managed and utilized throughout behaviours, we could have potentially done a single SponsorBehaviour class (for objects other than the player) to hold the checks if a sponsor is active or not in a single-place, and then inherit that class to add each specific behaviour.

Inheritance isn’t inherently (heh) bad, however it can very quickly lead to a complicated upkeep of classes and deeper-than-they-need-to-be inheritance levels on top of the classic diamond problem. However, depending on very specific situations, they can potentially reduce project complexity as well, making it a double-edged sword. However, that’s beyond the scope of this post, and instead we will be talking about dough, moolah, simoleans, money, because at the end of the day, that’s the scoring of our game.

Money Dough’ and Scoring ?

Similar to the SponsorsScore Types are also a Scriptable Object in our project. This allowed us to create different score types and rates that are affected by the different behaviours and actions without having to individually declare each of them by code and creating adequate functions. Instead, having them as Scriptable Objects allow us to re-use the different score types, and even derive score types from each other.

We wanted to have a score breakdown screen, and for that the game needed to track where each amount of score came from. We started by making some Scriptable Objects that had some basic information about each score source, where, for example, one “Grandma Saved” would be worth $10. That worked perfectly for simple proportions, but for anything more complicated it was a bit limited.

When sponsors started being implemented, we carefully employed inheritance and created a new kind of Derived Score Type, which in addition to the base multiplication-based monetary value (where each score-type adds a certain amount of score each time) can query the value of other score types to calculate its final value. This was used in some sponsors, which awarded money proportionally to a specific type of heroic act or time.

This approach allowed quick balancing by non-programmers, as well as a clean implementation for the graphical interface, which didn’t need to differentiate between derived and pure score types. It also allowed us to quickly connect any given Sponsor or character in need of rescue to a score-type, and implement them on the scoreboard without any new overhead. Of course, even with such systems in place, there was still a lot of content ideas that had to be cut.

The Cutting Room Floor ✂

Even with all these systems in place, there were still a lot of ideas for different sponsors and modifiers that didn’t make the final cut into the game due to it’s scope. Here are some highlights of these ideas in order to not extend this post by much longer but that we still wanted to share for pure curiosity:

  • Sponsors that would invert or change your controls to random keys.
  • Sponsors that would make you be followed by bees or ghosts, stunning the player when they caught up with them.
  • Sponsors that would play startling sounds every now and then to keep the player on their toes.
  • Sponsors that would cause characters to randomly interrupt the game and talk over it, allowing as little visibility as possible.
  • Sponsors that would add way more visual modifiers to the game, such as making the whole game grayscale, make it look retro, etc.
  • Sponsors that would hid how much money you have achieved or how much time you have left.

With the current system in place, we could theoretically add these new effects and scenarios without much challenge other than creating their respective Scriptable Objects and adding-in their respective behaviours where it’d make the most sense to keep their functionality.

At the moment we have no plans to do an this nor update the game with new sponsors and content. However, if that was to ever become the case, the introduction of several of these ideas would definitely be one of the plans for an expansion!

Phewsh, and that ends that! I hope for those that are into programming this post is at least an interesting read or that it sheds some light in the way that we have decided to handle things with creating our sponsors in our entry, Super Sellout. Likewise to our previous jams, we still have our usual post-mortem on the way, not to mentioned the aforementioned art-cantered post.

In behalf of our team, thank you once again for all the support you have given us so far in terms of ratings and coverage. Ludum Dare is a very important and heartful event for us, and it’s specially thanks to it that we are able to grow as a team and spread our word around. If you haven’t had the chance to play Super Sellout, we invite you to do so, and make sure to send us your game too!

Finally, we also invite you to join us at our team’s Discord server! We have a whole room dedicated to #gamedev and for talking about this type of technical jargon, and we’d love for you to share your own entries with us there!

If you’ve managed to reach this far, cheers, and thank you for reading! ?

Happy Birthday, Jazzy Beats!

While we might have just released Super Sellout yesterday, for us it’s always important to look back on our previous entries and understand how things have changed since. It just so happens that today, last year, was the day we released our Ludum Dare 40 entry, Jazzy Beats!

Jazzy Beats is to us our most important Ludum Dare up to date. While we had already participated up to three times in prior editions, Ludum Dare 40 was the one that we definitely decided to pull of our best, and try to create something with tons-of-personality, and try to rate as much entries on the judging period as we could potentially allocate in our time period.

We ended up creating what some people ended up calling an indirect beat-em-up as your goal, being an idol, was to convert fans of an opposing idol into your own fans by, well… constantly hitting them as they converted-back-and-forth. Due to the scope of the game, it ended up teaching us a lot of about time-saving techniques in programmingart and event sound design! While we talked about making an expanded universe, characters, and a larger version of the game, we have still not have gotten around it, and if we get to it remains to be seen. 

And of course, for the judging period, we ended up rating more than 100 games, making it our biggest ratings season yet!

It’s quite obvious that our latest game Super Sellout, is heavily inspired in Jazzy Beats. From the similar perspective in terms of art, to even the controls of it. Ideally we wanted to create a bigger-gap in terms of presentation between the two, but the two ended up sharing similar perspectives. Gameplay wise the movement systems shared many similarities, but applied to completely different game genres. If you notice closely you might even find some references to Jazzy Beats scattered around on Super Sellout! ?

While we definitely reapplied several of the lessons we learned through Jazzy Beats on our latest game, we also learned a lot of new lessons through Super Sellout as well, most namely, to managing and handling a bigger team with different skill levels. We’ll be sharing dedicated posts about that in the future as well, and we hope this time around it doesn’t take us half-a-year to get around to doing it.

Our personal goal right now is to give feedback and rate even more games than we did last time, and with the larger dedicated team, we hope to achieve that in the follow weeks! We wanted to make sure we can help as many people as we can with their games.

Our first day spreading the word about the game has been amazing so far, and we have already played some real gems! If we had to recommend some, we’d say Sacrificio Inc.Serial DaterIdentity Crisis and Medic!. We’re going to keep searching for more gems, and make sure we share them as we find them!

If you have a game you’d like to share around, then make sure to share it over at our Discord. A lot of Ludum Dareparticipants have already joined us there, and it’s be great fun if even more could join! Of course, if you like to be more shabby, you can also give us a follow on Twitter.

Whale on and sell yourselves out! ?

Jazzy Beats Jazzed Out Timelapse and Post Mortem!

It’s been almost half a year since we have released Jazzy Beats, with it being our fourth project released here on itch.io. To all of those that have played and downloaded our games, and those which have posted some genuinely great videos showcasing your time with our games, thank you! We’re humbled by all your support and we’re glad most of you are having a whale of a time with our games!

Jazzy Beats was developed for Ludum Dare 40, and, whenever an edition of the event goes by, it’s not irregular for the great majority of us to get the feeling of unfinished business. From changes that could have been made to the final product, to smaller things like posts that we’d like to have written and published, most of us get the feeling there’s still so much more stuff we could have done surrounding our Ludum Dare entries. Unfortunately, sometimes life takes a toll and we find ourselves unable to clean the closet of all those things we wish we had time to invest in.

Our team been continuously haunted by one specific instance of that feeling. Back for Ludum Dare 40 (that’s December of last year!) when we developed Jazzy Beats, one of the things that was left in our backlog to publish was both a Timelapse and Post-Mortem of the game’s development. However, with members of our team exchanging countries for a extensive period of time, to master’s degrees and exams, between other issues and tons of Fortnite, we kept pushing it back.

That’s exactly what we’re here to fix today. After a seven month delay (!), we’re here to finally post the finished Jazzy Beats Timelapse & Post-Mortem for the world to see. We decided to finish both of them, as even if the game is already past its prime, we believe both timelapse and post-mortem are an amazing tool of retrospect and that there are lessons to learn regardless of how long it has been since we released the game. That being said, let us give way for both! ?

Timelapse

Similar to our previous Petty Puny Planet Timelapse, I once again used Chronolapse to chronicle the game’s development. This time around, however, the program was set to take a screenshot every 30 seconds rather than every minute to make the flow of the development seem less abrupt at times when programs are suddenly switched.

The reason for screenshots instead of video is that having OBS recording the whole action, even with a moderate computer, still takes a considerable toll on the CPU which causes slowdowns when using the Unity editor and considerable increases compiling times. For someone that’s constantly returning to the editor after the slight change in code, that’s a considerable stack of delays over-time. Screenshots also allow me to revise them and much easily cut sections where I get AFK or leave a window open for extensive periods of time (as I am performing stuff on the other monitor) without requiring a bulky video editor.

Once again, the timelapse is only about the game’s development and you’ll mostly be seeing programming scripts starting to compose themselves on screen while the Unity scene starts taking shape and assets are imported. It’s still on the backlog for more members of the team to start making some of these time-lapses more regularly. 

It’s still hilarious for us how Lavasama was the very first thing added to the game. The jump in progress between the first and second day is also really noticeable.

Post-Mortem

Jazzy Beats is an idol-themed beat-em-up game where you indirectly have to defeat your rival idol by fighting against her fans, converting them into your own. Each idol’s fans will walk towards the rival and proceed to attack them, as they attempt to knock them out.

The player, taking the role of jazz-oriented idol Jazzchan (Jazzy), can use punches, kicks, a ranged trumpet attack and an area-of-effect saxophone special to convert fans of her opponent rival, Bluessom, into their own fans. Some of these actions have cooldowns, but they can be used in conjunction to create and increase the player’s combo. The highest combo the player has obtained, together with the time it took them to defeat their rival are displayed in the end results.

However, the player’s rival has similar techniques and attacks at her disposal and will eventually convert the player’s fans back to her side again. Both idols will need to keep converting each other’s fans until one of them gets knocked out.

The game’s development team was composed by three members of the Whales And Games team which had previously worked together on the multiple updates of our Ludum Dare 36 entry, Colossorama. The game’s development and gameplay programming was handled by Jorge, while all of the game’s artistic design, direction and graphic assets were handled by Moski. Finally, but not least, Robin was in-charge of composing all of the game’s audio, from the different tracks in the game’s soundtrack, to the multiple sound effects and their variations.

Tools Used

We once again decided to stick with the tools we use during our day-to-day game development. The game’s development was done using the Unity engine with C# as the programming language, where we used a more inheritance-focused programming structure this time around. Art was created and designed using Krita, a free and open-source digital painting program, which allowed for quickly sketching and coloring the multiple sprites used. Finally, the Music was originally intended to be composed using Cubase, but due to setup problems with the program prior to the jam, the composer instead used their back-up digital audio workstation, Bitwig Studio together with their MIDI controller, which paired-up perfectly with their game jam composing workflow.r

However, in contrast to the workflows of previous events, all the team members had access to the Git repository of the game hosted on BitBucket and had the knowledge of Unity necessary to aid on the implementation of their assets directly on the game’s engine. More details on that on the following sections.

Game Idea and Design

When we look back at the development process of Petty Puny Planet, our Ludum Dare 38 game, one of our personal highlights was how efficient it was to handle the game’s development and design. This efficiency came as a result of having a well-defined game idea, design and vision shortly after the theme was announced, which allowed us to know exactly what we had to do in order to turn the idea into reality.

As a result, we once again decided to stick with a similar starting workflow for this edition of the jam. Once the theme was announced (The more you have, the worse it is…) each of the team members brainstormed several ideas and concepts on their own which were then pitched between all the members. During this concept discussion process, the idea of creating an idol game where you had to attract fans, with setting inspirations from The World Ends With YouLove Live! and the japanese idol industry, struck as the highlight between all of the ideas, although we weren’t able to settle with a solid and enjoyable idea for the gameplay immediately.

After some further discussion in regards to the concept, the idea of adapting the lava lamp inside-joke from the community into an idol character lead to the necessary inspiration to further refine the game’s concept. During this additional discussion, we decided to add mechanics from the beat-em-up genre to the concept, inspired by the likeness of River City Ransom and Skullgirls, only instead of engaging in a direct beat-em-up with the rival idol, you’d instead do it with their fans. This eventually lead to what would be called the indirect beat-em-up design of the game as called by players.

The idol theming of the game, together with the inspiration from multiple and varied sources gave us a flexible concept to work with, which, combined with inspiration from real-life locations such as the districts of Shibuya and Akihabarafrom Tokyo, allowed us to create the unique world and concept that is Jazzy Beats, appropriately titled after the protagonist’s name, Jazzchan and the main action of the game, beating-up. One thing we missed however, was that Jazzy Beats is actually the name of an existing music genre, which lead to some SEO confusion.

The Best Parts of Development

Shared Team Workflow

As mentioned previously in the Tools Used section, the biggest contrast in our workflow as a team in this edition, when compared to our previous projects, was that everyone had access to the project’s repository at all times. In addition to it, both artist and audio composer had newly obtained knowledge of the Unity engine that allowed them to handle the importing and setup of their assets into the game on their own. This allowed for the artist to handle the setup of the graphic assets and animations on the game himself, meanwhile the audio composer handled the setup of audio sources and making sure that the audio was leveled correctly.

On previous events, the programmer would be the one in-charge of importing and wiring-in all of the assets, from the graphics to the audio, which ended up consuming a great chunk of programming time. This not only allowed for the the programmer to invest more time in handling other programming tasks that needed to be taken care off, but also allowed for both of the other members to make sure their aspects of the game were just as they envisioned.

Versatile Structure and Fast Iteration

Described thoroughly in an earlier programming insight, in addition to the shared workflow, another aspect that helped accelerate the game’s development was the versatile structure of the project, especially when it came to object-oriented programming. Likewise to our previous Ludum Dares, one of our main concerns in-regards to the game’s technical design was making sure that content could be easily adapted and iterated upon easily during the game’s development. Adopting an inheritance-focused programming structure helped us make this goal much more accessible.v

In addition, the versatile game’s structure also allowed us to tweak values, cool-downs, and artificial-intelligence parameters on the fly, helping us when balance the game and making sure that Bluessom (the AI controlled character) felt as powerful and skilled as the player. It also helped with the team’s shared workflow, as, while programming tasks were in-development, other team members were able to tweak gameplay values to assure they felt right and balanced.

Multiple Inspirations and Unexplored Genre

Having inspirations from materials of different genres and backgrounds allowed us to handle the game’s concept and mechanics in an unorthodox way, fetching different aspects from each of the inspirations with the intention of creating an unexplored concept with its unique identity. These inspirations affected all of the game’s aspects from the mechanics, to the art and the music, and eventually lead the game to become what we now call an Indirect Beat-em-up.

We originally concerned in regards on how we would make the Indirect beat-em-up gameplay feel solid and fair for the player, mostly due to the fans being automated and controlled by AI. Nonetheless, we feel like we struck an acceptable balance between experimenting with this new concept (together with its setting, art and audio design) and making everything computer-controlled not hinder the player’s experience nor mitigating the beat-em-up genre itself.

What Experience and Feedback Taught Us

Brainstorm and Starting Out

Immediately after the theme was announced, we started brainstorming several ideas and concepts, hoping to plan for a game different from games we had developed before. However, while brainstorming, we kept forcing innovation and differentiation which lead us to spend most of the early hours of the event discussing possible concepts in circles and rejecting ‘standardized’ ideas.

Eventually, we arrived at the final concept, and although the brainstorming process didn’t consume as much time as one of our earlier Ludum Dare games, limiting brainstorming and not-overthinking the concept can help the games development process moving forward faster, something that helped in Petty Puny Planet, one of our previous Ludum Dare games.

Most of the issues starting out however, happened during the first day when we were still converting the concept into actual game mechanics. Since we were still setting up assets and discussing potential gameplay features, there were certain moments where some of the team members were confused about exactly what to work on next, which lead to some early motivational and time losses. By the second day, however, the game’s development accelerated massively, almost to double speed, which quickly restored the team’s spirits and helped prove the game’s vision.

Un-fleshed and Unbalanced Mechanics

While we believe that we have struck a decent balance on making Bluessom behave like the player, there were certain design decisions regarding Jazzy’s abilities that ended up shaping several player’s play-styles in a way that we would rather have avoided.

The most notable example of this case comes from the Ultimate Sax Drop ability, which automatically converts all the fans in an area around the player into their own fans. While we originally thought of making this ability charge by having the player perform combos, we decided to keep is a time-based ability expecting it’d be enough of a constraint players to only use it occasionally. However, since enemies continuously swarm up to attack the player, most players ended up avoiding direct-combat in late game as to play it safe, and instead solely relayed on waiting for the Sax Drop ability to recharge, using it when surrounded by Bluessom fans, and then repeating the process. This lead to a passive play-style that wasn’t exactly of our intention, as we wanted players to remain engaged on active combat from start to finish.

Another case of a mechanic that was left unbalanced was Jazzy’s ranged trumpet attack, which was intended to give the player crowd-control by performing attacks at a distance in case enemies would become crowded. Unfortunately, as we tweaked the values to avoid the ability becoming too powerful, we accidentally made it unreliable, making it strikingly slow to recharge and too small to help in any crowd control.

Going forward, we’d like to implement play-testing in our game jamming routine, as to allow to get some early feedback in-regards to the overall gameplay of the game and help us to better realize what aspects need to be tweaked on and off. We also want to take more risks regarding design decisions, as it was originally the case with the Ultimate Sax Dropability.

Closing Remarks

Despite all the issues with the games balancing, Jazzy Beats is still our-best running Ludum Dare game to date, setting us a new record in the amount of feedback and ratings we have received in a single entry. We consider it our most unique-looking and ambitious game made in a game jam so far, and even if it didn’t have as much content as some of our previous games, it’s still one we are really proud off.

Therefore, before completely closing off this post-mortem, here are some closing remarks regarding the game’s development, which we suggest taking into consideration as lessons for those looking to participate in future game jams and which we will also be reflecting on ourselves:

  • If you’re joining in with a team, allow them to learn and experiment with the tools before the jam period. If other team members, aside from the programmer, also learn to implement their part of the content in-engine, you’ll be not only saving a great amount of time to the programmer, but also allowing those team members to improve their part of the game.
  • Try to make the game’s values (such as health variables, cool-down timers, etc.) and aspects quickly tweak-able in the editor you’re using. This, paired with the previous suggestion, allows other team members to also contribute in balancing and tweaking the gameplay without being code-dependant.
  • Draw the best from a multitude of inspirations and understand how they can improve your game’s design and aesthetics, turning it into something unique. The reason why our game looks different is solely thanks to the inspirations it was based off, and distilling what made them great in the first place. Jazzy Beats doesn’t shy away from the fact it art’s style is inspired in The World Ends With You.
  • Take risks regarding gameplay decisions, and get people to play-test your game as you develop it. This will help ensure and help you get a notion if certain aspects of your gameplay are balanced or not and if they require tweaking that might not be apparent to the game’s team.
  • Cut-corners where necessary, especially in art, where assets can be reused and re-purposed to allow the artist to dedicate more time in creating other assets that can be beneficial to the game. Re-purposing assets doesn’t necessarily down-play them either, as you can still perform changes to them to create even more variation, and some changes in color can be beneficial in other ways, as it was the case with Jazzy Beats’ enemies.
  • If you’re a programmer, experiment with making the game’s code-base more oriented towards reuse and expandability, especially if you’re working with object-oriented programming languages, even during the jam’s period. Practices such as Inheritance and State Management can give you a workbench to quickly upgrade and re-use already existing functionality without the need to re-write or copy code from one class to another. It also has the added benefit of making each element of the game contained on its own.
  • Sometimes, some extra little care in the game’s and material presentation can go a long way. Some of the players have remarked how the title screen animation, interface and even the game’s itch.io page were enough to create them a very strong first-impression.
  • Jazzy is clearly the better idol, and Bluessom is clearly pass her stage time. On the other news, would you like to get Jazzy’s amazing new fan-kit?

What Can We Improve On?

While we would like to continue our work into developing an expansion or an update for Jazzy Beats, at the moment we can’t be sure when or if we will be able to get around to it. However, given the opportunity, some of the changes we would implement, together with some player feedback would be as following:

  • Improve Jazzy’s abilities and tweak them to motivate and reward players to keep up their aggressive and active play-style all through the game, always making sure that they are converting and dodging fans around.
  • Increase the game’s tempo and potentially introduce more music-themed mechanics into combat.
  • Expand the fan-cast with more unique fans that would spice up the streets with unique behaviours and characteristics. Maybe have a healer fan that heals an idol over time, or a fan that attacks slower, but is able to double damage each idol?
  • Add-in a potential versus mode, where each player would each control their own idol and compete to have the largest amount of fans on their side attempting to defeat the other player.

Jazzy Beats was a wonderful Ludum Dare experience, and we would love to keep up the streak. We are really fond of the universe we have created for the game (including the multitude of characters and backstory that we have discussed between ourselves that isn’t shown in the game) and seeing the feedback and comments come into the submission always reminds us why we enjoy dedicating time and ourselves in game development and participating in Ludum Dare. This was also our best event commenting on other jammer’s games and giving feedback yet, and we expect to keep it up on future editions of the event in which we participate!

That’s our most complete (and longest) post-mortem yet! It was quite troublesome to finally get it done, but we’re glad that we had the chance to finally take something out of our long backlog. If you gave a read through it all, thank you a lot for reading!

Our team at Whales And Games is finally starting to tackle some bigger projects and finally complete several items we left pending around for a while and everyone is really excited and looking forward for it. If you didn’t get the chance to play our previous Ludum Dare game, Wizsnooks, now would be your best opportunity to do it! ? If you’d like to keep up with our game development chronicles, we also have our very own Discord server! We’d love to see you there and join up with us for some Fortnite. We’ll be starting with some server activities and extra project development soon!

For everyone that will be participating in the upcoming Ludum Dare, we wish you a whale of a time and that you take the most out of it! We won’t be participating as a team for the upcoming edition, but some of our team members will be joining the jam on their own and will be looking around for teams. Keep an eye out for their entries! ?

Wizsnooks • The Wizardly World of Postmortening

It’s time for the final sprint for Ludum Dare! It’s the last week, and people are going full-throttle commenting and rating! There are a lot of games with less than 20 ratings that deserve some more attention, so be sure to keep contributing to the community! Lots of people here have worked hard to make it through the crunch!

As for Wizsnooks, our loot-frenzy pool action game, we got a post-mortem ready for you. It took a bit longer than anticipated, but we’re still glad that we get to share this with you!

Wizsnooks is a roguelike loot pool hybrid where you clear tables with different layouts by defeating all of the enemies present on it. Enemies are defeated by attacking them with your white-ball, Snooks, or by pushing them against one of the lava-filled holes spread across the table. Once all the enemies are defeated on a table, the game will randomly pick the next one, filled with all new enemy balls to defeat.

When an enemy is defeated, the player is awarded a random piece of equipment of varying rarity which alters Snooksdefense and attacking stats, making it progressively easier to defeat more and harder enemies. Equipment can also be dischanted as to heal some of Snooks health and inventory prioritization is a must. However, no amount of equipment will save Snooks if they fall into a lava-filled hole!

Although we kept our same team formation (one programmer, one artist and one composer) for this Ludum Dare, this time-around, the team was mostly composed of members which have recently joined our team at Whales And Games , with the exception of Moski, returning as the game’s artist. Kroltan, which had previously participated with Moski on the creation of JouleThief: Charge Your Phone joined as the team’s programmer, and Robin, which had participated with us on previous Ludum Dare entries, such as Colossorama and Jazzy Beats returned as the game’s sole audio composer.

Tools Used

Wizsnooks was developed with a mix and match of programs which we normally use during our daily game development workflows, along with our vision and sweat. Some of these tools, as well as some of the plugins for each respective tool, that we used include the following:

Game Idea and Design

Because of timezones and availability, not everyone on the team was present at the announcement of the theme. Shortly after the theme was announced, some members got into brainstorming, then one left and another came to further discuss more ideas.It wasn’t until about 12 hours after the theme’s announcement that the game’s concept of “Snooker but with roguelike elements and loot” finally materialized with everyone agreeing on it.

With pool mechanics in mind, the programmer was able to make snookers, enemies, and even random level progression (which some people have mistaken as procedurally generated levels). The musician delivered some of his best tracks to date, and the art was among the most cartoonish the artist has done. The team played to their best strengths and in the end, we were all satisfied with what Wizsnooks became.

The Best Parts of Development

Scope of the Project

The idea of Snooker+Action+Roguelike was accepted almost immediately by the whole team. It was initially created with themes of pool mixed with a medieval setting (which, later in development, was shifted to sorcery). Because of it, we were able to quickly debate about what to add, what to remove, and which direction to take the game to. Many ideas included bosses and enemies taking turns to attack, but we ended up heading on a direction on which skill and inventory management were more important than hoping to survive being thrown into a hole without the player’s input.

The project had it all. A core gameplay loop, attacking and healing mechanics, inventory, enemies, and many levels. Discussing a plan, grounding the possible ideas and dismissing those that would need a lot of tweaking or playtesting.Having a direction made it possible to polish the game, make it as little confusing as we could, and still manage to have a wide arrangement of loot and levels.

Labor Structure, Division and Cooperation

Our core team was composed of 3 people, with a few special mentions of a few others that assisted us with feedback, help with code and moral support. Because of the tools used, the group was able to stay communicated with each other, update the project almost seamlessly and discuss changes and directions. Overall, we all had something to do almost all the time.

Because some of us had the knowledge to work with Unity at the same time, towards the end of the jam, we were making many levels at the same time. While the artist kept preparing stuff for UI and the title screen, the musician was able to import weapon and helmet assets, which allowed to double the loot. Finally, the programmer was able to improve the overall gameplay of the game.

What Experience and Feedback Taught Us

The Physics Could Be Improved

Wizsnooks was made with Unity’s recently added tiling system, which allowed us to create a multitude of maps in little time. However, one of its core problems was that the game’s physics ended up not working as intended. Balls would lose a lot of momentum when touching each other, bounce in weird directions or bounce back when hitting a wall, displaying a weird feeling of friction at times, making it hard to tell where something will end before you hit the cue ball.

Likewise, we should also have given the players the ability to preview how their shot would behave, allowing them to navigate around much easier.

The Camera Shouldn’t Be an Obstacle

With so many levels, there should be a way to be able to look around before hitting the ball. Otherwise, when starting a new level, the player would need to do small hits to avoid hitting a dragon orb accidentally or falling into a lava pit by shooting somewhere without having knowledge of the level’s layout. A common suggestion we got through feedback was to allow the player to look around the map before taking a shot.

Closing Remarks. What Can We Improve On?

It’s been a fantastic experience to work as a team again this Ludum Dare. With Wizsnooks, we adhered to a simple idea and increased it with concepts that were within our grasp, which allowed us to deliver a polished and fun experience (sans a few rough edges) which is what Whales And Games always strives for when creating new projects.

Like many projects in the Ludum Dare, we’d love to see some post-jam enhanced edition of sorts. Pending availability of the team, we’ve discussed things that we’d like to add to Wizsnooks, a lot of which is based on the feedback we’ve gotten from the comments. Some of the changes that we’d make include:

  • Tweaks to the behavior of physics, intending to have something more realistic and intuitive.
  • A common complaint with the game were the odd physics of hitting a ball into a wall only for it to go in an unexpected direction.
  • Add more visibility to the game, since early runs involved people either taking leap-of-faith shots or doing smaller ones to avoid accidentally going into a lava pit or dying when crashing with a dragon.
  • Encouraging trying to take as few shots as possible, possibly by giving a maximum number of shots or giving an extra reward when finishing under a par.
  • More additions like extra levels, items and enemies are a given, but we could consider adding extra obstacles, objects, power ups and the like to add more to the “Wizard” theme.

What’s Next?

Going forward, The Whales And Games team is planning on touching up some of our projects that we have previously shown around (such as on our Twitter wall). Since it’s a growing team, some of the members want to work on updating Wizsnooks, while others want to throw a few surprises in the coming months. There would be some extra touches here and there, and hopefully a few releases. We also want to start interacting more with players and better incorporate fan-feedback into our workflow. If you’d like to join us in this process, feel free to say ‘Hi!’ through our Discord server!


Making the post-mortem was an eye opener for us, and we hope that you can find this insightful as well. Doing an hybrid of snooker and roguelike was something that we couldn’t have even dreamed before the gamejam, and seeing it exist is just amazing. The team is proud of the project we made this time around and about the effort of not only us, but those that supported us from start to finish.

If you’re interested in checking it out, Wizsnooks, could welcome some last minute ratings. It’s been fantastic to once again participate with incredibly talented people at the Ludum Dare, and we’re hoping to stick around for some more in the future. We’ll be crossing fingers and hoping to see you all around! Cheers! ?

A Knight in a Wizard’s Snooker Game

D’oh no, I said Wizsnooks. That’s how I call Wizard Snooker.

So you call it Wizsnooks despite the fact this is obviously a knight.


Okay, this is time for a more abstract post. We’ve made some posts before about Wizsnooks, our roguelike loot plundering pool hybrid, but we haven’t touched the idea of the setting yet. That we waited too long to get to it reflects how it happened in the development cycle: We pretty much left the title and setting development to the end.

On the first night, we brainstormed like crazy, with the idea of a pool game with enemies and loot being the outstanding one. With that in mind, I made the cue ball, a sword, the enemies, and we went from there. The first weapons were all swords.

During the last day, I had the duty to make the logo of the game. The problem was that we still had no name for it. The brainstorming began shortly, with names like Medieballs (because of the setting of fantasy enemies and weapons). To add more flavor to the game, I was asked to make some hands for the cue ball, with armored gloves to further reflect the setting of the game. However, Robin told me that, since the hit sounds were lightning bolts, it’d make more sense if the hands were wizard gloves instead.

That’s when it hit us: The actual setting of the game. Our game would be about wizards meeting at a tavern to play a magical game of pool. Hence, the fire pits, enemies and loot. It sounded fantastic. But we still needed a name. We actually ended up with a lot of them. Here’s a list, including some that didn’t even have anything to do with wizards:

  • Bil Liard in Pool Land
  • Lord of the Orbs
  • The Elder Snooks
  • Tavern of Sorcery and Snookery
  • White Orbs Tavern
  • Poolgeons and Dragorbs
  • Billiard Dweller
  • Snook&Pool’s Tavern
  • Wizorbs Tavern of Potions and Billiards (Quickly rejected because Wizorb is an actual game)
  • Witchery, Poolery, Adventurly
  • Magic-8 Lounge
  • Witchcraft Inn
  • Orb of the Pool
  • Snorb & Bilial’s Tavern
  • Mana Snooker
  • Tavern for Magic Cats who play Magic Pool
  • Wizsnooks (Which kinda sounds like a cat’s name, but we still went with it)

The list is… not complete. There’s many variations and even some that didn’t have to do with wizards at all. The story of this development is not necessarily complete. But one way or another, we finally had a name.

That pretty much covers up the story behind the name. I quickly made up more things like wizard hats, more variety of weapons, and so on. There wasn’t much time left to go full wizard, but we still managed.


It this read got you interested in, Wizsnooks, click here to play! It’s available on your browser and downloadable for Windows, Mac and Linux. If you want to chat, this Discord server is where it’s at. And last but not least, here’s the Whales and Games Twitter, so you can keep in contact with us.

There’s lots of games being shared in the main page. Keep reviewing! Lots of people need the ratings! We’ll continue to check more games as well! Let’s keep pushing! Cheers! ?