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! ?

Getting the Ball Rolling in Wizsnooks • A Success Story

This has been my favorite LD so far, I had the opportunity to work with great teammates: Moski arting (he’s who drew Skeletorb, seen above), Robin sounding and me coding, and debuting as part of Whales and Games. I had partnered with @Moski earlier, in LD39, and sticked around their Discord annoying everyone until stockholm syndrome hit them again and we decided going for LD41.

Our entry is Wizsnooks, a billiards dungeon crawler!

This is a telling of the Jam’s events through my eyes, but not the game’s post mortem! Not yet at least. Stay tuned for that one some-when this week!

Day One

Our team decided quite early on on the Snooker RPG idea, so I immediately started working on a prototype for snooker physics so the artist’s eyes bled and gave him motivation so we could see with our own eyes.

Then we got the first batch of sprites and I started working on some animations and flair. This will be a repeating theme within this post: make a base mechanic, then fluff it up so it looks good before moving on to the next.

After that, we knew that an RPG needed an inventory, naturally. At the time we thought it would be nice if we had attack and defense stats that would affect how balls respond to collision:

  • A higher Defense stat would increase ball stability after bouncing on enemies, effectively a “knockforward” on hit;
  • As for Attack, it would increase the knock that the enemy ball takes, so a wielder of a strong weapon would need only small nudges to send enemies flying.

I had a lot of time while the artist worked on a crapton of equipment sprites, so I spent a lot of the time writing up a very flexible attribute system based on ScriptableObjects (more on that later) and making the inventory UI with stat comparisons.

Day the Second

After spending a million years perfecting a satisfying loot animation, I bodged together some more code to drop items based on a percent chance. And sneakily, I inserted a new requirement for the code: item rarities! No idea how would they matter, but I wanted colors so I put them in.

We decided going more RPG and less Snooks so we added health and made attack and defense stats affect that.

Oh, and also, the initial tileset was in so I had to learn how to use Unity’s tilemap in 30 minutes. I sorta did, but the repercussions are visible to this day.

Now, obviously, the priority was adding disembodied hands to the game, like any sane person would naturally choose to do.

Had to add events to every possible situation in the universe so soundman could add sounds to them.


Day One’s meneacing seemed to have worked, the artist was quite motivated. All menu sprites were done even faster than I could see them being pushed to the git repository. Tilesets flooded the Assets folder.

I also reused the drop animation’s sprites for a death screen, and burdened myself with the tiny visual detail that the death screen’s sprites are actually the player’s currently-equipped items.

The rest of the time was spent fixing bugs and polishing mechanics, while artman drew more items and soundman made more maps, and balanced artman’s items.

We hit publish, having needed the holy Submission Hour, with the game clocked at 19 items, 4 rarities, 4 monsters and 13 levels. Turns out a lot of items hadn’t been balanced and added to the loot tables (I mean, poor soundman having to do everything today, but such is life), otherwise we’d have 23!

Day the After-th

I spent this day using my webdevguy skills to polish the fuck out of the Itch game page, while secondary platforms were built (Win32, Linux, OSX). I mean, just look at it! So pretty!


I think this was a fantastic jam, finally with a Theme That Didn’t Suck, awesome teammates and no social interruptions (for once)!

So many great games! Now goodbye while I go hunt for some more entries!

Building the Character Logic in Jazzy Beats!

These weeks certainly went fast, didn’t they? It’s kind of amusing to think that judging phase ends in less than 24 hours! However, we at Whales And Games still feel like there’s still so much we could talk and post about the game’s development that we didn’t get the chance to cover during this judging phase (for a multitude of reasons).

In similar fashion to how our graphics designer has written a insight about creating the characters and the art direction and to how our music’s composer wrote another in-regards to his workflow and challenges in composing music, now it’s my turn to talk about the programming structures and methodologies I used for developing the different character’s logic in our Ludum Dare 40 game – Jazzy Beats.

Whales And Games ❤ Unity

