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

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

Thanks for the spazzy and snazzy Jazzy Beats time!

And so, the LD40 is finally over, and we’re all going around checking final statements, results and whatnot. Incredible games and fun rides all over the place! Even if I have to say so myself, Jazzy Beats, our entry, did quite well! Working on it was a blast, and we’re so eager to start other projects! (Sure, we still have a lot pending, but that’s besides the point. The job of gamedevs never end).

Here are our results, which are comparable with those of previous entries. On our own averages, we’re doing better in art and audio, but we could still do with more understandable themes and innovative games. But learning is part of what makes LD so great! Just keep on improving!

Of course, I’m proud on the graphical department since I’m the artist, but I actually want to congratulate Robin for scoring so high on the audio section as well, and Jorge, whom without, this wouldn’t be as polished and unique, which certainly were overall factors. Congrats, fam!

But surely, none of this would have been possible without you, people. We couldn’t have gotten the Jam’s 4th place in number of ratings if it weren’t for your constant support. The last few jams we felt we hadn’t given enough proper feedback back and we’re a bit disappointed by it. This time around we focused on giving feedback more than ever, and we’re quite amazed that we’re somewhat featured on the category! Awesome!

The team will be celebrating by sleeping off our different sicknesses and hoping to feel better soon. Maybe some hot chocolate, if we can stand up long enough to prepare it. But while we’re seating, you could come chat with us on our Discord channel or even follow us around on Twitter.

For Jazzy Beats we tried to post some insights in regards to the games development. If you have the time, check the post about building the character logic. There’s also one about making the music and one about making the art.

There’s one about coverage Appreciation for videos and links, and a Happy Holidays post as well. And finally, just assorted Fun Facts. Stay tuned, as Jorge still wants to post a timelapse, and we’re working on the post mortem. Jazzy Beats won’t end!

Once again, in behalf of the team, congratulations to all the LD participants, and we hope to have further chances to develop games along you in the future. Happy holidays, and have a magnificent, whalesome 2018! ?

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