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

Whale of a Retrospective! Whales And Games History through Ludum Dares!

With the end of the year coming up, television and news sites are flooding with yearly retrospectives and the most marking events of the year, highlighting both the positives and negatives of the past months and what’s bound to be remember of this year for history.

With the end of judging for this Ludum Dare coming up, we thought to do something similar, only instead of it being just about the year, we’re looking at the history of our past Ludum Dare entries from our latest game Super Sellout all the way back to Colossorama! Sit comfortably on your chair (unless you have a standing desk in which case just stand there) and prepare for the history of our Whales And Games team through Ludum Dare editions, how it shaped us, and what we learned from each edition respectively! Leggo! ??

Ludum Dare 36 – Colossorama

If there’s a game that we have to thank for and which was the reason why our team exists nowdays, it is Colossorama. Created for Ludum Dare 36 (August 2016)Colossorama was a simple hack-and-slash sidescroller where you were forced to swap weapons every round to defeat as many enemies as you can while attempting to stay alive on your own.

Colossorama broke what was essentially a two-year-long creative-block towards games for me and Moski, and has since evolved tremendously receiving multiple updates since it’s original debut, being showcased in multiple events, and even gaining a following of its own. In fact, a third major expansion to it is planned to come out early next year, and we are already looking at some other plans we have ready in-mind for beyond that!

Ludum Dare 37 – Hyper Holomayhem

While we ocassionaly make the joke that it’s the game that should not-be-mentioned, Hyper Holomayhem taught us some hard lessons regarding how we should tackle future Ludum Dare editions after Ludum Dare 37 (December 2016). In essence, the game was also a side-scroller free-roaming shooter, where you’d have to tear-away levels by shooting at it’s tiles in order to collect gears that would power the room and regenerate again.

The game, while it obtained good judging scores, taught us a few things regarding how we should tackle scope and design decisions. Always make sure you come up with a pre-set idea as you come out of the brainstorming phase and make sure mechanics are well established so they can be quickly ironed out and improved during the jamming time. Unfortunately, there’s still some one or two-offs where we fall on the same trappings, but overall, it taught us a lot about how to handle things going forward.

Ludum Dare 38 – Petty Puny Planet

With the hard-swallowed lessons from Hyper Holomayhem, our next entry, Petty Puny Planet for Ludum Dare 38 (April 2017) was a complete turnaround of what had happened during the previous game’s development, and, in the opinion of many of our team, might be our best take-away from Ludum Dare so far. Petty Puny Planet was a pick-your-own-adventure type of game where you’d pick different actions to determine a planet’s development, and be faced with random-consequence events that could undermine (or be undermined by) your previous choices.

Rather than teaching us harsh-lessons, Petty Puny Planet instead served as a confirmation of many things we had done right this time around. Keep the scope conformable and well-defined, allowing you to focus immediately on what’s important and establish mock-ups and mechanics so that the rest of the team is able to immediately know where the game is headed. Samurai Jack was also airing at the time, which probably helped the team mood a lot.

It’s also noteworthy that Ludum Dare 38 was the point we officially founded our team under the name Whales And Games which we’ve been using since! ?

Ludum Dare 39 – JouleThief: Charge Your Phone

JouleThief: Charge Your Phone is an odd-one-out when it comes to this retrospective, being the only game in this list that wasn’t originally planned as a Whales And Games title. Rather, the game was originally developed during Ludum Dare 39 (August 2017) as an attempt for Moski to work with a different team while other members of WAG were busy at the time. Taking the role as Joulethief, you’d go around attempting to charge your phone as much as possible while avoiding guards attempting to arrest you for disturbance.

The game noticeably has it’s own noticeable quirks, utilizing 3D physics in a 2D game and even featuring an unfinished level editor. Later on, Kroltan, the game’s programmer, would end up joining the Whales And Games team and has since collaborated with us on two other projects featured on this retrospective. After some recent internal talks, we have finally decided to crown JouleThief as being an official part of the Whales And Games collection and hope for one day to be able to put the game on the limelight it deserves!

Ludum Dare 40 – Jazzy Beats

Following the momentum and good spirits of the original team preserved since Petty Puny Planet, the next game to come out of the team would be Jazzy Beats, an indirect beat-em-up where you brawl against an opposing idol’s fans to convert them to your own, created during Ludum Dare 40 (December 2017).

The game extended on the lessons learned through a Petty Puny Planet, continuing on with the trend of defining the games vision right on the first hours, increasing the project’s scope to involve more mechanics, and allowing team members to experiment and implement their part directly on top of the project files (while previously, all the project setup on the engine side was made by the programmer).

Jazzy Beats was also noticeably our best performance in a judging phase as of yet, both in terms of how many games we’ve rated as well as how many ratings we have received. It has since become our staple goal of what we want to achieve with each consequent judging phase and edition.

Ludum Dare 41 – Wizsnooks

With a new Whales And Games setup and the core team growing, the torch started being passed around the different team members depending on the occasion and availability of the team. The first project to test having different team members on the lead instead of the usual suspects happened with Wizsnooks during Ludum Dare 41 (April 2018). Mixing two incompatible genres, Wizsnooks was pool meets RPG, creating a pool game where you’d have to defeat enemies either using your gear or pushing them into pits.

Wizsnooks turned out to be a nice revelation, being surprisingly innovative with its mechanics mixing both the genres, making it one of the games we have considered giving a revamp too for the longest time, especially considered the different ways the game could be expanded. Overall, it served as a perfect example of the capability of the team to adapt to different team setups and how they can affect the ideas behind a specific game.

However, it still followed the typical three-people team formula we had been using during the previous jams, and that was something we wanted to break with the next edition.

Ludum Dare 43 – Super Sellout

After skipping Ludum Dare 42 as a team (not so much for Moski which had a catastrophic experience instead) we finally reach the current live edition with Super Sellout being developed for the current Ludum Dare 43Super Selloutpitches a runner-game with having to sacrifice mobility and visibility by choosing sponsors as to achieve an higher highscore.

Super Sellout‘s development was somewhat similar to the development of Hyper Holomayhem, with it’s own sets of ups and downs, but at the same time, it was somewhat expected in advance. The jam was the first time we experimented with having most of the team (that’s five out of six people) in a single jam, rather than going with usual three-people model. In essence, it was a team exercise, and we have certainly gotten some good pointers about how to manage future editions and projects when they involve more people than usual.

While we could go into more detail regarding the lessons we learned, we still have our usual post-mortem coming up in the following days detailing both what went right and what feedback and experiment taught us.

And that wraps it up! While the judging of Super Sellout is still going on, it’s always a nice lesson to go back and retrospect through our history as a team and jammers, realizing the different lessons we learned throughout the different editions. We believe that the next jams will continue evolving us as a team as we tackle different genres and experiment with different ideas and as we keep refining our formula and identity.​ ?

As the year comes to a close, we have a bunch of new ideas and experiments we want to make, but we’re yet to see how our team evolves. From adopting a new roadmap, to attempting to build a more complete experience, we’re sure the time between this and the next edition of Ludum Dare is going to be surprising. It’s quite sad to see the event reduced to only two editions a year, but we’ve already got our scopes sighted for other events we’d love to join!

If you’d like to keep up and join us in the wild ride the next year is going to be, we totally recommend you to follow us on Twitter and join us on Discord where we’ve got an active community of developers, artists and even just traditional gaming peps. You’re also obviously free to share your Ludum Dare games over there! ?

Fun Time with Fun Facts of Super Sellout. For Fun!

Hey you. Yes you. I see you browsing the Ludum Dare front page looking for treasure. We’ve got goods in the form of fun facts of our sponsored-fueled avarice marathon of a game, Super Sellout.

Stick around, for this ought to be interesting, and insight about how a team of five can somehow crunch a game in 72-hours while barely clinging to anything that loosely resembles a spec of sanity. Here we go!

Chin-Scratching Inspirations

After our long back-and-forth brainstorming session we settled on a superhero theme. As such, we wanted a protagonist that looked heroic but somewhat goofy in line of our previous characters. Our inspirations, for an early concept, included Crimson Chin from Fairly Odd Parents and Captain Qwark from Ratchet & Clank.

We didn’t truly like the cyan colored suit for the protagonist, so we kinda took Crimson Chin as an inspiration, making him red and black. However, we also gave it a logo of a white triangle on the chest. Since someone jokingly said he looked like a YouTube inspired hero, we ended up calling him Monetization Man, the hero who “demonetizes crime”.

Grandmas? On trees? On my rooftop? More likely than you think!

Early in development, Moski made grass assets for walking around, fire hydrants and an old lady stuck on a tree. However, since the programmers thought a runner-type game would benefit from jumping, the park got replaced for rooftops, inspired by another piece of trivia in this post. That’s how we got stuck with grandmas stuck on trees stuck on rooftops.

At that point, we threw common sense out of the window (like we normally do as a team) and added dogs, a bunny-suited bunny-girl and a lot of ice cream, beyond the added-in cosmetics that Monetization Man gets when different sponsors are equipped.

Incredibly Paper Inspired

While we were discussing the superhero thematics and were starting to turn the game into a runner, one piece of oddware that was brought up as an inspiration was The Incredibles (yes, the animated picture) video game adaptation for the Gameboy Advance.

While the theming and actions you can perform in that game are vastly different from the ones you can perform in Super Sellout, the game did provide some inspiration as to how to tackle the gameplay perspective and ultimately, how we should design and implement the different rooftops.

And of course, two looks at the game’s style, remove half of the halftone we put on top of everything and you can also see some direct inspirations for the comic-book art style not only from comic books themselves but also from the likes of Paper Mario, with the characters outline with the white outlines and soft shading.

Overbearing Whales And Games References and Internal Jokes

If we were able to give teams human traits, then our team at Whales And Games would be guilty of not having any self-awareness at all. In similar fashion to our previous projects, we cramped our game full of internal jokes and references. Of course, we don’t think anyone will really be able to name them all, but we keep putting those jokes in for self-amusement. Guess we’re the true super sellouts in the end, eh? ?

As an example, Dapperfish is a recurrent character in our games and conversations. You can see a muggler with a Dapperfish mask, and he even appears in his own panel in the main menu. You can even click on him there for a goofy surprise. ?

Of course, the self-referential fun doesn’t end there either as there’s plenty of other situations where we took the opportunity and cramped even more self-love into it!

  • On the main menu, beyond Dapperfish in his own tile, there’s also Whalechan, one of our main mascots, in the credits panel.
  • All of the billboards you can find when you activate the Whales And Games modifier, are as expected, mostly Whales And Games references, including three of them to previous Ludum Dare projects, Colossorama (namely how the 1.3 update has been in development for a while), Petty Puny Planet and Jazzy Beats.
  • Other billboards also have other miscellaneous references, with Maid Dragon parodies and Egg.
  • While you might think that Rob Boss is simply a direct reference to Bob Ross, they have actually appeared in Colossorama, as a playable character. We decided to throw in a reference to the character in Super Sellout as we thought it’d make for an interesting sponsor.
  • And last but not least, there’s also a sticker in reference of Wool Pit which despite not being a Whales And Games project, was Moski’s saving grace from whatever happened during Ludum Dare 42.

A Design as Crazy as a Goat

When the “Sacrifice” theme was announced, each member of the team brainstormed ideas for what to make the game about. And we brainstormed a lot. One of the most popular ideas among us was to make the game about a dating game show, where contestants would get sacrificed if they were not selected for a date.

While that idea never came to be, one of the things that remained as a left over was having a sick goat with a sick goatee as the host, which we later wanted to repurpose to serve as a sort of tutorial for the players in Super Sellout and even interrupt the player based on some sponsors.

Unfortunately, wiring out text-systems into the game were quickly ruled as being too out of scope for the time we had in the jam, and instead we kept the goat as one of the rescuers as a callback to our original idea. Mayhaps the day will still come where he will actually get to be the host.

And that’s your fun time fun facts trivia of today for Super Sellout! We always have a stupid amount of fun working on our games despite the occasional hiccup that happens here and there. In fact, we actually left our development text and voice channels for the game completely open for public-reading over at our at our team’s Discord server!. We’d love to see you (and your games) there!

If you haven’t tried Super Sellout yet, we’d love for you to give it a try and tell us what you think!. We’re still going around and playing as many as we can, and would love to check yours out! Make sure to share it with us, and we’ll get to them first opportunity! Cheers! ?

Super Sellout’s Art Asset Sweatshop

Hey there, fellow whippersnappers. It’s a Whales and Games tradition to share our game development perspective. And, as I’ve done a few times in the past, I’ll be giving y’all some good old insight about the artwork done for our Ludum Dare 43 game. This time, for our not-really-endless and very-slightly-on-theme superhero runner Super Sellout!

Almost every single pixel you see on the screen that’s not text was made with Krita, which is a free open-source digital painting program. If you want to get into asset making, even if it’s pixel art, I recommend it. Just download it, get a $40-$80 tablet, read a few tutorials, and you’re ready to go.