For Jazzy Beats, we decided to stick to what we know and use Unity as the engine to develop the game once again. It’s been my tool of choice for almost four years now and I’ve used it on the past four Ludum Dare‘s we’ve participated on. As such, it’s an engine I’ve grown comfortable with, both in terms of workflow, as well as in terms of it’s scripting structure (built on top of C#). As for the IDE itself, I use Visual Studio, not only because of all the tools and integrations it offers when paired with Unity, but also because of how standard of an IDE it is for pretty much everything programming, be it standalone programming, be it with other game engines.

Even so, after all these years using the Unity engine and programming, I still find myself learning better and different ways of getting around, and improving my methodologies when it comes to managing code. Looking back to just a few months ago, when we were updating our Ludum Dare 36 game, Colossorama, for it’s anniversary update I ended up spending a great amount of time just restructuring some of it’s early code in order to optimize it and make it easier to introduce the new mechanics we wanted to add with the new update.

The point is, even while working with the same engine for years, you always end up learning more and further stuff that always helps you refine your future projects as you go, and the past projects we’ve developed were what allowed us to develop Jazzy Beats as it currently stands. One of the programming aspects that ended up being the most important for the game’s development that I only really understood the flexibility as off recently, for example, was Inheritance.

The point is, even while working with the same engine for years, you always end up learning more and further stuff that always helps you refine your future projects as you go, and the past projects we’ve developed were what allowed us to develop Jazzy Beats as it currently stands. One of the programming aspects that ended up being the most important for the game’s development that I only really understood the flexibility as off recently, for example, was Inheritance.

The Power of Inheritance

Although Jazzy Beats‘ behaviours and characters aren’t anything ground-breaking or extraordinary, without some code management and methodologies, it would have been hard to develop and iterate on every single character’s behaviours at the iteration rate necessary during a game jam.

As a consequence, one of my priorities when it came to the game’s development was the code’s re-usability, especially when several of the character’s actions are shared between all of them – be it the Player, the Enemy, or the Fans. One basic example of these actions was the basic punch, which all of these past three characters feature. In order to aid with this re-usability, one of the things I turned too was abstraction and inheritance.

Some of the most basic actions are shared between all of the characters, be them controlled by the player or not. For example, all of the characters use and require components such as a Rigidbody2D, and have variables such as healthdamageDealtvelocity and feature functions such as TakeDamage()and Knockback(). All of these functions are shared between all of these characters and feature no differences. However, functions that require more specific functionality depending of the character, such as Movement() and Attacking() are marked as abstract and are later overridden, and filled in depending on the character we’re working on.

As such, all of the characters on the game derive from one base and template abstract controller known as the CharController which has all the base fields and functionality for a working character. This controller is later inherited and expanded into new and more specific controllers such as the PlayerController in which, for example, the abstract function Movement() is overridden with the code used for recognizing the player’s input. These controllers are also expanded with new functions exclusive to that character, such as ApplySparkAttack() function, which allows the player to use their ranged attack and which is exclusive to their controller only.

This allowed any specific base check or tweaking to be made to all the characters at once, if justified, or specifically tweaked according to the functionality of each individual character. With this structure, I was able to save time with several of the programming tasks that would have been needed if I tried to make separate individual controllers for each of the characters.

However, inheritance is always a mold-able and relative. While writing this section, I can think of several points in which this design and template could be improved further upon. However, given the time limit, you can’t be a perfectionist in regards to it either. Don’t let code perfectionism hold you back while there are features you could be implementing at that moment, but make sure that your code is maintainable to the point you can quickly make changes and adaptations to it.

Character Controllers & Pseudo-AI

With inheritance applied to the characters, the next step was to start connecting this controller structure to the actual gameplay logic of the characters. As referred in the last section, since the base CharController class Movement()and Attacking() functions are marked as abstract, each of the extended controllers have their own different logic for that same function.

For the PlayerController these functions mostly check which input the player has done, such as applying a velocity to the Rigidbody2D depending on the axis that the player is currently inputting, and deploying different attacks depending on their button presses. Not too shabby and a set of controls most likely similar to what most Ludum Dare contestants did with their games as well.

It’s worth side-noting that, for the concern of getting up to speed with Player input and being able to include Gamepad Support out of the box, we used the Unity plugin Rewired as an input wrapper, instead of the default one. It’s a great extension that I absolutely recommend to everyone that has been struggling with expanding Unity‘s input for a while now.

However, it’s when it comes to other characters that the controllers need to be thought of differently. As opposed to the Player, neither Enemy nor Fans have a direct input, meaning that all their actions and decisions needed to be made through code. As such, both of these feature what I like to call a pseudo-AI through a set of checks that are made to see what types of actions the controller should make depending on their situation. I call it pseudo-AI because their decisions are made up of conditional statements, rather than an adaptive artificial intelligence algorithm (such as machine learning which would be insane for a game jam).

The most basic example of these condition checks is with the EnemyController. For Bluessom’s movement and attack patterns, she will check for any opposing-affiliation Fans (in this case, Player fans) in a wide zone around her and target the one closest to her. Depending on the attacks that are currently available and not on cooldown, she will roll a random number to decide which attack she should use on the currently target fan, and will continue attacking them until they eventually turn over to her side again. Since the amount of fans quickly ramps up during the game, eventually, one Bluessom’s attack will hit more than one fan at a time, converting multiple fans in one ago.

The FanController works in a similar fashion to the Enemy one, except instead of Fans moving only when one of the idols is near them, they’ll will always be walking towards the idol opposed to their affiliation (Bluessom’s – the Enemy – fans will always move towards Jazzchan – the Player). They’ll stop when it’s time to perform an attack, at which point they’ll perform the same base attack (the punch) that both the main characters have, followed by a cooldown to avoid them constantly doing the attack. Fans don’t have any other attacks such as the kick or a ranged attack as to avoid having the player having to think on dodging different Fan attacks, making their main focus avoiding and converting fans as fast as possible.

One of the earlier issues we faced upon once the fan count started increasing was that all the fans targeting a specific idol would eventually converge into a single moving line since they’d all be moving towards a single point (the Player’s position) at the exact same velocity. In order to circumvent this, we introduced a slight random variation in their movement speeds (rolled when the fan is spawned), together with a position displacement that’s added to their target’s position, making each fan target a point around the character, rather than the character’s absolute position itself. These two variations alone are enough to make Fans walk and ‘mob’ in a much more believable fashion.

Finally, for the actual hit-checking when one of the characters performs an attack, each of the controllers will perform a box cast in front of their feet to check for any opposing-affiliation colliders in a small zone in front of them. These box casts are placed by their feet as due to the game world’s perspective, as making a box cast of the same size as of the player would make the check return characters that, perspective-wise, seem above the player.

Pictured is the example of these box casts for the different attacks performed by the player. The yellow box represents the zone checked when the player performs a basic punch and the red one for the kicking. Finally, the green circle shows the area of fans converted when the player performs a Ultimate Sax Drop.

As a somewhat trivia piece, one of the original designs we had in mind for the Ultimate Sax Drop involved the play having to perform multiple combos in order to charge it before being able to use it. However, concerned that it could create a contrasting design with the other abilities, we eventually decided to stick with having a cooldown for it.

Unfortunately, this ended up making the Ultimate a safe-guard ability, causing most players to just stick to just using it by late-game, and avoid using it during the remainder of the game. Most of the feedback in regards to the game turns around this, which goes on to prove that, sometimes, playing risky in terms of the design can be a much more rewarding, and it’s a note we will take in mind for future jams.

The Game Manager & State Management

And, finally, the last thing important to the management of the characters is the dungeon master GameManager! The Game Manager is a singleton entry that is responsible for managing the overall state of the game and keeping references to other, single-entity objects that are used through the game.

One example of these objects is the FanSpawner which will continuously spawn more Fans (which always start with affiliation to the Enemy) as to ramp up the game’s difficulty as the game progresses. Having the game starting with only a single Fan allows the player to get a general understanding of the controls before reaching late-game where they have to take multiple Fans into consideration. The FanSpawner will stop spawning new Fans when the total count of them in-game reaches 40 – because y’know, it’s Ludum Dare 40.

To avoid performance and other issues – especially in WebGL – as the amount of Fans spawned increases, the higher the chance of them spawning without an AudioSource becomes higher. This not only saves a lot of memory allocated exclusively to audio (which was causing some music cut-off issues in early development), but also stops the player from hearing 40 different AudioSources all playing footsteps at the same time.

Finally, the GameManager also keeps track of the current GameState which check what state the game is currently on between three different states (StartingOnGoing and Over). These states exist to stop the remaining objects in the game of performing certain tasks when they’re not supposed too (like the FanSpanwer spawning Fans after the game is Over or Starting). Likewise, the character controllers also check this state for this very same reason, and will, for example, stop characters from moving once the game is Over.

Some food for thought for the future is creating a state system for game characters. This would allow for more complex logic and conditions that are not exclusively limited to conditional statements, without potentially creating much additional workload when it comes to programming character and character actions during a game jam.

And that pretty much wraps up this overall programming post! Getting it out in time was one big challenge due to the snowball of occurrences that happened during the whole of the judging period, but here it is, even if it’s just a few hours from the end of judging phase. We still have our Timelapse and Post-Mortem on the way which we hope to make available as soon as we can. However, those will most likely have to wait until after the judging to see the light of day.

In behalf of our team thanks for keeping up with us during this Ludum Dare. Yesterday, when Moski made a post about the coverage we got during this edition, we were baffled that we had almost made it to 200 ratings. However, as of today, we’ve managed to smash that very goal! A whale of thank you to everyone who has made that possible and to everyone which has played our game during these last three weeks. The feedback and engagement by all of the other developers was amazing and completely broke all of our expectations. ? If you haven’t had the chance to play and rate Jazzy Beats yet, now would be the perfect time to do it!

If you’d like to keep up with us at Whales And Games after this Ludum Dare ends, we have our very own Discord channel! It’d be wonderful to see you there! Again, Thank you! ?