Hey all! I’m in for the second time now, although it’s more like a first time since things didn’t really go that well last time I joined which was back in April. Never the less, I’m pretty confident that this time around things are going to go marvelously!

Since I’m still a newbie at this, I’ll be joining the Jam version with a friend, The_Moski who will be taking care of the art. Me personally, will be taking care of the programming (and hopefully the design) of the project. For tools I’ll be using Unity together with C#.

At this point I’m just waiting for the theme to be revealed so I can start up early in the morning tomorrow. We’ll be trying to post a DevLog at least everyday.

I’m really pumped for the journey that the next three days are going to be and I’m looking forward to checking the games that all of you are going to be creating! Good luck to all!

Judging and ratings games is finally here after a week long wait! It's time for us to take a moment to explore other's games and give them the scoring and feedback they deserve. Petty Puny Planet 38 has been getting a lot of feedback and we want to make sure we spend the next few weeks giving feedback to others as well.

To commemorate the occasion, and similarly to how other jammers have already posted their own, we have prepared a timelapse video of our development journey during the event. As such, we would like to present you with...

During the development of the event, we used Chronolapse to take a screenshot every minute of the game's progress, and then we stitched them all together to produce a fast-paced timelapse of the game's development. Our intention was to originally make an actual seamless timelapse video, but due to some misconfigurations, that ended up not happening. Oh well. There's always next time for that. :stuckouttonguewinkingeye:

The timelapse is only of the game's development, which means you will only be seeing programming and Unity shenanigans during the whole timelapse. The rest of the team will be annoyed so they'll also make their own small-timelapse of the Game's Art & Co. in future events. :whale:

But, enough talking about the video itself before you even watch it. In case you decide to give it a watch, here it is!

https://www.youtube.com/watch?v=L0kb8NdK7y4

It's still endearing to see lines and lines of code getting added as time starts passing, as well as the Unity scene starting to get shape from a taste-less white box to the final interface, and it's especially satisfying seeing the minutes on the clock counting up until early hours in the morning and back again.

Soon in the future, we also want to publish a post-mortem, but we will leave that for after making sure that we have judged and commented on significative amount of games. As such, expect it sometime towards the end of the week.