So, with Krita and a tablet, I was able to make spritesheets for pretty much everything. The main character, the people in need, the background, UI, and even the logo. Almost everything starts with a sketch, then lining up, coloring, adding details, arranging, and saving as a backgroundless PNG, to be imported in Unity.

Did I do anything special this time around? Other than trying a different style, not really. Our previous projects, like Petty Puny PlanetJazzy Beats and Wizsnooks, had a very similar workflow. It all starts with some sketches, then making their respective lineart, coloring, shading, and adding final touches.

Granted, actually making in-depth animations could have taken too long, so we took a lot of shortcuts. I’d like to talk some other day about the design and looks, but long story short, we opted for some paper-cut-out style so that we could justify having so few frames, and thus, allow me to make more content in other places. That’s why we’ve got so many people to rescue, different buildings, menus and what not. In a way, you could say I sacrificed some things in one area to add to others.

Krita, the digital painting program, excels at that, painting, but doesn’t mean that it can’t be used for gamedev assets. Heck, I used it for pixel art for Ludum Dare 36 and 37, and I’m pretty sure that people more talented than me could even make vectors or some impressive stuff. At least on my level, it works to create PNG files that can be easily used in Unity by the rest of the team. That includes the characters, UI elements and even the logo.

Gamejams are a very hectic experience, and it’s extremely hard to juggle between designing, programming, making art, music, playtesting, polishing and delivering. If I was able to make artwork that’s easily recognizable, it’s only because the Whales and Games team were hard at work with the rest of the elements. They do what I cannot do, and I do what they can’t do. They’re the best. If you’d like to come hang out with the team at some point, you’re more than welcome into our Discord server. Come in and we’ll talk about Warframe, Smash bros, the dankest of memes, and cute anime girls high end videogame development.

Here’s hoping you’re having a fantastic rating season. We’re still playing games around, and some have been among the best ones I’ve seen in gamejams to date. Y’all are faaaantastic! Anyhow, I believe I’ve overstayed my welcome. If you’d like to have some more insights from my previous art works, do take a look at the following links. And if you’d rather read about scripting instead of art, my little buddy Jorge got you covered. with an in-depth take about the innards of the game. Keep your chins up and have a fantastic weekend, friendorinos! ?

Scripting Super Sellout’s Sponsors and Behaviours!

The first week of the Ludum Dare rating and judging season has passed! Time certainly flies when you’re busy playing and rating different entries, preparing material to be posted, and recovering sleep due to the unescapable claws of self-inflicted game jam crunch. Sounds like our usual way of doing things here at Whales And Games indeed!

We were expecting to post a blog post going in-depth about how the characters for our latest entry, Super Sellout (which has just smashed our last entry’s record!) were created in terms of art, but unfortunately, our artist has gone internet-less for the weekend and just recently recovered it, meaning that probably for the first time ever, our first in-depth blogpost will be about the programming instead!

So let’s dive right in! This post goes into the technical deeps on how the different Sponsors in Super Sellout were made, how the scoring system of the game works, and the overall benefits of Scriptable Objects and why we keep using Unity! Hope you’re ready, because it’s a long one!

We’re still in ? with Unity

In case you haven’t seen our latest in-depth programming post from Jazzy Beats, our team at Whales And Gamesmostly develops projects through Unity. At least for me personally, it has been my engine of choice for five years and, as expected, I’ve grown comfortable with it in terms of workflow. Our other programmer, Kroltan, has also got some experience in Unity but also has his own hand-full of qualms with it. Our IDE of choice is Visual Studio, and Kroltan utilizes ReSharper on top of it. Visual Studio is pretty much the standard IDE for everything related to programming, being utilized together with other game engines beyond Unity (such as the Unreal Engine) as well.

For this edition of the jam in specific, we decided to risk it and utilize the beta of Unity 2018.3, hopefully to get accustomed to utilizing the new nested prefab workflows that are being introduced in this version (at long last!!) for development. While we did catch a few crashes here and there, and a lot more of them than usual, if we hand’t decided to stick with this version, we probably wouldn’t have been able to properly complete the game during the allocated jam time.

While our post on Jazzy Beats was mostly about Inheritance and how different behaviours were inherited by different characters to perform different actions, with Kroltan‘s inclusion in the Whales And Games team we’ve been trying to do things a lot more through composition. This means, breaking much more behaviours into Components and more specifically, some very underrated data containers in Unity called Scriptable Objects, which allow for fast data management and insertion without necessarily affecting the rest of the game’s structure.

