We have great news for fans of Monumental Failure. Today we're rolling out a feature update which includes support for up to 10 controllers! Our new Team Versus mode allows competition between 2 to 4 teams, each team consisting of 2 to 4 players. Essentially, this feature is a combination of the existing cooperative mode and split-screen versus mode, Team Versus mode is competitive cooperative. Confused? Well, if you are set up for 4 players, you can jump in to Team Versus mode and play 2 versus 2, try it now!

Another feature we've included is Practice mode. Once you've scored 1 Star in a world, you unlock the option for practice. Practice mode will let you instantly jump to a level within a world. Perfect for mastering levels and figuring out how to get that elusive 3 Star score.

There's a thought among game developers that when you are scheduling out your game, you figure out how long everything is going to take, add up the time, then double it. It's a sentiment that is simultaneously joke and wisdom, but it does raise the question, why are we so bad at predicting how long our work will take? I've been giving this a decent amount of thought lately. I've had to take on the task of scheduling myself, and, consequently failing to meet those schedules, why am I so bad?

This chess image kept coming up when I was searching for "schedule" on free stock image sites.

When we start scheduling ourselves out, we probably think that tasks fall into two broad categories, things we know how to do, and things we don't know how to do.

As developers, we are good at estimating the time it takes to do work we know how to do. You sometimes hear devs refer to this kind of work as "plumbing", it's skilled, but procedural work.

Tasks we don't know how to do are work we relish. These tasks mean we get to learn something new! These tasks are harder to estimate, obviously, if you don't know how to complete them, how do you know how long it will take? However, I found my estimates worked out in balance. For everything that you learn that is hard to do, and consequently takes longer than you guessed, there are three things that are easier than you thought, thus quicker to do. Great!

​So where does that double extra time come from?

The way I see it, the problem is caused by a third category of tasks, the things we didn't know we had to do. As your working through a game, you discover new things your game needs.

These could be gaps between mechanics or features, intersections between mechanics that aren't quite working. The space where I ended up implementing character customization was found through a gap in our loading mechanics. I'm so happy with how that feature turned out, providing us an introductory scene for each world, and a "Get Ready" mechanic previously not in the game.

Other times, you discover potential small tasks that return big value. Monumental Failure's co-op mode was an example of this. Co-op took about a week to implement and ended up being the most popular way to play the game. A week of work I didn't schedule, but a week well spent.

This process of discovering things about your game leads to a better game, but how do we schedule it?

If there is anything to take away from this post I want it to be these two things:

1: Schedule a lot of unscheduled time. Both to let you catch up, and give you the space to discover new features for your game.

2: Re-schedule constantly. If you get behind, or you find a new feature to implement, don't try and adhere to your old schedule, figure out a new one. Re-prioritize your tasks and adapt the project as you go.

What do you think? Should designs be more thorough, flushed out, and discovering features is my lack of inexperience? Are there factors I have missed? Better scheduling strategies? Let me know!

I thought I would take a moment this week and highlight some games that I think are outstanding in the field of comedic video games. Here's my 3 favourite comedy games:

Little Inferno

Little Inferno follows a pretty simple premise, you buy stuff and burn it, burning it gives you money, which then let's you but more stuff to burn. The game ensures that the act of burning is satisfying. Coupled with clever writing and good pacing, the game is a great satire, and well worth a play through.

Drawful

Drawful is one of several fantastic party games from Jackbox Games. Drawful takes the draw and guess mechanics of Pictionary and pairs them with the deceit mechanics familiar to other Jackbox games. What I love, is where bad drawings and bad guesses make for painful moments in Pictionary, Drawful's design instead turns them in to the funniest moments. Near endless fun.

Octodad

Octodad is an incredible achievement for comedy games. It is dense with content. It starts with a goofy premise, a dad who is secretly an octopus. It has funny mechanics, challenging you to control physics simulated tentacles. As you're wrestling with these mechanics, you have a family sitcom playing out around you. Your kids and wife interacting with the world, having family fun, oblivious to the mess you're making. The game is fully fleshed out, unbelievable how much content and care is in it. A spectacular piece of media.

As we move into Monumental Failure's post-release life, Jess and I talked a lot about what sort of updates we wanted to do for the game. Our first update was a big boost in content, The Great Wall. For our upcoming update, instead of content, we are shifting to adding some new features. Today, I want to discuss how our content and play-testing has informed Monumental Failure's existing and upcoming features.

Monumental Failure's content, its worlds and levels, are relatively static, unchanging. Playing a level is the same challenge each time. This is important to understand as we look at deciding on the game's feature set. That brings me to the title of this post. It probably seems odd to compare a game's features with standing in a river and looking for little pieces of gold, but, throughout the stream of development, I have been looking for feature nuggets, small amounts of coding and UI work that will pay huge value.

Sorry for using such a tortured metaphor, but, here's the gist of it. With a static set of content I had to be constantly on the lookout for ways I can make that content multifaceted. Take the static content and through simple features, amplify its worth. Let's give a few examples.

When I started working on Monumental Failure, I had no intentions of having a co-op feature. Co-op feature was inspired by some coworkers, who when play-testing an early demo, opted to each take half the keyboard and share the single player experience. The co-op feature represented about a week's worth of work to add to the game. It ended up being our favourite game mode and the mode we leaned on when marketing the game. Talk about a gold nugget!

​Hats! We knew it would be important for players to be able to form a connection with their in game characters, so a simple customization system was the solution to this. The value to be discovered was that having hats gave us something players could unlock, something higher scores could award. Welcome to value town.

Practice mode is a feature that will be coming in a future update. Practice mode allows you to instantly play, and re-play any level in the game. Practice mode was something I wanted in the game from the start, but had to push it to the side as being concerned about being able to reset the level was a burden I couldn't afford to work with. Fast-forward 8 months, the game is released, and I have a simple solution to the problem that involves cloning the levels. Practice mode was implemented in about 4 days work, most of which was UI and testing. Another nugg!

I think it's great when a game informs its own design, and by that property I think it's important for us as developers to be on the lookout for these self informed designs. Especially when it means a little work can have big payoffs.

Finally a tease. Can you spot the nugget? In Monumental Failure we have the ability to let 4 players play in the same world. We also have the ability to have 4 players each play in their own world. Hmmmmmm. Hmmmmmmmmmmmmm.

It's GDC this week and I'm reminded of one of the best pieces of wisdom I've received from a GDC talk. In a talk about balancing Halo 3's multiplayer, designer Jaime Griesemer list 3 types of feedback your game can receive.

The whole talk is worth a watch, full of nuggets of knowledge, but there's something about this feedback breakdown that has really stuck with me. My work this week has involved implementing a new feature based on a common thread of feedback I've received from multiple sources. I'm not going to talk about what that feature is, instead I want to talk about a particular level that has been a real wedge in player experience.

Stonehenge's third level looks like a copy of Stonehenge's first level. Nothing but a simple ramp to push the stone up and the two posts on which it can rest. However, there is a difference. In level 3, as you are about to slide the stone off the ramp and onto the posts, something happens. The stone stops. Pushing is no longer effective.

​WTF! BROKEN GAME!

Look at this broken game!

The ramp is too short. But this doesn't mean you can't succeed.

Success just requires a bit more work,

I'll admit it, the fact "the ramp is too short", isn't perfectly communicated to the player. People have told me that this level is broken, a bug I must have missed. Other players push the stone as far as it will go, and when it stops they assume that was all the game wanted them to do. They are promptly corrected when they receive a low score.

So why leave this level in the game? Why not replace it with a clearer challenge?

I use this level to buy myself forgiveness in later levels. I want to trick and deceive the player, show them that this game isn't a perfectly polished straight-shootin' sequence of obvious challenges. Instead, here, they are shown that there is need for some finesse with the physics engine to achieve a perfect score. I show them that this game might be a bit janky at times. Most importantly, I do it with a joke. When the stone stops at the top of the ramp, your assumptions have been subverted, punchline delivered!

Greetings! As you may have heard we recently pushed out an update featuring a new world, a new monument to build, non other than The Great Wall of China. This is our first world update since the release of Monumental Failure. From a development standpoint, this makes it the first world that wasn't developed simultaneously with other game features. The creation of the great wall was a start to finish process, and creating it has been my sole focus for the last month.

I'm going to take this opportunity to talk about this process. and give you a peek into how a world in Monumental Failure is composed.

Let me show you how we go from the top to the bottom.

Before we hop into Unity and get game making, we start by collecting images for our art reference and do some designing of the world on paper. I have notebook pages and sticky notes with ideas for different levels, I try and select several that I think would feel good and write out a general plan for what the world's ten levels should feature. Meanwhile we use Pinterest to gather our references for the world's aesthetic features.

Pinterest is an underrated tool for this task.

With an idea of what we want the world to look like, and what we might want the levels to be, it's time to head into Unity.

I had decided that I wanted the Great Wall to ascend up a mountain as the levels progressed. I started by creating an approximation of the final mountain using Unity's terrain tool. One of the brushes allows you to change the terrain to a fixed height. I created a "mountain" that was a staircase of plateaus each one 5 - 10 units higher than the previous. I then used ProBuilder to model a prototype for the guard towers, both the target base and the pushed piece. I placed 10 of these prototypes on the mountain steps I had created and then used ProBuilder to "build" walls connecting the guard towers.

I grabbed this screenshot from within the editor today, but it's a close approximation to what we have at this step in the process.

I use a plug-in to export these prototypes so that Jess can import them into her 3D modeling program and start creating a detailed model of the monument.

Meanwhile I get to prototyping the gameplay features for each level. I generally am able to use Unity's simple prototype objects to get this done, occasionally I will need to model something with ProBuilder. When I implement mechanics, I am actually able to reuse and iterate on levels from worlds before. For example, in the Great Wall you get to drive a vehicle very similar to the one from the Bayon Temple, but this time you also get to control the movement of the crane component. I copied the vehicle over, made it wider to allow more controls, and changed the crane to a controllable fork. Simple reuse.

I've received detailed 3D monument models from Jess. The vehicle is "recycled" from a previous world. I have laid out a challenging obstacle course the player will navigate around.

Once all the levels are prototyped, Jess and I do a playthrough together and try to figure out how we are going to go from prototype boxes to good looking levels. For the bigger stuff we tend towards modular props. Scaffolds made of bamboo and logs are easy to mix and scale allowing me to conform them to my prototypes. Other props require more individual models, like the spike ball mobiles in the Great Wall.

Modular scaffolds.

Bespoke spike ball mobiles.

The playthrough process also reveals elements which require more polishing. As Jess makes the props, I will be working on adding sounds, particle systems, and any number of other elements to provide additional feedback to the player.

With the levels figured out I can next attempt to set up the environment. Knowing where the "level stuff" is, the process starts with sculpting and painting the terrain.

The terrain here was looking a little empty, so i created a second terrain to act as some distant mountains.

The Great Wall introduced a unique problem in that the scale of the environment meant we needed bigger trees in distant spaces. This lead to a lot more work as I couldn't rely on Unity's auto tree placement.

Our final step is getting out colours good. When we started working on the Great Wall we had designed with a pretty generic, green trees, green grass on brown mountains colour.

By keeping our materials specific to the world, we can easily change colours around. Trees, sky, and terrain are all easily editable in Unity. Jess also does the lighting for the world. Most of the time we only use a single directional light (the sun) and the global illumination, usually using the gradient option to get a bit more dynamic lighting.

Finally we use Amplify Color to color correct the whole scene. With the great wall we specifically wanted to draw attention to the reds in the terrain and trees, and contrast that against the grayer colours of the mist and scaffolds.

I think the result is quite striking!

That's the gist of how a level comes together. I've certainly neglected a few steps: making the little vignette where you customize your team, animating the gods, making sure the hats look good, images for menus... there's a dozen little things that need to get done. Even more, while the process for designing each level is pretty much the same, all 10 levels are unique creations. Not only does each one have a set of mechanics and props, each one needs to consider camera work and scoring mechanisms. It adds work time, but it is pretty necessary for achieving the level of quality we have.

That said, I feel like we really have established a process for world creation and hopefully that means more world updates in the future. For now, go enjoy constructing The Great Wall!

Greetings! Monumental Failure v1.1.0 is our first world update. There is now a 7th unlockable monument to build. World number 7 features 10 new levels that challenge you to construct The Great Wall of China. Not only is the Great Wall a huge addition of content to the game, but it's also our hugest monument yet! You'll feel a difference in the size of this monument. The levels and environment are all bigger. At times you'll even be asked to control 8 characters at once. Good luck!

We're really excited to get this new world out to our players. Thank you all for your support on our game. We sincerely hope you enjoy constructing The Great Wall. Cheers and have fun!

Monumental Failure utilises a low poly aesthetic, a look that has risen in popularity over the last few years. I wanted to take some time and collect my thoughts on employing this art style. It would be nice if I could organise this as a discreet list of pros and cons, but in the process of collecting my thoughts, I've realised that the work of employing the aesthetic is not broken down that simply. There's a lot of grey area, there are a lot of small decisions along the way that informed the final look. So, instead, I'll be writing about these decisions, and you'll infer the pros and cons from it. Sound good? Well, anyways, I'm probably a bit ahead of myself! First I should define what I mean by low-poly aesthetic.

By RedPanda_UA

Low poly can be literally understood as low polygon count. When I say low-poly, I mean models where the geometry is obvious. This is consistent through the world. We have hard edges. Light hits the models' faces at one angle only, creating big blocks of colour. No textures. When you see a rock, a brick, or a log, you know an artist spent the time modelling it and placing it. That's it, that's our starting point. With that in mind, let's get going!

By onewheelstudio

The first thing I want to point out is definitely a pro, and was a huge boon in developing Monumental Failure in the time we did. Simply said, there are tonnes of freely available assets for low poly environments. A quick search through the asset store will reveal plenty of low poly models ready for you to drop in your game. If you find models that aren't low poly, It's pretty easy to edit objects to look low poly, otherwise the plug-in Polyworld has a utility to do it for you. Saving time on producing assets, especially generic stuff like rocks and trees is such a huge plus. The only stumbling point here is ensuring that these free models are cohesive with the rest of your aesthetic.

Speaking of sticking to aesthetic, one of the questions you'll have ask is what do low-poly effects look like? Things like fire, dust, smoke, or water, what are their low poly versions? A strict approach, i.e. producing something that has the obvious geometry like we described above, would have required a wealth of additional time and knowledge. Custom mesh based particle systems for fire, custom shaders for water, and custom cloud models for smoke, are a few examples of things I would have had to consider. Instead, for Monumental Failure, I decided that people generally wouldn't find a regular looking flame or smoke poof out of place, and trended towards "realistic" looking effects. For water, in the end, I think there are 3 unique takes on water in the game, and each one of those probably took a good 3 attempts before I settled on something I liked. It's not trivial!

You can see 2 different waters in this screenshot.

On the theme of natural things, lets talk terrain. A feature of low poly artwork with respect to landscapes is there is typically more geometry in the foreground, less geometry in the background. As your eyes move from rocks to hills to mountains, the amount of polygons that describe each object decreases. The problem we run into, is of course that we're creating a video game, not a static image. We have a moving camera, meaning the area we want rendered in high detail, near the camera, will be changing.

By mosegro

The obvious solution is to have the parts of the world the player will be near be detailed, and keep backgrounds less detailed. This is probably feasible for something like a fist person game, where the spaces the player occupies will be relatively constrained. This is harder top do with a game where the environments are larger and less constrained, or when the camera's zoom frequently changes. Both these issues occurred within Monumental Failure.

I'm beating around the bush; there's a bigger problem. Fully modelling every environment vertex by vertex would be too much work! There's no way I have all the time to custom place an entire environments worth of ground. ​​I need a tool like Unity's terrain engine to easily sculpt and paint terrain. Polyworld is that tool. Polyworld also has the advantage of providing flat surfaces with a low poly "texture", again saving us time modelling terrain.

For me, the Polyworld terrain was definitely an imperfect solution. It looks algorithmic, detracting from the "hand crafted" nature of the low-poly aesthetic. I was able to reverse some of this affect by manually placing rocks and buildings and other details where possible. Additionally, foliage helps distract from the repetitive nature of the Polyworld terrain.

An early Aqueduct screenshot, featuring only Polyworld terrain.

A more finalized look at the Aqueduct, the foliage and the modeled riverbanks flush out the scene.

These before and after screenshots highlight another aspect of achieving the low poly look. Your colour game has to be on point. The colours of the scenes your game renders out have to be cohesive, they should tie everything together. This starts with the colours and textures of all the models in the game. We then had the skyboxes and fog settings to play around with. The lighting was key to pulling this all together. Finally, we throw on some post process color correction to get all the previous work looking just a little bit better. With Monumental Failure, it would be nice to say we had this all figured out from the start, but truly it was an iterative process, adjusting and readjusting until we were happy, or at least complacent. 😛

It's subjective, but to me the colours in this scene are non-cohesive, detracting from the overall look.

The last thing I need to mention are the models our artist Jessica made. I can't specifically speak to all the challenges of modelling in a low poly style, though I'm pretty sure I can say that Jess never wants to model another brick again. I will however, speak to the aesthetic quality of the models themselves.

I think low poly really helps achieve a look of mystery and majesty. It's surprisingly good at communicating material property, those towers are made of stone, you know it! On the organic models it works great too. Trees and grass are trees and grass, no doubt about it. Our human characters too, even with their super low amount of detail convey huge amounts of personality. Jess knocked it out of the park!

That's pretty well the summary of how we got Monumental Failure to look the way it does. Perhaps you're wondering, would I employ this aesthetic in a future project? Short answer: maybe! I think in a game with less camera movement and more constrained environments, you would reap more reward from the aesthetic. The low poly look can save a lot of time and effort realising environments, producing a great looking game to boot. I also think it has potential to be combined with other aesthetics, maybe your environments are low poly but the characters are toon shaded. Ultimately, this experience will help me going forward to inform any other aesthetic choices, and maybe this devlog will help you too.

This will be the fourth installment of a series of posts on tools that helped bring Monumental Failure into existence. If you like this post, make sure to check out parts one, two, and three.

Amplify Color. Amplify Color is a color correction package for Unity. The store page speaks for itself as far as what Amplify Color does and which other games have employed it. I will say, Amplify was invaluable in pushing Monumental Failure across the finish line. It really gave us an extra boost in making the game look finished.

Stylized Water Shader. This shader was instrumental in achieving the water and lava in the "Raft Adventure" levels in Easter Island. Frankly, I don't think we do this shader justice, I definitely had to constrain it to fit with the style of rest of game. It was flexible enough to turn water into lava. Definitely recommend if your game needs water.

Well, that's it for today. Maybe you'll find use for these in your own projects, if you do, let me know!