Super Sellout Post Mortem – A Bargain Bin of Information!

Ludum Dare 43 is about to wrap up, along with year! Get cosy, comfy and cuddled up. And while the clock’s a-ticking, take a chance to rate some of the games in the danger zone. A few votes can make the whole difference and get people pumped up to receive the new year.

As we leave the year behind and as the jam ends, as per tradition, we’ve got our largest piece of insight with the post-mortem of our very own superhero themed runner Super Sellout! Sit back and relax, as we take you through our journey to sacrifice integrity for the sake of profit!

Super Sellout is a high-score based runner game where, at the start of the game, the player gets to select as many sponsors as they want. While in game, the playable character has to jump from building to building, as to avoid falling in any gaps in-between, all-in-all while interacting with people who need rescuing as to get a higher score and extra time as to continue saving people and ranking sponsor money.

Each sponsor selected at the beginning of a game affects the playthrough in a variety of ways, such as by adding obstacles, slowing down the player or distorting the screen. Sponsors, however, also add score multipliers, forcing the player to sacrifice mobility for a chance at a higher score. Or, as we like to call it, sacrificing integrity for profit!

As a variation to our previous team structures, one of the goals for this edition of the game jam was to perform an exercise with as many team members of the Whales And Games group as possible. Instead of relying on our old tested formula of only having three team members, all with different roles, we instead wanted to brute-test our synergy as a full team and understand how having more than one person in the same role would affect our workflow.

That being said, our formation ended up involving five out of the six members of the Whales And Games team, being structured as following:

  • Moski was, again, the game’s artist, handling all the assets and the graphical direction.
  • Jorge took his role once again as a programmer, after having skipped the last Ludum Dare edition the team participated on.
  • Kroltan reprised his role as a programmer as well, making it their second jam together with the WAG team.
  • Zak joined us once again as the audio’s composer and handled the different music and sound effect tracks for the game.
  • Poncho aided us with overall support, aiding us when necessary, such as in adding more level variations and improving in-game animations.

Tools Used

Super Sellout, in similarity to its predecessors, was also created and developed with the field-tested trusty tools and programs that the Whales And Games team uses in day-to-day development. Some of these programs, in case of the engine and programming side, also utilize plugins in order to smooth-out rough corners in development. The list is quite extensive and is as following:

  • Unity, returns once again as our engine of choice. This time around we decided to use the 2018.3 beta (which has since been released as a stable version) as we wanted to learn and utilize the newly added nested prefabs workflows in a real development scenario for the first time.
  • Rewired, a Unity editor extension that considerably improves Unity’s input systems and management by allowing actions to be easily binded to a variety of input methods, including game-pads, out of the box.
  • Visual Studio, the generation-long development environment, for writing all of the game’s programming.
  • ReSharper, Kroltan’s favorite Visual Studio extension that aids in a multitude of programming tasks, most notably refactoring code. In his words, its “Visual Studio’s equivalent of Word’s Clippy.”
  • Git, for hosting and sharing the project files between the various team members and allowing for easy version control. It gets its own mention in this command list because Kroltan is hipster enough to use only raw Git Command Line.
  • SourceTree and GitKraken, two different graphical interfaces for Git used depending on each team member’s preference. They make managing commits and performing commit merges an easy-peasy task.
  • Krita, the open-source and free-to-use digital art program, used for creating and designing all of the game’s art assets and handsome chins.
  • FL-Studio, for handling sound and audio composition and editing. For most of the team members other than the audio composer, the actual way to handle this program is a mystery to them.
  • Google Office Suite, which is likely the most standard and less-beefy tech of this tool list, but yet, our team has a lot to thank for it given how much we use Docs and Drive day-to-day. In fact, this whole post-mortem was written in co-op using Docs!

In addition to these existing tools, we also experimented on using our internal Whales And Games toolset, Shipyard, during the development of the jam. These include a variety of different utilities that aid us with mostly the deployment of the game, such as being able to build and upload multiple game versions directly to itch.io directly from the Unity editor, as well as pre-setup site-locking systems for the web versions (which were re-hosted on unauthorized sites almost immediately after the game went up). We are planning to release this toolchain as an open-source package at a later date.

Game Idea and Design

As a team of five, we wanted to approach brainstorming in a way where everyone could pitch in, discuss their ideas, and then opt for the best ones to implement into a game. When the theme of Sacrifice was announced, we made a document – visible to all of us – and started writing our ideas on different pages. After all of us felt we had a decent dosage of ideas down, we started to discuss them pretty much one by one.

Oddly enough, we ended up going with a Superhero theme despite it not having been originally suggested or written by anyone in the brainstorming document. There were some ideas of the likes of “save someone over another one” (including one where it’d involve Animal Crossing-esque animals), but we also expected a lot of the entries to be serious and outright macabre. As such we opted for a more light-hearted setting, with vibrant colours and funny characters.

When we settled with the superhero setting, we spent some-time testing implementations, attempting to create a cohesive design. We needed to think of how gameplay, art direction and audio would all tie together. Some of the early aspects of the game involved a hero with an extremely big chin, rescuing grandmas from a tree on a park and jumping over fences, as well as the overall idea of “sacrificing mobility for more rewards”.

After going back and forth with more ideas, we ended up with a similar yet practically different concept. A timed runner that took place over rooftops, where the player would be incentivized to make the game harder for themselves in exchange for the chance at a higher score.

The Best Parts of Development

Early Playtesting and Feedback Involvement

As part of an ongoing effort to improve the quality of our games and making sure we tackle the most important issues of their design, a few months prior to the jam, we set up a community programme seeking for community playtesters to join us and give us feedback about certain points we could improve on our projects to ensure they feel tighter and more rewarding.

One of the aspects we always found lacking in our previous jams was the lack of practical feedback during the development of the game that we could immediately sort out and improve on the moment. While feedback during the judging phase is helpful to figure out aspects that we could improve in the game at a later point, feedback from playtesters during the jam allow us to improve situations and work on issues that would certainly be deteriorating for first impressions of the game during its judging phase, where the game is exposed to the majority of players that will play it during its lifetime.

Thanks to our playtesters, we were able to iron out several aspects of Super Sellout that needed refinement. Some of these tweaks, obtained through their feedback, included communicating what the different sponsors do during the sponsor selection screen, improving the overall readability of menus, and making the impact of certain hazards and sound cues more clear and noticeable to the player.

We also need to take this occasion to thank our existing community playtesters for all the feedback and helping us making the game better!

Team Preparation and Project Control

Since Ludum Dare is an event with very limited time, it’s necessary to find ways to save it during the actual event and during the game’s development. While the actual labour division was not exactly perfect, the preparation of the team and the way we’ve got our tools sorted out prior to the jam allowed each team member to quickly jump into development and catch-up at any time.

Previous methods of project collaboration involved each of the roles sending their files back and forth, working separately and leaving the task to the programmer to combine all of the files alone. While this may have worked in the past with smaller projects and teams, it was not efficient.

Starting with Jazzy Beats last year and carrying it on to future editions, the non-technical team members have been practicing working on Unity, while at the same time getting the hang of committing, pushing and pulling their own project updates, allowing every individual team member to work in almost real-time on the project. Through enough coordination, the process of making and receiving files, giving feedback and tweaking on the go has speed up significantly, and each member has been learning more and more about how to bridge their work with the others.

In addition to standard Git management, there’s also other workflows that we’ve already long embedded into our team, including using Discord to voice chat during the jam and using the aforementioned Google Office Suite for sharing brainstorming and design documents. Finally, there’s also the previously mentioned Shipyard toolchain that has been in-development in parallel with another project of ours that we’re developing an update for, and which proved to be a crucial helper during the game’s deployment.

What Experience and Feedback Taught Us

Team Management and Labour Structure

