Whale of a Retrospective! Whales And Games History through Ludum Dares!

With the end of the year coming up, television and news sites are flooding with yearly retrospectives and the most marking events of the year, highlighting both the positives and negatives of the past months and what’s bound to be remember of this year for history.

With the end of judging for this Ludum Dare coming up, we thought to do something similar, only instead of it being just about the year, we’re looking at the history of our past Ludum Dare entries from our latest game Super Sellout all the way back to Colossorama! Sit comfortably on your chair (unless you have a standing desk in which case just stand there) and prepare for the history of our Whales And Games team through Ludum Dare editions, how it shaped us, and what we learned from each edition respectively! Leggo! ??

Ludum Dare 36 – Colossorama

If there’s a game that we have to thank for and which was the reason why our team exists nowdays, it is Colossorama. Created for Ludum Dare 36 (August 2016)Colossorama was a simple hack-and-slash sidescroller where you were forced to swap weapons every round to defeat as many enemies as you can while attempting to stay alive on your own.

Colossorama broke what was essentially a two-year-long creative-block towards games for me and Moski, and has since evolved tremendously receiving multiple updates since it’s original debut, being showcased in multiple events, and even gaining a following of its own. In fact, a third major expansion to it is planned to come out early next year, and we are already looking at some other plans we have ready in-mind for beyond that!

Ludum Dare 37 – Hyper Holomayhem

While we ocassionaly make the joke that it’s the game that should not-be-mentioned, Hyper Holomayhem taught us some hard lessons regarding how we should tackle future Ludum Dare editions after Ludum Dare 37 (December 2016). In essence, the game was also a side-scroller free-roaming shooter, where you’d have to tear-away levels by shooting at it’s tiles in order to collect gears that would power the room and regenerate again.

The game, while it obtained good judging scores, taught us a few things regarding how we should tackle scope and design decisions. Always make sure you come up with a pre-set idea as you come out of the brainstorming phase and make sure mechanics are well established so they can be quickly ironed out and improved during the jamming time. Unfortunately, there’s still some one or two-offs where we fall on the same trappings, but overall, it taught us a lot about how to handle things going forward.

Ludum Dare 38 – Petty Puny Planet

With the hard-swallowed lessons from Hyper Holomayhem, our next entry, Petty Puny Planet for Ludum Dare 38 (April 2017) was a complete turnaround of what had happened during the previous game’s development, and, in the opinion of many of our team, might be our best take-away from Ludum Dare so far. Petty Puny Planet was a pick-your-own-adventure type of game where you’d pick different actions to determine a planet’s development, and be faced with random-consequence events that could undermine (or be undermined by) your previous choices.

Rather than teaching us harsh-lessons, Petty Puny Planet instead served as a confirmation of many things we had done right this time around. Keep the scope conformable and well-defined, allowing you to focus immediately on what’s important and establish mock-ups and mechanics so that the rest of the team is able to immediately know where the game is headed. Samurai Jack was also airing at the time, which probably helped the team mood a lot.

It’s also noteworthy that Ludum Dare 38 was the point we officially founded our team under the name Whales And Games which we’ve been using since! ?

Ludum Dare 39 – JouleThief: Charge Your Phone

JouleThief: Charge Your Phone is an odd-one-out when it comes to this retrospective, being the only game in this list that wasn’t originally planned as a Whales And Games title. Rather, the game was originally developed during Ludum Dare 39 (August 2017) as an attempt for Moski to work with a different team while other members of WAG were busy at the time. Taking the role as Joulethief, you’d go around attempting to charge your phone as much as possible while avoiding guards attempting to arrest you for disturbance.

The game noticeably has it’s own noticeable quirks, utilizing 3D physics in a 2D game and even featuring an unfinished level editor. Later on, Kroltan, the game’s programmer, would end up joining the Whales And Games team and has since collaborated with us on two other projects featured on this retrospective. After some recent internal talks, we have finally decided to crown JouleThief as being an official part of the Whales And Games collection and hope for one day to be able to put the game on the limelight it deserves!

Ludum Dare 40 – Jazzy Beats

Following the momentum and good spirits of the original team preserved since Petty Puny Planet, the next game to come out of the team would be Jazzy Beats, an indirect beat-em-up where you brawl against an opposing idol’s fans to convert them to your own, created during Ludum Dare 40 (December 2017).

The game extended on the lessons learned through a Petty Puny Planet, continuing on with the trend of defining the games vision right on the first hours, increasing the project’s scope to involve more mechanics, and allowing team members to experiment and implement their part directly on top of the project files (while previously, all the project setup on the engine side was made by the programmer).

Jazzy Beats was also noticeably our best performance in a judging phase as of yet, both in terms of how many games we’ve rated as well as how many ratings we have received. It has since become our staple goal of what we want to achieve with each consequent judging phase and edition.

