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 Sellout, Ludum 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! ??