Like with all of our previous jam entries, our team was divided into the usual roles of programmers, artists and audio composers. While that was all great in theory, the actual practice made it clear that the lines of what each had to do ended up being blurrier than what they originally seemed to be. The programmers had their own styles and methods to approach situations which sometimes lead to stun-locks at times where another programmer was unable to continue their task as it depended on another programmer’s tasks. On the other hand, there were some ideas about design and art were sometimes not properly communicated or discussed beforehand.

One situation where we ended up feeling this the most was during the early phases of brainstorming, where we spent several hours throwing several ideas and concepts attempting to find an idea that everyone was comfortable to begin development with. Unfortunately, because this was a larger team, this led to an never-ending loop of conversation trying to figure out where we were headed. In the end, we went with an idea that was not in the list of anyone, but rather, was made on the spot.

However, even with an established idea, we were too quick to judge it, and with some programmers starting their day earlier than others, it became apparent that the tasks and mechanics that need to be added in weren’t properly made clear between team members, with several gaps of the original idea not filled in with clear mechanics.

One way to improve this aspect in a future edition of the jam would be to clearly elect one or more team members to hold the role of game designers and making sure the whole systematic design of the game is done in advance, or, alternatively, to only allow each team member to pitch-in a limited set of ideas and then refine those until proper systems are achieved.

Not having proper mechanics written down also lead to initiative-related problems, where a team member, unknowing of the tasks that needed to be achieved next, would experiment with different implementations, leading to some conflicts in terms of coding and even overlapping tasks.

The Usual Scope and Unexplored Mechanics Issue

Although we might have been able to make the game seem like it features a multitude of sponsors due to the different modifiers that provide similar situations, one point that several jammers have featured in their feedback was the how the sponsor selection felt lacking in regard to the different modifiers that can be equipped.

In our original game design ideas for the game, there were several concepts for sponsors that weren’t able to make the cut into the game, including sponsors that would invert the player’s controls, add more overlays on top of the game, between many others that unfortunately met the cutting room floor, as described in an earlier development insight.

While it has certainly became an internal joke given that all of our post-mortems mention this one issue in our games, it is one that is likely bound to repeat itself every time we experiment with a different genre or try a different team setup. Trying a new genre whilst trying to achieve the same polish that the team always aims for has proven to be a tough challenge, and normally results in the actual juice of the game to feel underwhelming as we try to figure out what makes those games enjoyable.

However, experimenting with different genres isn’t really a passable excuse. Instead, getting the scope and mechanics right is something that we will keep training as we continue to develop games (and update them, given the chance). In this jam, we have underestimated the time that it’d take to develop the different systems for the different mechanics, both due the given work stack, as well as a result of labour structure issues mentioned in the previous points.

Given the status of our previous entries that got updated or refined designs, it’s possible that all our entries will only really meet their full potential when given a second look, when more feedback has been taken into consideration, and when the development of the systems has reached a point where we are comfortable and fast in iterating them. We hope to get the chance in a future jam to tackle a simpler design we can get more mechanics into.

Closing Remarks. What Could we Improve on?

Despite the fact that Super Sellout had a rocky development at time, it was still very well received by both the Ludum Dare and Whales And Games communities. However, for us internally as a team, it taught us several lessons that we must take attention too when developing our next projects, most notably, when it comes to team management and working with larger teams.

Like previous team exercises, there are several takeaways and lessons we can make from our overall experience during the jam, that we’ll be taking into consideration not only on future editions, but that we hope are also useful and for the benefit of other jammers:

  • While it appears obvious, it needs to be clear at all times that, for proper teamwork, there needs to be a lot more communication. For synergy, initiative, coordination and progress, asking doubts when they arise and achieving agreements when situations arise will keep it all knit together.
  • Although it is a good idea to hear what everyone has to say, when working with bigger teams, it might be necessary to assign one or two people to design the core of the game with the rest of the people working to fill-in any gaps or missing pieces.
  • There’s a time and place for everything. Ludum Dare is a fantastic opportunity to learn and experiment, but the time is also a great constrain if your objective is to learn stuff from scratch. Learning the skills should be better done at one’s leisure.
  • Preparing to work on a project may be as important as actually developing the project. Get the team to set realistic expectations, talk beforehand about the tools of the trade, the limits of the responsibilities, and set up working times. This last bit is especially important when working with international teams.
  • Do not panic. Odds are that things will break down. Keep your cool, and even consider sacrificing scope for the sake of fixing things. Good polish can compensate for having a lot of fun mechanics that crash or bug out half of the time.
  • If you’re participating with a team, make sure that the workflows and file sharing are setup and that all of the members are able to quickly access project files and all the information that is needed. This builds up team independence and allows the different members to implement the parts of the project they’re responsible for.

Beyond the actual lessons of development, we have also received several cues of feedback about how we could improve the game if we were to pick on it again and iterate on it. Some of the things we could think off to improve include the following:

  • Introduce new sponsors and reuse some of the ideas that stayed on the cutting room floor as to introduce more diversity to the game through new sponsors that would behave considerably different from the existing ones.
  • Reconsider the way movement is handled on the game and make it more responsive and tighter to the player. The main aspect that needs to be refined is the player’s jumping, making it feel more responsive, less floaty, and improve its collisions with the rest of the game elements.
  • Balance and improve the game’s scrolling, making it so that the latter half of the run doesn’t feel like a punishment to the player, and that they are able to stay at the centre of the screen most of the time despite the increasing screen velocity.
  • Introduce additional keyboard controls, as some players would have certainly preferred an Arrow and ZX key combo rather than the existing WASD and F key setup. Additionally, potentially introduce more keys to perform the same actions in the same set, so the E key could also be used in alternative to F while using WASD controls.
  • Include more visual diversity in terms of the scenery. Like pointed out earlier, several assets were created expecting a park-like setting, which lead to concepts such as grassy-rooftops. While not necessarily out of the realm of the Whaleverse, it’d be interesting to include different types of architecture.

What’s next?

While we still don’t have any specific plans to develop or create a new content update for the game as it is, we are planning to start an internal programme next year focused on revisiting and updating some of our older games, namely Ludum Dare entries that haven’t really gotten much attention outside of the time-frame they were developed at. Given that we will be deciding which entries to update based on public voting, there’s a likelihood that Super Sellout will be revisited sooner than we expected!

We also want to start working towards longer-term projects with the turn of the year focusing on delivering games that can easily be iterated on with regular content and meant for expansion over time. We are planning to work on one of these projects starting early next year and we think that it’s going to be a doozy!

And that pretty much wraps everything up, doesn’t it? Super SelloutLudum Dare 43 and even the freakin’ year, comrades. 2018 surely went fast, and the next year seems oh so very bright. If you want to sail with us on 2019, you’re welcome to board our Discord Server or if you prefer somewhere more quiet, on Twitter! And hang tight, because as you’ve read earlier, we’re planning on going places!

Get the kazoos, heat the chocolate, wear your best suit, and toast! For a new and bigger year for game development! ??

Jazzy Beats Jazzed Out Timelapse and Post Mortem!

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

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

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

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

Timelapse

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

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

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

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

Post-Mortem

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

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

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

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

Tools Used

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

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

Game Idea and Design

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

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

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

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

The Best Parts of Development

Shared Team Workflow

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

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

Versatile Structure and Fast Iteration

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

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

Multiple Inspirations and Unexplored Genre

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

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

What Experience and Feedback Taught Us

Brainstorm and Starting Out

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

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

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

Un-fleshed and Unbalanced Mechanics

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

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

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

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

Closing Remarks

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

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

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

What Can We Improve On?

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

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

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

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

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

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

Wizsnooks • The Wizardly World of Postmortening

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

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

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

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

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

Tools Used

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

Game Idea and Design

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

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

The Best Parts of Development

Scope of the Project

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

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

Labor Structure, Division and Cooperation

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

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

What Experience and Feedback Taught Us

The Physics Could Be Improved

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

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

The Camera Shouldn’t Be an Obstacle

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

Closing Remarks. What Can We Improve On?

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

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

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

What’s Next?

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


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

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

Petty Puny Planet’s Planet Sized Post-Mortem

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 Jorge 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, Zak 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! ?
  • 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. ❤️

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

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!

Hyper Holomayhem 37’s Hyper Post Mortem

It’s been a full month since we released Hyper Holomayhem 37. With the holidays and university finals, we found little to no time to actually give our experience with Ludum Dare 37 the proper conclusion it deserved. But alas, some free time to be able to write and share with you the highs and lows of the development process of our second time on the rodeo!

Hyper Holomayhem 37 is a side-scroller platformer shooter where, as a jetpacker trainee, you must stay for as long as possible in the Hyperdeck, a room that’s constantly changing layouts as you power it up with gears. Gameplay is based around collecting the gears spread throughout the level which you must bring back to the room’s core under a time limit. Enemies chase you around, and you will have break the blocks in order to get to some gears you wish to collect. Once the time is over, your training is complete.

Our development team was composed of three game developers, each of us with a different area of expertise. Jorge returned again as the gameplay programmer and Moski once again fulfilled his role as the game’s artist, exactly as it had previously been the case with our Ludum Dare 36 game, Colossorama. However, this time around we also had the opportunity of having Zak as the game’s audio composer (which you can read more about below).

Tools Used

Keeping with the pace from last time, we decided to stick with the usual tools for Hyper Holomayhem 37’s Development. The game’s uses Unity as it’s game engine with gameplay programmed in C#Krita was yet again used for producing the game’s art and Zak used FL-Studio for making everything from the Music to Sound Effects.

Game Idea and Design

After the jam’s theme (One Room) was announced, there were several ideas that were placed on the table as potential concepts that we could develop during the event. From all of those ideas, we decided to pick the concept of having an holographic room constantly changing layouts, now deemed in game as the Hyperdeck. Other ideas and concepts included impossible room puzzles and even an Fingered-esque game about room decoration.

The Hyperdeck idea was picked as the chosen idea not only due to the time limit we had to develop the game, but also to allow the game to have extra replayability value which is greatly enhanced in this concept thanks to the ever changing room layouts.

As progress on the game continued during the following days, we decided that we would focus on the game’s airborne platforming, as well as environmental destruction the player could make by destroying the blocks that made up the room’s layouts. These elements were then further expanded on with enemies, extra traps and even power-ups, all of them placed on the rooms at random, which also helped strengthen the game’s loop, even if several ideas had to be left on paper due to time constraints.

What went right?

Games Polish and Completion

One of the aspects that Hyper Holomayhem 37 was mostly praised on was the game’s overall polish. Although we had to make some cuts when it came to the gameplay, we made sure that game still felt complete and solid, as well as progressively let friends playtest the game in order to assure that no issue went unnoticed.

One of the reasons why we favor polishing overall is to allow each player to feel like they’re interacting with a vertical slice of a potential game. This allows them to always know what to expect in case they come back, either on their own or due to an update.

Task Scheduling and Submission

Once the game’s development was put up to speed, task division and scheduling was efficiently put into the place. We paced what needed to be done as we went through the days, and based on what content we knew we would be able to have in the game by the deadline. Same as last time, this allowed the submission hour to be fully dedicated to that for that alone, and based on requests from last time, we also provided a WebGL version right from the beginning.

Audio Composer

One of the things that we felt could have been better explored in Colossorama was the game’s audio. Last time, we were only able to find someone that could give us a hand on composing original tracks a few weeks after the game’s release and update. by that time, the great majority of potential players and Ludum Dare participants had already played the game.

However, with Hyper Holomayhem 37 we were able to find someone who was eager to give us a hand with the audio composing, Zak. Having someone doing and composing audio on the team helped us give the game a set of unique sounds and a great music track to boot, making the game more unique, and distinctive when it came to audio.

What could have gone better?

Overthinking Game Design

As mentioned above, several ideas were outlined right after the theme was announced. The final concept for Hyper Holomayhem 37 was only decided a few hours after the theme announced, which slightly delayed works.

Nonetheless, even after the final idea was picked, there was a period of uncertainty regarding what exactly made our concept unique and what exactly would be the game’s core loop. At the time this loop was only the player going around collecting the gears and bringing them back to the core. This eventually lead to multiple, overthought discussions about implementing features like puzzles, etc.

This uncertainty caused some delays, however, we then realized that the base loop we already had just needed to be spiced up, as collecting gears and destroying the room’s blocks was already engaging by itself, and playtesting helped confirm this fact. We then proceeded to add extra content to further solidify this game loop.

Unexplored Gameplay and Concepts

Despite having settled with our game loop, there was still a lot of content that had to be cut due to the time constraints, some of which caused by the delays of the concept’s uncertainty. Although each of us knew which tasks needed to be taken care off, and what schedule to follow, we believe we could have better explored the game’s concept, as well as added a lot more content into the game. One example of a game’s concept that was not fully explored, and caused us to have a not-so-good score when it came to the theme, was how the Hyperdeck represented a single room.

Some of this content that was unable to be included in the game included more types of enemies, power-ups and even completely changing the room’s aesthetic as the player completed layouts. We still hope to get back to these ideas in a future update.

Conclusion and Closing Remarks

Even if the game’s development was filled with mixed feelings, we’re still happy and glad of the final results, dazzled by how well the game scored, getting a 51st place in Jam Overall.

As a short summary from everything above as well as our notes advice both to you and for future projects:

  • If an idea you have the beginning of jam already seems like it’s going to be complicated to develop, it’s probably better to go for a simpler idea, unless you really want to challenge yourself to execute a complicated one.
  • Schedule your tasks, even if in an informal way. Make sure that every team member has a list of what’s needs to be done, especially if your team members are on different time zones.
  • It’s always for the best to make assets that might end up not being used than not having assets for the time they are needed.
  • Having an audio composer on board can really greatly improve your game and increase its atmosphere and value with unique sounds and music.
  • Don’t overthink your game’s mechanics. Sometimes a few basic and quickly learn-able mechanics are enough to create an engaging game loop and diverse content.
  • Always remember to build your game content, visuals and feel around your game mechanics. Form follows function.
  • Do playtesting often, even if it’s just limited to friends, in order to collect some low-level feedback on what to improve. Ideally, playtest with non-familiar people, as they provide the best and more honest feedback.
  • Focus on exposing your game after you finish it. One extra aspect we feel we could have done better was on spreading word about the game, which we didn’t do as much as we did with Colossorama.

Feedback is the greatest thing a developer can get, and we’re glad that we’ve been able to constantly receive it. Hyper Holomayhem 37 was yet another great game we enjoyed developing, even given the hiccups, and we’re full of ideas on how to improve it, as well as for brand new projects we hope to do soon!

Thanks a lot for reading! As always, even if post mortems are mostly for self-reflection, we have the optimism that those who read these always learn something from them. We’re really glad of our results and the feedback we’ve collected during Ludum Dare, and it’s all thanks to you, the wonderful jammer community.

Our hands are completely full with assignments, commissions and other projects we must get done under a tight time frame, but we hope we are able to come back with some new stuff to show soon, as well as give Hyper Holomayhem a brand new coat of paint and bring it to the same level of content as Colossorama. It’s probably going to take a while, but it’s something we want to do as soon as we can!

If you wish to keep up with what we’ve been doing, you can follow us at @JorgeGameDev and @The_Moski as well as @Zakblystone, which was a honor having as a guest to help compose the game’s audio.

Thanks a lot! Until next time! And don’t forget to try out Hyper Holomayhem 37 if you still haven’t given it a go already!