Ludum Dare 41 – Wizsnooks

With a new Whales And Games setup and the core team growing, the torch started being passed around the different team members depending on the occasion and availability of the team. The first project to test having different team members on the lead instead of the usual suspects happened with Wizsnooks during Ludum Dare 41 (April 2018). Mixing two incompatible genres, Wizsnooks was pool meets RPG, creating a pool game where you’d have to defeat enemies either using your gear or pushing them into pits.

Wizsnooks turned out to be a nice revelation, being surprisingly innovative with its mechanics mixing both the genres, making it one of the games we have considered giving a revamp too for the longest time, especially considered the different ways the game could be expanded. Overall, it served as a perfect example of the capability of the team to adapt to different team setups and how they can affect the ideas behind a specific game.

However, it still followed the typical three-people team formula we had been using during the previous jams, and that was something we wanted to break with the next edition.

Ludum Dare 43 – Super Sellout

After skipping Ludum Dare 42 as a team (not so much for Moski which had a catastrophic experience instead) we finally reach the current live edition with Super Sellout being developed for the current Ludum Dare 43Super Selloutpitches a runner-game with having to sacrifice mobility and visibility by choosing sponsors as to achieve an higher highscore.

Super Sellout‘s development was somewhat similar to the development of Hyper Holomayhem, with it’s own sets of ups and downs, but at the same time, it was somewhat expected in advance. The jam was the first time we experimented with having most of the team (that’s five out of six people) in a single jam, rather than going with usual three-people model. In essence, it was a team exercise, and we have certainly gotten some good pointers about how to manage future editions and projects when they involve more people than usual.

While we could go into more detail regarding the lessons we learned, we still have our usual post-mortem coming up in the following days detailing both what went right and what feedback and experiment taught us.

And that wraps it up! While the judging of Super Sellout is still going on, it’s always a nice lesson to go back and retrospect through our history as a team and jammers, realizing the different lessons we learned throughout the different editions. We believe that the next jams will continue evolving us as a team as we tackle different genres and experiment with different ideas and as we keep refining our formula and identity.​ ?

As the year comes to a close, we have a bunch of new ideas and experiments we want to make, but we’re yet to see how our team evolves. From adopting a new roadmap, to attempting to build a more complete experience, we’re sure the time between this and the next edition of Ludum Dare is going to be surprising. It’s quite sad to see the event reduced to only two editions a year, but we’ve already got our scopes sighted for other events we’d love to join!

If you’d like to keep up and join us in the wild ride the next year is going to be, we totally recommend you to follow us on Twitter and join us on Discord where we’ve got an active community of developers, artists and even just traditional gaming peps. You’re also obviously free to share your Ludum Dare games over there! ?

Season’s Greetings from Whales And Games! Happy Holidays!

Happy Holidays, everyone! Season’s greetings from all of us at Whales And Games! While they’re almost over already, we hope they were as snow-white as Whalechan’s hair and we wish you had or are having a fantastic time with yourself, your friends, family and/or loved ones! ??

While the banner is the same as the one we posted last year to celebrate the occasion, we have updated it with a fresh coat-of-paint and made a handful of tweaks. Similar to last year, the banner features characters from previous Ludum Dare entries such as ColossoramaPetty Puny Planet and Jazzy Beats, together with other games we have in development or that were part of our story as a team. Of course, Whalechan and Polite Whale are also present together with other minor characters that make part of our vast array of mascots.

However, if you look closely, we are also added and featured some-brand new characters, most notably, Monetization Man from Super Sellout which was our game for this Ludum Dare! If you feel like giving the gift of saving civilians from an array of different situations, we’d suggest you give it a try! Of course, you might also need to get some sponsors in order to pay-off the bills of the presents you bought yourself…

And that’s really it! We’re hope that you continue to enjoy the upcoming days as we get ready to close off the year! There’s only a few more days until judging ends and we will be replying to everyone that has left us a comment in the game and continue to push through judging and cover as many games as possible. If you’d like to celebrate the holiday mood with some strangers and share your game, you can also do so at our Discord server! Everyone is welcome to join and we’d love to see you there! ❤??

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

The city is in dire need of saving!

The city is in dire need of saving! Our entry’s first screenshot sports this city’s brandest new handsome and brightest hero ready to save those in dire need! I wonder if there’s anyway we can come to monetize this man… 

This is only some very early animation and system progress for our Ludum Dare entry. Just like it was the case with Jazzy Beats, there’s still a lot we need to get down before you can fully grasp how “Sacrifices must be made” makes into the theme of this game, but we promise we won’t keep it a secret much longer! ?

Want a place to chill-out while working on your entry? We’d love to see some of the progress of your own games over at our team’s Discord server!