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!

Colossorama 36’s Slayed Post Mortem

It’s been two weeks since we released Colossorama 36. Thus, we consider it an appropriate moment to share with you some insight about the development process, including its highs and lows, through this Post Mortem. Without further ado, here is the…

Colossorama 36 is a hack-and-slash arcade game where you play as a gladiator and must use an arsenal of different weapons and items to slay enemy gladiators. Each of these weapons and technologies have a set of different stats and attributes and depending on the player’s choices can determine the outcome of each wave. The player’s score is measured by the amount of gladiator heads the player has decapitated.

The development team is currently made up of two amateur yet eager game developers – Jorge and Moski. Our first project, The Farming One, was developed in RPG Maker over two years ago and despite not having made another major project since then, we’ve been learning several new skills and tools while discussing potential new ideas.

Tools Used

For the development of Colossorama 36 we used Unity and C#, while using Krita for the game’s art. Our familiarity with these programs ensured we knew what set of tools and workflows were necessary for the game’s development.

Game Idea and Design

The game’s concept was grounded up shortly after the jam’s theme (Ancient Technology) was announced. We settled with gladiator fights to use the Ancient aspect of the jam, while the weapons and items could choose from – aptly named Pantheon Techs – defined the Technology theme.

Being a Game Jam game, one of our major focus was to develop a quick yet fun game loop. Various of our decisions, such as replayability were inspired in roguelikes, as well as the decision to go with some randomization and decision making in order to spice things up.

One such example of these elements is the forcing the player to pick between a set of random Patheon Techs at the end of each wave, even if the player must sacrifice a stronger weapon or item for a weaker one. This together with other elements such as randomity of which gladiators get into arena helped ensure that the game’s loop, despite repetitive, is always slightly different.

What went right?

Clear Idea and Direction

Having a clear idea and direction of the project right from the beginning helped establish priorities and decide what needed to be worked on first. This allowed us to quickly shape up gameplay as well as helping setup the art style right from early on.

Game’s Polish and Submission Hour

Since our project was practically always on schedule, we had enough time to polish it and make it as presentable as possible. This, together with the decision to make sure we had everything built by the submission hour, allowed us to focus on setting up the Ludum Dare and pages during that hour alone, as well as making sure everything was packaged correctly.

Cloud Build and WebGL Version

Since none of us had access to a Mac computer, we had no way to directly compile a Mac version. This worried us since it could mean ending up leaving Mac users hanging. We decided to give a look at the Unity’s Cloud Build service to help create a Mac build of the game and thanks to the service we were able to launch a Mac build and support all the three major platforms.

Making some changes to the project in order to export a WebGL version of the game also proved to be a worthwhile effort. With very minimal source changes we were able to create a version of the game that could be played in-browser. Since then, the amount of views (and subsequently, plays) in the page has been five times the amount of desktop downloads.

What could have gone better?

Late Design Decisions

Some design decisions could have been made earlier in the game’s development. One such example is the upgrade system design which design’s was only fully completed during the second day, which ended up causing some delays and content cuts.

Important design ideas like this one should be thought and decided right on the first day, instead of progressively delaying them. This way, we can assure that the design mechanics get practically built in the first day and improvements and content to populate the resulting mechanics developed during the remaining days.

Unexplored Mechanics and Balance Issues

Some of the feedback we have collected mentions how some of the mechanics and weapons are not as useful or as balanced as others. One such example is the jumping mechanic.

Although there isn’t a clear method to ensure every mechanic is well developed, playtesting base mechanics and experimenting diverse alternatives can help us notice which ones need more work and sort out balancing issues.


Audio was also practically an afterthought and something we could have explored much better. We never got into searching for someone to help with audio, which forced us to use royalty free music together with some generated sound effects created with SFXR.

One of the things we definitely want to change in our next project is to find someone that can give us a hand with the audio. This way we can make the game feel more personal, unique and most importantly, distinct when it comes to audio.

Conclusion and Closing Remarks

After all the development and effort we’ve put into Colossorama 36 we have to say we’re pretty happy and impressed with the game’s results, especially after almost two years of hiatus as a team in which we didn’t get to show any new project to the world.

As a short summary of the previous points and on the lessons we take for future projects:

  • Have a clear idea and direction right from the beginning helps quickly shaping up the project. Having mixed ideas can hinder development.
  • Leave an extra time just to make builds and wrap everything up in order to make sure the submission hour is used for submission and showcasing alone.
  • Don’t be afraid to check other services and opportunities as they might help you solve problems you normally don’t have the power to solve. If we hadn’t checked Cloud Build we would have needed to ask someone to make a Mac build for us.
  • When possible, compile a Web version. This allows players and users to play the game directly on the browser, something more accessible than a downloadable version.
  • Important design decisions should be made on the first day instead of delaying them until they need to be forcefully made.
  • Focus more on playtesting and exploring diverse alternatives when a certain mechanic or balance change doesn’t feel as solid as others.
  • Find someone to help with the audio in order to create a more distinct, personal and unique feeling to the game.
  • Some features along with Controller Support and Player Incentives could be bigger focus points for future projects, given there’s enough development time for these ones.

Needless to say, we’re confident that we’ll be able to show new and more varied projects as time goes along. We can only look forward for developing them, and to get to read the feedback of other players and developers.

Thanks for reading! We hope that you’ve gotten something of this – honestly quite big – Post Mortem. It’s been great hearing all the support and feedback we’ve gotten from other developers and players who have given the game a try.

Right now, one of the things we’re working on is an update to Colossorama 36 with some new features and content. We’re not sure when it’s going to be out nor how many updates are there going to be. But at least for now, even if it’s just for practice, it’s going to be one of the things we’re going to be focusing on next. We’ll definitely let you know when these updates happen!

By the way, you can check our Twitter at @JorgeGameDev and @The_Moski since those are the main platforms through which we share our current projects and progress on what we are doing. And don’t forget to give a try to Colossorama 36 if you haven’t already!

Thanks again!