In case you still haven't developed your very own puny pet planet yet, you can check make your own over at the Game's Page (which technically links to the itch.io page. The game can be played right in the browser, on all desktop platforms and it even has an Android version if you fancy games with mobile versions! :newmoonwith_face:

We would also love to give a look at your game! We're going to start by commenting on the games of those which have already leaved feedback on our game, but go ahead and share your game with us in the comments! We look forward to playing them!

Thanks a lot, and on behalf of Whales And Games we hope you've enjoyed the timelapse video!

We see everyone is having a great time judging and rating each other games, but let's not forget there's also another very important event going on today! Of course, it's May 4th - The Star Wars celebration day! Hope all the fans are having a great day! To commemorate we even have a poster to celebrate!

Click here for the full-size poster. We didn't want to have it cover the whole page.

If you've got a break between revisiting the movies or what you might be doing to celebrate, check out Petty Puny Planet 38! There's no actual Star Wars stuff in-game though (for hopefully obvious reasons). But it has a moon, just not a space station one. :new_moon:

If you're curious about the game's art process (such as the way the poster above was also designed), @moski posted a post earlier today about how we uses Krita to make the our project's art. We also still have our post-mortem to do and post, so if you've been keeping tab with us, we hope you look forward to it!

Thanks! And have an happy Star Wars day from Whales And Games! :whale:

We're one week away from the end of Ludum Dare 38's judging period and we've been feeling overwhelmed with all the great feedback and reception that Petty Puny Planet 38 has been getting over the last few weeks. As other members of the site have been posting as part of the Ludum Dare tradition, we too, wanted to share the tales and conclusions we've made during our development process and aftermath, through our very own Planet Sized Post-Mortem!

Petty Puny Planet 38 is a pick-your-own-adventure roguelike-ish simulator style game where, as a bigger-than-life entity, it's the player's job to take care of their small pet-planet - and the tiny people on it. This is done by picking between presented choices that are randomly chosen from a pool actions every round.

Every round, however, a random event will happen that can cause different outcomes to the player's planet depending on their choices. Most of the choices made by the player, as well as the random events, have visual impact on the planet, which, together with some random visual elements and colors, makes it so each player will have their very own unique planet at the end of each playthrough.

Certain choices also branch out into others, allowing for even newer choices, while others increase or decrease the population's happiness and wealth. As the player progresses through the game, and depending on their planet's status, certain choices will start appearing which lead to different endings.

Our development team was composed of the same three members that had also participated together last-time during Ludum Dare 37, where we developed Hyper Holomayhem 37. This team is composed of @JorgeGameDev who works with everything Unity-related and handles gameplay programming, @Moski once again being in charge of the game's artistic direction and responsible for all graphical assets, and finally, @ZakBlystone which once again composed unique tracks for the game's soundtrack, as well as all the jingle sound effects that are played in game.

Tools Used

We once again stuck with the tools we've known and have worked on, similar to how we have during all previous Ludum Dares. The game's development was made using the Unity as the game engine with C# as the chosen programming language. In fact, you can even see the whole Unity and programming part in a timelapse we posted earlier when judging started. The art was designed and created on Krita which @Moski has written a blog-post about how the program can be used for developing art for games, and finally, the music and sound effects were composed on FL-Studio.

Game Idea and Design

In order to avoid a similar situation to Ludum Dare 37 where we constantly cross-questioned our design decisions in regards to the game, we decided that for this edition of the jam we would start development once we had an exactly clear idea of what we wanted to go with, and that we needed to decide the idea early on during the first hours of the event.

Once the jam's theme was announced (Small World) each of us brainstormed several ideas that we're then pitched to the remaining of the team members. Eventually, the idea of a decision-making planet simulation game, inspired by the likes of Sort the Court and Civilization was picked, with more brainstorming eventually leading the idea of the planet continuously getting new cosmetics as the player made their choices in order to add extra charm and humour to the established concept.

The decision making around the planet eventually was given extra depth, as making decisions regarding a planet struck similar to somebody taking care of a pet rock, which lead us to start focusing the game - and all the descriptions of it - around the concept of the player owning a pet planet, which eventually lead to the game's name of Petty Puny Planet.

What went right?

Versatile Gameplay and Design

Being a game designed around allowing the player to make decisions at will meant we could progressively add more and more actions and events to the game as development progressed, extending it's gameplay and replayability. This system was designed with Object Oriented Programming in mind, which meant we could easily add new choices and random events to the game without having to do alterations to existing code once their base was programmed.

Towards the end of the jam, we could easily add choices in a matter of a few minutes, requiring only the art assets to be paired with the text scripts which allowed us to quickly multiply the number of actions, events and endings by the final hours of the event.

Pool System Familiarity

A great strength of making a pick-your-own-adventure styled game focused around random choice picks meant that we could reuse the random pool system we had previously developed for Colossorama and Hyper Holomayhem, our previous Ludum Dare games, and expand it by adding new functionality to fit the unique design characteristics of this project.

These changes made to a pool system we already had experience on, made it more versatile, allowing new choices to be added and compared the ones present in the pool when another choice was picked, as well as to give unique conditions to specific actions where, even if an action had already been unlocked, there could still be some requirements that, when not meet, meant the pool system would re-roll the actions. We believe we will continue using this pool system for future projects as well, as it can be easily repurposed to create a roguelike-ish experience.

Overall Game's Development

Similarly to our previous Ludum Dare entries, we put a great deal of focus and attention into making sure that the game's design and game loop was satisfying and polished enough for every player to get absorbed into the game and feel encouraged to keep playing. Deciding on a simple idea, together with the points presented above meant we could focus on adding smaller details as other team members wrote and designed new actions or fulfilled their respective tasks.

This, together with the lessons we learned from our previous experiences, such as having an audio composer on the team, focusing on making design ideas early on the first day in order to avoid delays, in addition to having a web and mobile version available from the moment the game was published on the site, meant that we had a much more accessible and enjoyable game for a wider audience of players and developers alike from the moment the game was released.

It is also to note that a great Samurai Jack episode aired during the jam, which gave extra ~~thicc~~ motivation to the team.

What has feedback told us, and what could we have done better?

Although we normally name this section as 'What could have gone better?' we legitimately think that this was one of our best game jams to date, and definitely one of our projects which had the smoothest development. Therefore, we instead want to re-focus this section to what feedback has told us regarding some game design problems we didn't realize in the game's design during the actual event.

Game Balancing and Action Diversity

Although there's an extensive and varied collection of choices that the player can make throughout the game, most of these need to be unlocked first before they are added to the action pool. This means that, during the early phases of game, there are several actions and random events that are too common, and even intuitive for players starting out. The lack of unique actions in the first choices of the game also make the first parts of the game look the same because of the reduced number of options available during this section of the game.

Some choices were also added for the sake of diversity, in attempt to make the game look more unique on each different run, but a small portion of these ended up not adding any significative branching or changes to the planet's variables, which makes them feel irrelevant.

Early Events and Endings

As an extension of the previous point, there are several random events which reduce happiness and wealth very early in the game. One such example is the Ice Age event, which is drawn multiple times during the first rounds of the game and which constantly reduce the planet's happiness unless the player chooses to Discover Fire almost early on. However, also choosing to Discover Fire results in yet another event which also results in happiness drops when pooled.

With reduced happiness and wealth the player can easily get most of the 'bummer' endings early in the game, feeling almost like a punishment to the player, especially during their first playthroughs of the game, especially before they even have an idea of the actual length a game session can take up to. In fact, we've already witnessed some comments and even an video producer, who believed some of the 'bummer' endings were actually full-fledged endings.

Closing Remarks and what could we improve on?

As mentioned above, we really believe that this has been the smoothest Ludum Dare we've participated in, and as such, we're really proud of our effort and of how the game's been performing. The game has quickly beat the amount of total views of our previous project in a much smaller time-frame.

Before closing this post-mortem, of course, we still want to leave some closing remarks summarizing the points above, as well as lessons to take present as we move forward:

• Focus on an idea right from the start and and focused on replayability can give enough of a time-frame to focus on expanding and adding content to the original idea of the course of the jam.
• Build a system which allows for easily adding new content, so if you have time to spare by the end of the jam, you can use it to keep adding additional content into the game. Remember, one thing is new content and another thing is whole new features. For the latter, it's preferable you save them for post-jam versions if you're closing in on time.
• Check out previous technologies you might have developed (especially if you're participating in the Jam instead of the Compo) and check if there's something you can re-use from them that can help you save time on your newest project.
• Even if gameplay is important, try to leave a small time-frame to give some extra polish to the game. Some small polish here and there can really improve the first impression the player gets when they play your game! :smile:
• Try to spread tasks around if you're participating as a team. Assuming the previous points have been taken care off, have team members help out in other sections (such as writing, planning or preparing descriptions for submission hours), or have them make extra content. It's better to have left over content, than missing content.
• Make sure your player gets an intuitive experience. The player should understand the impact of their choices or the reason why a specific mechanic is in-game. Give them space to experiment without them thinking "That's it?".
• If you're game could be easily and quickly adapted for other platforms, such as Web or Android then try to support them. It will allow your game to be experienced for another great number of players which might have different preferences when it comes to the platform they play games in.
• Samurai Jack will end in two weeks. It's sad we know, but it's was well worth the ride. Watch Rick and Morty while you're at it too.

Some of the improvements we've got planned for possible future iterations of the game, and which we look forward to getting feedback on the upcoming weeks include:

• Make it clear which type of actions is which and explain if an action is a repeatable action (which means the tasks can be repeated multiple times) or unique (tasks that can only be picked once, branching out into new choices).
• Consider adding the effect of an action when it is selected, giving the player some insight regarding the consequences or unlocks of picking their action. This can allow the player to better plan for the next round or playthroughs.
• Add more variables and encourage players to tailor their playthroughs towards a very specific planet proficiency.
• Add more replayability incentives, like obtaining an ending on a specific playthrough leading to more actions being unlocked on the next playthroughs.

Again, most of these things and improvements we came to realize regarding the game was only possible thanks to the feedback everyone has been posting in regards to the game and what they believed were the strong and weak points of the game. We seriously take all the feedback into consideration, and we try to reply to everyone who comments on the game in order to strengthen discuss about what could be improved. You're the reason we keep going forward and improving, so thank's a lot for everyone who has given us feedback so far, and we look forward to playing more of your games soon. :heart:

Thanks a lot for reading! We know that's quite the extensive post-mortem, but once again, we hope that there are some lessons that can be of use for you and your team, or that you've at least enjoyed reading it and know more about the highs and lows of our development process during this edition of the event.

Experimenting with this new game in specific has been a blast for us, and we really like the direction the game has been going, and the overall reception of it as we explained. Now that this post-mortem has been finally posted, one of the thing we got in mind next is having the community (either developers and players) get involved with future developments of the game in case we go through with it. We hope you look forward to it! :whale:

Once again, thanks a lot. If you haven't already, and wish to keep up with our future development, give us a follow at our team's twitter at Whales And Games and if you still haven't already, give Petty Puny Planet 38 a try of your own! We're curious to see how your pet planet will look in the end!

This Ludum Dare’s judging is ending pretty soon, and we couldn’t be happier with the response we’ve received for Petty Puny Planet 38, our simulation-but-not-really choose-your-own-adventure-esque game. Once that’s done, we’ll be more than free to further update the game with some of the feedback we’ve received! :smile:

We’ve got lots of things planned and discussed to further expand the customization of the planet, and the interactions you can have with the game. More choices, more branching, more events, more endings, and some other stuff that could turn each playthrough into an even more unique experience.

However, with all these events planned, we’ve also talked about user-submitted choices and events. So, if you were in charge of adding new stuff to the game, what would you add?

As in, would you like a choice that made your people spend a century bowling? Would you like an event where aliens invade the planet? Would you like an ending where the people evolve beyond comprehension and leave the planet to make their own planets? Do you just want to add a moustache and a monocle to the planet? Anything goes!

Basically, we would love to see some suggestion and ideas coming from you! Anything goes, from events and endings to features or just cosmetics. We will discuss them over, see which would be fun to add, fill in the blanks, and hopefully add them to the game. You can go as far as to suggest actions you would like to see together with the kind of stat bonuses they give and even what kind of cosmetic picking the action would show in the planet!

We’ll credit you, of course. :stuckouttonguewinkingeye: We’re not planning on getting any monetary gain from the game, if it helps keep your mind at ease regarding these user-suggestions. We want to keep this project as a constantly evolving free web-toy that everybody can always look back too and expand upon.

As such, if you would like to see some of your own ideas on the game, head over to the comments (of this very post) and make your suggestions there! No need to follow specific templates, forms or anything like that, just make any suggestions you have to your heart's content! Of course, we recommend you to do it after you give the game a try. :wink:

On behalf of our team at Whales And Games and everyone else that has jammed with us, we thank you for all the support and feedback you have given us during this Ludum Dare edition. The feedback we’ve received this time around smashed all our expectations, and we’re really thankful to all of you!

Now then, onwards with your suggestions! :whale:

Ludum Dare 38 has been a long week gone, however, we still haven't completely closed off the event as we haven't spoken about the results or the future of our game, Petty Puny Planet 38 but most importantly, we haven't also truly thanked everybody that has rated, commented and played our game (we've been doing it every post, but now we want to do it officially)! Guess now's it's the appropriate time to fix that.

First off and most importantly, we really want to thank everybody who has participated. When we set out to develop Petty Puny Planet 38 for this edition of the jam, we decided we would go and try to be more connected with the Ludum Dare community. We wanted to share and talk more about the game, it's development and try to give something back to this amazing community of jammers, attempting to involve those which played the game with it. We got highlighted by Alpha Beta Gamer and several other content creators, made a Timelapse of the game's development, a feature on the program we use for our Ludum Dare games' art, and the other small goofs every now and then.

We tried to rate as many games as we possibly could during the event, even if we were in a excessively busy time. We were able to comment and rate several games, but we were still in no way able to payback the community with the same amount of feedback given as the one we received. With the next event being right at the beginning of summer season, we look forward to finally being able to give back as much love as the one we received, as we'll definitely be more empty-handed by then.

As such, and once again thank you. This has been our biggest, most successful and active Ludum Dare yet, and it's all thanks to everyone who participated, commented, gave feedback, rated and played our game. We are really looking forward for our next one. :wink:

Now, on a separate note, we wanted to give our thoughts and opinions regarding the results of our game. After all, everyone's doing it! We got to fit in as well, right?

There are two conclusions that we were able to draw from the results we've got, especially when we cross compare them with the ones from our previous Ludum Dare game, Hyper Holomayhem 37. For starters, our rankings in the average of all categories went up, with only the Fun, Innovation and Mood categories staying under the Top-80 mark, showing we were able to do an overall improvement in aspects we probably used to put less thought into, most notably, the Theme and Innovation categories.

However, we were actually surprised to see our Overall rank decrease, albeit slightly. In our opinion, Hyper Holomayhem 37 was our weakest entry in all three Ludum Dare's we have participated in, with Petty Puny Planet being the one where we felt we had the smoothest sailing and the most involvement with the community. As such, we over-expected to see the latter get a much better overall position than Hyper Holomayhem, which ranked 51st, with us, this time around, ranking 69th. In comparison, the drop in Fun from 43rd to 190th didn't astonish us as much, knowing that the game, due to it's reading and choice-based gameplay, could be a hit or miss depending on the player.

We have several hypothesis about what could have lead to the increase and decrease in each individual category, and we will be taking those hypothesis into consideration for Ludum Dare 39. The event is already coming up in July, which means we will have to buckle up and take them in mind for when the event comes around! :smile:

As for the future of Petty Puny Planet, we have plans to make a post-jam version with much more content, a handful set of new features and even, possibly, an official release. Given the structure we’ve developed the game with, adding new content is something easily achievable, but we want to make sure everything is top-notch. We don’t know when exactly when we'll be releasing this update, as we’re currently busy with something else, but we hope for it sometime in the upcoming months.

When the update is ready, we will be publishing an article here announcing it, but for the time being, give us a follow over at the Whales and Games Twitter, which we’ll start using more frequently for updates and networking! We would love to keep in touch with the highest amount of developers as possible, so if you have a Twitter account, drop us a link. Even if you would rather not follow us, we would love to follow you and keep up with your work! ​:whale:​

With that, we finally close this Ludum Dare. Oh behalf of Whales and Games, we hope we keep in touch, and we will see you next time on Ludum Dare 39!

Whew! That was a very long needed rest! Congratulations to everyone that has made it through this Ludum Dare! I still haven't had the opportunity to play a great deal of games yet, but I can't wait to see what some of your bubbly wacky minds came up with! If you weren't able to make it to make it to the finish line this time yet, don't push yourself too hard. We also weren't successful on our first jams, but it was a matter of keep trying until we got there!

After having skipped Ludum Dare 39 in August, we're proud to say that Whales And Games is back! And this, time, during our fourth Ludum Dare as a team, we're proud to present you to Jazzy Beats!

Well, if that title card doesn't already tell you what the whole deal is just by looking at it, then let me just tell you straight ahead what the whole game about - Being an Jazz-centring idol (appropriately named Jazzchan) and about capturing your rival's fans hearts and turning them into your fans! The fastest way to get around doing that? Using the power of music, of course! Oh, and punching the living :poop: out of them too.

Why would you want to do that? Well, because that's what your rival told them to do in the first place!

Why don't you just get over her and settle matters with her person-to-person then? Well. Because solving business like that is professional-y questionable, you see.

So, get ready to Jazz and for some beat-em-up action! Make sure you score up on those combos together with your fans! You can check out the game over at our game page. You can either download it and play it on your desktop, or even play it on the browser directly! Yes, even with controller support! The more fans you get on your side, the worse it gets for the opponent idol. Make sure you convert as many fans as possible! :sparkLEs:

We also have to thank all of the feedback we've already got by some great folks over at our game page, and we've been trying to return them as much feedback possible to their games as well (and will reply to the ones they left on our page soon)! :yellowheart: If you got a game that'd you like to get some feedback on, make sure to post a link over in the comments that'll make sure to play them the first opportunity I can get! :blueheart:

On behalf of everyone over at Whales And Games, thanks a lot for the whole experience that this Ludum Dare has been so far. Sure, we're still on the beginning of the judging period, but just with all of the action from these last four days, we already know this is going to be one we're not going to want to forget anytime soon. Thanks! :trumpet: :whale:

This first week of judging has been incredible! We've received an overwhelming amount of feedback and support for our game, Jazzy Beats, that has already surpassed the reception we got with our previous game, Petty Puny Planet during Ludum Dare 38's judging phase. From the bottom of our heart, we don't have a way to thank you enough for it. We've been trying our best to respond to the feedback we've got so far, but know we can still do much more! :hugging:

It is our belief as a team that the 72 hours we spend creating a game during Ludum Dare is only the beginning of the game's lifecycle, and everything that follows from documenting the game's development, to getting the game onto the screens of more players is when the true challenge really comes into play.

As such, part of our goals with this Ludum Dare was that we'd try to branch out our game into more and different platforms beyond those which we've always published our game on (such as itch). With that said, we've released the web version of our game, Jazzy Beats, over on Newgrounds as of yesterday!

Many of you probably know Newgrounds from the early days of the internet, being one of the most popular flash games portal back in the late 2000. However, even after all these years, the site kept growing, and has since started accepting HTML5 and WebGL, keeping Newgrounds as a trustworthy portal even on our current days. Their support when we had Colossorama, one of our past Ludum Dare games, ripped from us and published in their site without our consent in the past was phenomenal, removing it straight ahead, and when we were finally ready to republish the game there ourselves, they immediately accepted us open-armed. 😀

And once again, with the release of, Jazzy Beats, they've have featured us on the site's front-page! Those guys are some sweet honey-buns. :yellow_heart:

If you're interested in the game, give a look over at our game page! Although Newgrounds only hosts the web versions of the games, we also have links for the game available on all major operating systems over at the game's page!

During the upcoming days and weeks we hope to release the game on even more gaming portals we never took the chance to try to publish our games on. We believe it's going to be a great learning experience to understand what it takes to have our game on multiple sites at once.

Once more, in behalf of our team, we once more thank you for all the reception we have gotten this far, and during the next days, we hope to publish more insights into the development of our game. If you're looking for some chit-chat, we also have a Discord available, where we all talk everything from game development to overall gaming! Thank you once more! :blue_heart: :whale:

One year ago, Ludum Dare 37 came to a close on this very day and, we, as a team, had just finished our second Ludum Dare entry - Hyper Holomayhem 37. Although the game's overall placement and results were quite satisfying, every time we think back at the game we can't stop but thinking we could have done several things differently, and how we could have faced our second entry in a completely different light and with a completely different design perspective.

As a result, it's not a game we tend to mention or acknowledge often, however, having a game created during Ludum Dare early on that we ended up not really being proud off taught us several lessons that helped us change the way we looked at Ludum Dare and how we structured our workflow on every event afterwards, both in regards to the jamming part, as well as during judging.

Up to this day, we still carry those lessons together with us, as our latest Ludum Dare entry, Jazzy Beats takes the stage now, one year later. On this post, as the game celebrates it's one year of lifetime, we'd like to discuss some of these lessons we learned the hard way through it's development, and how they ended up shaped the way we approached our latter jams, including, of course this latest Ludum Dare.

A Problem of Scope

Hyper Holomayhem was a side-scroller shooter where, as a jetpack trainee, you had to stay as long as possible in the Hyperdeck, a room that kept constantly changing layouts as it was powered it gears. As you explored the rooms under a time limit, you also had to dodge and shoot enemies, breaks blocks, and return to the room's core to deposit all the gears you'd find spread across the level. The gameplay hook came from the player's free and unrestricted movement, thanks to the jet-pack mechanic, random room layouts and using the player's weapon to destroy enemies and blocks in order to claims the gears spread through-out. Seems fine-ish and probably fun at first, right?

The truth was that for a great part of the jamming period, we hadn't really agreed on what made our game unique, or what made it stand out. Instead, we had several different, unexplored design ideas in our minds that didn't exactly cohere together, from different environments, to power-ups and puzzles, and by the time we decided to focus mostly on the shooting and speed oriented gameplay, we were already reached a point where we had very few time left to flesh up the gameplay without compromising everything else. On other words, we had an issue of scope, and the feeling that we could have made several different design decisions in regards to it, is one that accompanies us up to today.

This feeling taught us some very important lessons that we'd apply to our workflow on the following jams:

1. Always settle for an idea right at the beginning of the jam, and, if preferably, create mock-ups so everyone on the team understands the game vision and direction right from the start. If the idea already sounds like it's going to be an hassle and you haven't even begun it's execution, then it's preferably better to rethink it. The moment everyone in your team understands the concept is a pretty magical moment and one that you can really tell when it really happens.
2. Consider time and resource limitations and work little-by-little. Although every member knew exactly what they had to do at a given time, because of the lack of direction and scope, we ended up not having a clear distinction on what each of us should be aiming for. If the direction was established earlier on as point 1. mentioned, each member could have worked more coherently to improve gameplay.

Another aspect we felt we could have performed much better on as well as the judging phase, especially with it being the first time we were judged on a Ludum Dare. Since it was at the time where everyone on the team was busy with their personal work, school assignments and commissions, we ended up not putting as much heart and thought into it as we could have possibly have, making it the Ludum Dare we have posted the less, commented the less, and received the less feedback on of all of them, especially when compared to our latest ones.

From that point on, we realized it was important to do things differently, and that, for our next Ludum Dare we'd have to rethink most of our workflow, focus on the scope of our next project, and involve ourselves much more in the judging period.

The Next Ludum Dare

Four-months later, and cue Ludum Dare 38. For the second time, we decided to assemble exactly the same team that had participated in Hyper Holomayhem's development, meaning we were practically giving a second try at our team's structure. During the whole development of this new project, we took into considerations the things that we felt we hadn't played out as we expected during Hyper Holomayhem.

For starters, just as the jam started, we decided to make sure we'd completely settle on an idea before beginning the game's development. After almost two hours of discussion and some rough sketches, we had settled on the idea that would lead up to Petty Puny Planet’s creation. Having a clear vision from the start allowed us to plan ahead much better, and by the end of the first day, we already all of the base gameplay down, allowing us to further refine the concept, additional features and polish and add content for the remainder of the event, a polar opposite situation to what had happened with Hyper Holomayhem. How did some of these rough sketches look into the first hour? Well...

...even so, it was this much of a simple sketch that allowed everyone to understand what we were trying to develop.

Same-wise, when it came to the the actual judging phase, we focused on making sure that we’d spread the word about the game across as needed, and, even if we were still on a busy time of our personal lives like we had been during Hyper Holomayhem's development, that we'd take a moment off each day to guarantee we gave the game the attention it deserved.

At the time, we also cemented the name of our brand-evolved-into-collective Whales And Games, using its logo, name, and likeness for the first time ever in this project. Looking back, our focus on the judging phase after a rough first experience, and on getting the branding out for the first time, was an important step that helped lead to everything that came afterwards.

Jazzy Beats

And finally, we arrive at Ludum Dare 40, which judging phase is going on at this very moment. With all the lessons learned with Hyper Holomayhem and the latter, Petty Puny Planet, we took up the Dah-ray once again, creating and developing our currently in-judging game, Jazzy Beats. Applying the lessons we learned through the development of Hyper Holomayhem, and the changes we've made to our workflow through Petty Puny Planet, we we're able to deliver a project which we believe transmits the same values we have as a collective. For many, those values might not be the most important thing when it comes to game jamming, but for us, game jams are a opportunity to try new things, whilst also showing what Whales And Games is truly about.

On Hyper Holomayhem first anniversary, we might not have been able to ship a massive content-update to it as we did with our Ludum Dare 36 game, Colossorama when it was it's one year anniversary, but it's still a game to look back at and, for all it's flaws, realize it was an important milestone that helped us define a lot of our working procedures and direction to go. It's a game that, even if we aren't as proud of as much as others, it's a game that we, at Whales And Games will always consider a part of the family and of our history. One day, we'd like to go back and give the game the proper treatment and love it deserves.

In behalf of our team, thank you for reading, and for all the support you have given us during these past Ludum Dare that has lead us to the point where we are today. We might have gone through some hardships, but getting feedback, and seeing people playing our games is what drives us to keep on going! If you'd like to do some chit-chat, or would just like to keep up with the different things we develop, we also have our very own Discord! It'd be nice to see you there. Thank you! :whale:

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 devlog 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 :heart: 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 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 health, damageDealt, velocity 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 (Starting, OnGoing 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. :trumpet: 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! :whale:

With Ludum Dare 42 on it's way, we're starting to see some new found activity here on the site, as developers and teams begin to ready-up for the next jam.

However, 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! :tada:

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. :whale:

https://youtu.be/E--3C4OmJro

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 @JorgeGameDev, while all of the game’s artistic design, direction and graphic assets were handled by @Moski. Finally, but not least, @RobinhoodPT 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.

However, in contrast to the workflows of previous events, all the team members had acess 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 You, Love 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 Akihabara from 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 devlog, 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.

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 Drop ability.

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! For the others, we apologize in advance for the size of this post in the feed. :sweat_smile:

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! :8ball: 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! :whale:

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… :moneybag: :whale:

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! :wink:

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! :thumbsup:

Being a superhero sounds really cool when you think about it, but when you start looking through the details, you really realize that it doesn’t pay the bills properly. What would any person looking for support do at the time? Accept sponsorships, of course!

In case you missed @moski’s post earlier, our team at Whales And Games is proud to present our game for this Ludum Dare edition, Super Sellout!

Super Sellout is a runner featuring Monetization Man, our usual day-to-day superhero. Unfortunately, upon realizing that being a standard superhero doesn’t pay the bills, he started looking for sponsors, equipping him with all kinds of wacky treats!

Sacrifice your mobility and comfort as you pick various sponsors to increase your chances and rates for large high-score! Some sponsorships reduce our hero’s speed, while others add overlays on top of the game, attract dogs and metal objects to you, or randomly spread billboards all across the map! :money_bag::whale:

This Ludum Dare was certainly an unique one for us, and we have already started going hands-deep on trying to give feedback to as many games as possible. If you have one game that you’d like for us to rate and give feedback on, please leave a link to it on the description because we’d love to play it!

Our team is really hyped for this edition’s rating period, and we can’t wait to see what else we come across! We will be featuring our favorites over at our Discord server too!

Looking forward to playing all of your games! :wink:

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 programming, art 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. :trumpet:

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! :trophy:

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 Dater, Identity 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 Dare participants 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! :whale:

Short post for today as our artist is unfortunately without internet. Like usual, we have a whole backlog of posts dedicated to the development of our latest entry in the works to be posted soon! That being said, we wanted to thank everyone that has rated and commented on our latest Ludum Dare entry, Super Sellout so far! We're humbled by everyone's reception and we have already broken our last entry's ratings in this first week alone.

Thank you all for your support so far! :tada: It’s incredibly humbling to get all of this support from the community and we’ve been trying to do our best with reviews too, trying to cover as many entries as possible while micromanaging through getting material done to post, hosting server events, and handling school work. We’ve been seeing some great entries, and have been trying to always give as much accurate feedback as possible!

Speaking about server events and feedback, our team at Whales And Games has a discord server of our own! It's a mixed bag of sorts, serving as a home for developers, people who enjoy games (look at one of the rooms and you’ll mostly find Smash and Warframe there) and creative people! We’d love for you to join us and share your own game there, and help us make the community more diverse!

Of course, if you prefer something more focused on Ludum Dare, we absolutely also have to give a shout out to the community-run Ludum Dare discord server.

Whichever server you decide to join, we hope to see you there and we look forward to playing more of your games! Cheers! :whale:

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 :blue_heart: with Unity

In case you haven't seen our latest in-depth programming post from Jazzy Beats, our team at Whales And Games mostly 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? :confused:

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.

Sponsor Behaviours :dog2:

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 :moneybag:

Similar to the Sponsors, Score 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 :scissors:

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. :whale: 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! :whale2::tada:

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 Colossorama, Petty 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! :heart::green_heart::whale2:

Waddle on!

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! :tada:

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 43. Super Sellout pitches 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.​ :smile:

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! :whale2:

We're almost there with our game, properly titled Woofice Chair! But we will really have to make the most of these last hour and a half that are left to go to put it up to standard! :ok_hand:

Meanwhile we get it done, which of these is your favourite buddy? Which of them do you want to pet? :dog: