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!
