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 Itch.io 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 Itch.io 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
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!