Scriptable What? ?

If you’ve been following Unity in the past years, then certainly you must have already seen them trying to promote the concept of Scriptable Objects through articles, tutorials and talks especially during the last year. While they certainly have been around for a while, there’s still a lot of potential case-scenarios where people could be using them but end up utilizing the standard tools instead. We were guilty of this too, and only recently with us rewriting one of our past Ludum Dare projects for a future update we’re planning did we realize just how handful they can be.

In a short explanation (you can read everything about them in the documentation), Scriptable Objects are essentially instances of classes that can be stored and re-used as if they were assets. If you’re already accustomed with C# and using it in Unity, you’re probably already accustomed to the idea that you can have classes dedicated to holding data without them necessarily having to inherit from Monobehaviour.

Scriptable Objects take this concept further by allowing you to create these data classes as if they were project assets, rather than having them be created by either code, or exposed to an inspector through Monobehaviour. These data assets can then be added to other behaviours, read from the project, etc.

Our Sponsors in Super Sellout utilize Scriptable Objects. Each different sponsor is a different asset, composed of their name, icon, explanation, how many rounds they take to unlock the sponsor, etc. While you can add logic to Scriptable Objects, we strive to keep all of the logic that is not relevant to the concept of the object itself (such as creating objects on the scene, storing runtime values associated with it) on the Scriptable Object class itself. This allows these objects to be independent on their own, serving only as data references, meaning that all of the state related to them (such as if a Sponsor is equipped or not) is stored elsewhere, and not keep with the Scriptable Object when it is serialized and deserialized.

(It should be noted that Scriptable Objects show the Unity standard asset icon by default, whereas we display icons thanks to the Asset Icons extension available on the Asset Store.)

As such, what we do is add all of these sponsors to our GameManager and then utilize that list through the game. The sponsors screen is the best example of this. All of the buttons for the different sponsors are created at runtime, and the icon and name of the sponsor are filled-in at the start. This would allow us to scale this screen and system infinitely if we wanted. We’d have to make graphical changes to accommodate, but we wouldn’t have to directly change anything in the logic itself if we were to add more sponsors.

Each sponsor is delegated to these buttons by creating their EventTrigger when the buttons are instantiated, keeping all the logic in a single place. Sponsors that are picked by the player are then added to another list that keeps track of the sponsors that the player has equipped, and removed accordingly (such as if the player changes their mind on the sponsor equip screen). This list is frequently checked, and helps establish the magic of the following section.

With the sponsor system in place, and with the UI and GameManager wired in, the next part is to wire the different sponsors to actually affect the different facets of the game related to them.

If you have played Super Sellout by now you will have understood the whole gimmick of the game is that you sacrifice movement and your comfort while playing (which we so called sacrificing your integrity) by enabling different sponsors that cause a variety of different effects and obstacles to react to you in exchange of getting an higher score when you rescue people throughout the game (and depending on some sponsors, even based on time you have left).

It’s also worth noting that most Sponsors also have different cosmetics that are overlaid on top of the character. These are stored in arrays together with the rest of the Scriptable Object, and are checked every frame to check if the cosmetic frame matches the one of the current player’s frame.

There are a few gimmicks that are standard and re-used through the game due to the limited time-frame that we had to put the whole game together. For each of these sponsors, their logic is kept in different places, most notably being the ones that the sponsor affects. Sponsors that affect a player’s abilities or controls are kept together with the player, while sponsors that affect objects are kept with those objects.

One of the most standard gimmicks, for example, is the speed reduction gimmick with different sticker sponsors you can add to you which reduce your character speed (while keeping the world speed increasing as always) in exchange of score over time. Being a sponsor that affects the player, the logic for the sticker sponsors are kept together with the rest of the player’s scripts under a PlayerAffects class.

When the game begins, the scripts checks through each of the sponsors to check if they’re activated, and applies the correspondent speed reduction, reducing the player’s speed on the spot. The same is done for other sponsors that also affect the player, such as the Dog Sitters sponsor which applies random forces on the player’s velocity at regular intervals.

As for other behaviours that are affected by sponsors, such as metal objects following you, the check is done on each individual behaviour instead. One such example is the MoveToPlayerBehaviour which causes both metal objects and the dogs to follow the player if their sponsors are active. These perform a similar check to the previous speed-affecting behaviours, checking if the sponsors that are needed to run that behaviour are equipped by the player, before actually executing it’s logic in Update.

Finally, there are the sponsors that make certain objects appear on the stage if they are enabled, such as the billboards and the different puddles. Just as you might expect given the way the logic of the previous objects is checked, these are actually placed on the different rooftop segments ahead of time (or are spawned in at randomly on places dedicated to random obstacles). Once the game starts, they make the same check on ConditionalObjectSpawn likewise to the following behaviour, and depending on the result, choose to disable the object (if the sponsor is not equipped) or leave as it is (if the sponsor is equipped).

If we were to look back and think of a few ways we could have improved the way sponsors are managed and utilized throughout behaviours, we could have potentially done a single SponsorBehaviour class (for objects other than the player) to hold the checks if a sponsor is active or not in a single-place, and then inherit that class to add each specific behaviour.

Inheritance isn’t inherently (heh) bad, however it can very quickly lead to a complicated upkeep of classes and deeper-than-they-need-to-be inheritance levels on top of the classic diamond problem. However, depending on very specific situations, they can potentially reduce project complexity as well, making it a double-edged sword. However, that’s beyond the scope of this post, and instead we will be talking about dough, moolah, simoleans, money, because at the end of the day, that’s the scoring of our game.

Money Dough’ and Scoring ?

Similar to the SponsorsScore Types are also a Scriptable Object in our project. This allowed us to create different score types and rates that are affected by the different behaviours and actions without having to individually declare each of them by code and creating adequate functions. Instead, having them as Scriptable Objects allow us to re-use the different score types, and even derive score types from each other.

We wanted to have a score breakdown screen, and for that the game needed to track where each amount of score came from. We started by making some Scriptable Objects that had some basic information about each score source, where, for example, one “Grandma Saved” would be worth $10. That worked perfectly for simple proportions, but for anything more complicated it was a bit limited.

When sponsors started being implemented, we carefully employed inheritance and created a new kind of Derived Score Type, which in addition to the base multiplication-based monetary value (where each score-type adds a certain amount of score each time) can query the value of other score types to calculate its final value. This was used in some sponsors, which awarded money proportionally to a specific type of heroic act or time.

This approach allowed quick balancing by non-programmers, as well as a clean implementation for the graphical interface, which didn’t need to differentiate between derived and pure score types. It also allowed us to quickly connect any given Sponsor or character in need of rescue to a score-type, and implement them on the scoreboard without any new overhead. Of course, even with such systems in place, there was still a lot of content ideas that had to be cut.

The Cutting Room Floor ✂

Even with all these systems in place, there were still a lot of ideas for different sponsors and modifiers that didn’t make the final cut into the game due to it’s scope. Here are some highlights of these ideas in order to not extend this post by much longer but that we still wanted to share for pure curiosity:

  • Sponsors that would invert or change your controls to random keys.
  • Sponsors that would make you be followed by bees or ghosts, stunning the player when they caught up with them.
  • Sponsors that would play startling sounds every now and then to keep the player on their toes.
  • Sponsors that would cause characters to randomly interrupt the game and talk over it, allowing as little visibility as possible.
  • Sponsors that would add way more visual modifiers to the game, such as making the whole game grayscale, make it look retro, etc.
  • Sponsors that would hid how much money you have achieved or how much time you have left.

With the current system in place, we could theoretically add these new effects and scenarios without much challenge other than creating their respective Scriptable Objects and adding-in their respective behaviours where it’d make the most sense to keep their functionality.

At the moment we have no plans to do an this nor update the game with new sponsors and content. However, if that was to ever become the case, the introduction of several of these ideas would definitely be one of the plans for an expansion!

Phewsh, and that ends that! I hope for those that are into programming this post is at least an interesting read or that it sheds some light in the way that we have decided to handle things with creating our sponsors in our entry, Super Sellout. Likewise to our previous jams, we still have our usual post-mortem on the way, not to mentioned the aforementioned art-cantered post.

In behalf of our team, thank you once again for all the support you have given us so far in terms of ratings and coverage. Ludum Dare is a very important and heartful event for us, and it’s specially thanks to it that we are able to grow as a team and spread our word around. If you haven’t had the chance to play Super Sellout, we invite you to do so, and make sure to send us your game too!

Finally, we also invite you to join us at our team’s Discord server! We have a whole room dedicated to #gamedev and for talking about this type of technical jargon, and we’d love for you to share your own entries with us there!

If you’ve managed to reach this far, cheers, and thank you for reading! ?