Spenny

[DevLog] Monumental Failure

Recommended Posts

Hey, if you are a regular around here there's a chance you played my Winter Wizard Jam entry Shtone Hemge. [Webpage | Itchio | Wiz Jam Thread]


tumblr_nzv7akxIWN1tybik8o1_1280.gif

 

Shtone Hemge is a comedy physics game where you help a group of druids construct a monument. Project Stonehenge will encompass taking the ideas of the the Shtone Hemge prototype and expanding them to full game, chocked full of content, and sold on Steam. 

 

The druids and Stonehenge will still be there, but there are so many more monuments to construct! Help Egyptians build a pyramid. Help Romans build the Colosseum. Help ____ build _____. You get it?

 

 

Why Project Stonehenge?

 

Shtone Hemge got some good feedback. Members of the community here seemed to enjoy what the prototype contained. It was blogged by FreeIndieGa.me. At Christmas, my girlfriend's father played through it about ten times before figuring out he couldn't get his score much better. I know that's a fairly small body of feedback, and maybe it's tough to be convinced that it constitutes enough of a foundation to base a commercial project off of. But, in my head, Shtone Hemge was meant to be so much more.

 

When I was conceptualizing the prototype I had lofty ideas of multiplayer features, I really wanted to make a game you and a friend could play together, and laugh together while playing. This means split screen. This means pass-the-controller hot seat. This could even mean co-op or head to head modes. I wanted a game that had a tight scoring system, that would convince you to show off your score and mastery. I wanted a game full of surprises you couldn't help but tell your friend to check out. 

I have experience making comedy physics games. I have a lot of experience playing the couch friendly multiplayer games. Games like Starwhal, Mount Your Friends, and Gangbeasts. I can definitely take a stab at making something that captures the comedic value of game physics.

 

 

What are the Next Steps?

 

Greenlight is the first major hurdle. I figure to do this, I want to polish up the content found in the prototype build, to have a demo that can help convince people to vote. This means a new UI (see the gif below) and a split screen mode. 

 

post-33952-0-62637500-1462243730.gif

 

 

What Happens Beyond That?

 

There's a lot I want to do with respect to how the game is displayed. Pull the stone arches in to a circle. Have the camera circle and give you a final look at your amazing monument.

 

As a goal, I'd like ten scenarios to be in the game at launch, 10 different monuments in other words.

 

I want to make the scoring system work a bit different, or at least a bit more transparently. I think having a three star system for each scenario would make the game much more engaging as a single player game. Also, infer from that, the scenarios will probably be unlocked in some sequence, again, to engage a solo player.

 

Further down the road, more monuments, more modes, mutators to diversify the fun, it's open ended.

 

 

Can You Help Me Out?

 

There are 2 problems I'm struggling with.

 

First, if you played Shtone Hemge, you will remember you are judged by a pantheon of gods, including Sanic Hegehog, John Cena, and forum members Dibs and Lu. Fun times for the jam, starts to make less sense if you see that on Steam (sorry Dibs, sorry Lu). What do I replace it with? Real gods? If Apollo and Hercules are judging you build the Parthenon, is that cool? What about some Dank memes, Business Cat and Rage Face judge your constructions? A mix of the two, a Rage Faced Apollo? I'm leaning on the 1st option, but I'd be happy to hear thoughts.

 

Second. Game name. You're building monuments, and frequently failing to do so. The name I've been kicking in my head is Monumental Failure. Punny and old memes. I'm not sure if that's good or bad. Thoughts?

 

 

 

I'm really excited to give a go at making my own commercial project. You'll be hearing more about Project Stonehenge soon.

Share this post


Link to post
Share on other sites

I don't have much to offer on the whole, but Monumental Failure seems really good, I'd stick with that at least for now.

 

As for pantheons, either go 100% serious (Apollo, etc) and rip on the serious God / Goddess attitude vs. the uselessness of their mortal peons, or just 100% zany nutcase pantheon. Don't mix it up, leverage the contrast or run with the theme.

Share this post


Link to post
Share on other sites

Help _dibs_ build _his self esteem back_.

Share this post


Link to post
Share on other sites

As far as comedy physics games, I think you should play or take a look at Poly Bridge, Besieged, Kerbal and Home Improvisation.

 

It might be difficult to come up with something that has real substance as a comedy piece, AND a challenging and interesting building game.

Surgeon Simulator doesn't last very long, for example, but Kerbal is funny at first because it's actually SUCH a deep system.

 

Try to find a strong usable identity now, in pre-production  :tup:

Share this post


Link to post
Share on other sites

I don't have much to offer on the whole, but Monumental Failure seems really good, I'd stick with that at least for now.

 

As for pantheons, either go 100% serious (Apollo, etc) and rip on the serious God / Goddess attitude vs. the uselessness of their mortal peons, or just 100% zany nutcase pantheon. Don't mix it up, leverage the contrast or run with the theme.

 

Thanks for replying. I was already leaning that direction, I just needed somebody to sound it off of. Cheers!

 

As far as comedy physics games, I think you should play or take a look at Poly Bridge, Besieged, Kerbal and Home Improvisation.

 

It might be difficult to come up with something that has real substance as a comedy piece, AND a challenging and interesting building game.

Surgeon Simulator doesn't last very long, for example, but Kerbal is funny at first because it's actually SUCH a deep system.

 

Try to find a strong usable identity now, in pre-production  :tup:

 

It would be a misunderstanding to interpret this as a game about building, in Project Stonehenge building something really just implies an end goal for the player, and the shenanigans in the middle prove to be the interesting part. Where I think Surgeon Simulator is about an unwieldy control scheme, and Kerbal is about building things, Project Stonehenge will be about moving things. In the prototype you move druids who in turn move a stone. It's bare, it's accessible, the level design is the interesting bit. I have a feeling a future devlog will describe the doctrine of design that presently sits in my head.

 

Thanks for the feedback!

Share this post


Link to post
Share on other sites

Well this is good news. I only discovered Shtone Hemge recently when I checked out last Wizard Jam's entries, and enjoyed it enough to play through twice. Looking forward to the new version, and yeah Monumental Failure is a great title. :)

Share this post


Link to post
Share on other sites
It's been a while since I've updated what is happening with this game, now, officially called Monumental Failure (thanks to those who said they liked the name). This period of quiet was not due to inactivity, quite the opposite. We have been busy preparing Monumental Failures branding, demo, and Greenlight campaign.

 

The "We" there is important too. My girlfriend Jess has signed on to take an active role in the development of the game.  Together, we've branded ourselves Scary Wizard Games, follow us on Twitter.

 

G3Uzp6o.png

 

Monumental Failure as a name I had conceived of quite a while ago. Most people I mentioned it to found the pun to be clever enough. Developing a logo, we wanted to focus on blocky, ancient, stone carved fonts. 'Monumental Failure" is a massive amount of text to fit into something sleek. Instead, we went for a stack of blocks, evoking the monuments the game will focus on. The broken column ads some pictographic imagery, turning a text treatment into something uniquely ours.

 

ZFDsUBB.png

 

Because Shtone Hemge had already been released as a thing, I figured I needed to post an updated, on brand revision of the demo. What should have been a simple revision turned into three weeks of work, as I completely replaced the UI and added split screen multiplayer. In an unsatisfying way, the experience of the game the player receives is pretty much identical to the game jam version. Behind the scenes though are some huge improvements which will help me hugely going forward. Grab that demo here.

 

Finally, ho-lee-sheeeeet, GREENLIGHT! This feels like the first real test of the game. Not much to say, just please go vote!

 

We're really excited to have announced about what we're working on. More updates soon!

Share this post


Link to post
Share on other sites

I mentioned this in Slack, so I'll put it here as well. I was given an opportunity to make working on this game my full time gig for the next few months, meaning I quit the job I'd been at the last 4 years. A huge privilege to say the least, but also a huge "put your money where your mouth is" situation. I couldn't sleep knowing we would be launching the Greenlight campaign this morning. I'm certainly planning on sharing our Greenlight results, just like Dinosaurssssss did. My fingers are crossed!

Share this post


Link to post
Share on other sites

Aaah this is rad! I love your company mascot and the game logo looks great!

Share this post


Link to post
Share on other sites

Oh man oh man this is really happening and it's awesome! :D

 

Kudos on taking the big scary leap into full time indie dev.  :tup:

Share this post


Link to post
Share on other sites

Thanks for the kind words everyone. Also, thanks for retweeting, sharing, and what not. Our greenlight has been going quite well so far, I would be quite surprised if we are not actually greenlit. Thanks for voting!

Share this post


Link to post
Share on other sites

A picture is worth a thousand words, so here's some screenshots of today's good news.

 

post-33952-0-21466500-1468375169_thumb.png

post-33952-0-91745100-1468375169_thumb.png

post-33952-0-50688200-1468375170_thumb.png

post-33952-0-89755900-1468375170_thumb.png

 

A shout of Woohoo! And a sigh of relief. Steam is such a make or break for indie games. Not getting greenlit would have spelled out an early death for this project. You can see from the screenshots that the overwhelming majority of traffic came within the first 48 hours. Here's where our analytics said our traffic came from.

 

post-33952-0-25498500-1468375663_thumb.png

 

I have to assume most of the traffic came from regular steam users browsing greenlight. I set the campaign live around 10 am EST. Evening for Europeans, start of the day for the Americas. We stayed on the first page of Greenlight for about 24 hours. I think having a gif that quite explicitly shows gameplay was a good idea to pull people in to the page, but, this is hardly a scientific conclusion. About 75% of the comments on the Greenlight page were positive. Great to see that support this early.

 

Very happy to share this good news with you all, thanks for sharing and promoting the campaign, and most importantly, THANKS FOR VOTING!

 

 

Share this post


Link to post
Share on other sites

We're making an effort to write more dev logs. I'll x-post them here, but they will all appear on the official site. This week

 

ITERATION & POLISH aka THE LIGHTING WORKS NOW

 

I told a friend earlier this week that there's a lot of naivety regarding how much work on a game is polish and iteration. Later this week, I found myself stressed by the fact that instead of pushing forward and designing new levels, I was instead re-doing the system for loading levels.

 
mfscreenshot-0029.png?609
I'm sure this looks like just another Stonehenge screenshot, but what it represents is a level loader that doesn't break lighting!
 
As you may or may not know, Monumental Failure started as a game jam game. I had always wanted to include a split-screen multiplayer option, but game jam time constraints meant that didn't happen. For our Greenlight campaign, I knew the game jam version had to be fixed up, with prettier menus, non-meme-y gods, and most importantly (to me anyways) - split-screen! I devised a level-editing system that let each level have a scene it was designed in, a script to write all the designs to prefabs, and a main scene to load those prefabs, and had it repeat the loading for the number of players. It worked well, except for the lighting. It was subtle, but the loaded prefabs were always just a bit darker than they were in the design scenes.
 
To be honest, I don't know enough about Unity's lighting system to tell you why this is. I can tell you how I fixed it though.
 
Levels now consist of two scenes. The first, contains the lighting info and a directional light. Lightmap baking has to have its "auto" mode turned off. The second contains the "content", the actual designed game stuff. To load the level I first load the lighting, then additively load the content for each player, merging it in to the lighting scene. I can use the "Scene" object to grab all the root GameObjects in the scene and move their position so that players aren't playing on overlapping levels.
 
In the end, I am essentially throwing out about half the work I had done when making the original level loader. This sucks, but it's part of the process, and I can live with it. More importantly, it's better now. The levels load smoother and faster. 
 
Two steps forward and one step back. Iteration can feel bad, especially when it means scrapping hard work I've already done. At the end of the day, I have to accept it as part of the process, and focus not on what is lost, but what is gained. At least, that's what I'm telling myself :-P
 
​-Spencer

Share this post


Link to post
Share on other sites

We've been maintaining a devlog on MonumentalFailure.com.

 

Last week, I wrote about some Unity plug-ins I've been using.

 

This week, I wrote about designing for accessibility, and how my Dad is helping me test the game. I'll put that text here as well:
 

I have the belief that for Monumental Failure to be a success, the ability to share it with friends and family is a key factor. To clarify, I know that Monumental Failure isn't going to be the game that occupies hundreds of your gaming hours, but I want it to be a game you're going to show your brother, your sister, or even your grandma. I want Monumental Failure to bring people together to have a laugh, and enjoy a moment of comical frustration with whacky fun video game physics​™.

To achieve this level of share-ability, the game has to be accessible. If someone has never played a game before, will they be able to play Monumental Failure? What barriers does someone have to overcome to play it?
 
In this week's dev log, I'd like to share some thoughts related to how I'm answering the above questions and making Monumental Failure more accessible.
 
screeshotsaturdayfacebooksept3-2.png?628
 
The first thing I ever designed for Monumental Failure consisted of 4 capsules that pushed a 3D rectangle up a ramp on to two other 3D rectangles. To give the player a degree of control fidelity, it made sense to assign pairs of capsules to separate joysticks, left capsules on the left stick, right capsules on the right stick. I needed to allow the player to end the round, so a button press, 'A' , fit this need. Move your "guys" with the sticks, lock it in with a button.
 
​In developing the Monumental Failure proto-game I found myself with an extremely simple control scheme. I decided it would make for a more interesting game if these controls never changed and every challenge was prescribed by the level design. This has the benefit of only needing to tutorialize the controls once, which combined with simple controls gives a huge boost in accessibility.
 shtonehemge-gif-01_orig.gif
The very first gif of Monumental Failure
 
Assigning all the joysticks to character movement eliminates the right stick's typical function - camera control. Asking the player to be a camera operator could be a huge barrier to play, so we remove camera controls from the player's responsibilities, and instead make it a responsibility of the designer. This definitely creates some headaches for the designer, but it's a huge gain in accessibility. 
 
Additionally, as a concern for accessibility, I have to take a macro look at the game, and ask, is it friendly? Goofy situations and a general comedic tone help, but, is it fun to fail? Can you enjoy yourself even if you're not winning? 
 
I sum up all these questions and concerns into a simple mantra for myself: "Can my dad play this?". My dad doesn't play video games, but he has a sense of adventure and embraces new experiences. He has the right attitude and the perfect lack of video game knowledge to make him an ideal tester for Monumental Failure!
dadpho.jpg?602
Dad tries pho for the first time.
 
It just so happens that Dad stopped by this week, and we got him to play through the Stonehenge and Roman Aqueduct levels. He navigated both levels with competency. Surprisingly, his biggest challenge was figuring out how to press start on the game's title screen. I guess I have to make that more accessible!
 
I hope in the future if you hear me talk about accessibility as an element of game design, this post will enlighten you as to what I mean by that.
 
Thanks for reading!
Spencer

 

Share this post


Link to post
Share on other sites

On a bit more of a personable note, we've had our first push back on release date. Originally we had a very lofty goal mid October, giving us room to miss. We've shifted our "version 1 complete" goal to mid November, then we just need to figure out a release date that isn't going to be trampled by a notable AAA release. 

 

In general, I'm feeling better with this plan. It's going to give me the time I need to design the game, and a bunch more to do bug fixes and optimizations. I have 3 new levels designed, and the speed in which I can do that has basically reached its maximum.

 

Recently I completed implementing almost all the games UI, options menu being the big TODO still on the list. This feels great. I have all the navigational conveniences you would expect from a game, and in my testing I'm feeling better about playing the game. There's still polish to be done, and some additional features might create more UI, but it was a moment of contentment for me.

Share this post


Link to post
Share on other sites

This week's devlog: How the camera works.

 

In the last dev log, I mentioned that Monumental Failure's camera would be controlled by the game, not the player. In this post, I'd like to take some time to discuss lessons I've learned working on game cameras.
 
Before working on Monumental Failure, I had experience working on 2D game cameras, specifically with the games Battle Run and Super Battle Racers. In those games, the camera uses a few simple rules. The camera tracks the player character. If the character is within bounds, the camera asks the level where best to situate the camera. If the character is not within the bounds, the camera does its best to follow the character anyways. Though the actual implementation of this system would be represented by hundreds of lines of code and hundreds of points of information specified by the level designer, the key idea here is that 2D cameras are best left to the designer. 
 
​As a side note, Mushroom 11 creator Itay Keren, in his massive treatise on 2D game cameras, essentially comes to the same solution.
 
camerablog_orig.gif
Super Battle Racers
 
The question then is does a similar, level-design driven approach make sense for Monumental Failure, a 3D game? The simple answer is no. Battle Run and Super Battle Racers are concerned with tracking a single character who moves in 2D screen space along a level that is almost one dimensional i.e. you can move left and right, with little variance in up and down. The level designer need only provide a list of points that the camera then interpolates between. In Monumental Failure, I have a variable number of things to track - a piece of a monument, and the characters that are pushing it - all of which move in three dimensions of space. Trying to populate the levels with three dimensions of camera direction would be a nightmare. Instead, I need more general solutions, and need to be much more selective of the camera controls which I expose to the level designer. 
The first rule I impart to the camera is to find a relative forward/backward (depth) axis. I define this as the axis made from the target position to the pushed stone's position, removing any vertical change. The camera uses this depth axis and is placed at a distance behind the stone's position, as well as an angle up from the stone's position. The distance and angle are defined by the level designer. The camera attempts to maintain the angle and distance from the stone as the stone moves. With a little bit of smoothing, this method is very good for keeping track of the stone, but I need to do a little more to make sure you can see your push-people.
 
To assure the push-people are seen by the camera, I call a function that returns their individual screen positions. If the function returns a number between 0 and 1, they're on-screen. If anybody is off-screen, I increase the distance that the camera is away from the stone until the characters are back on screen. To make this camera rule more graceful, two changes are needed. Instead of checking a range of 0 to 1, we instead want to check something more akin to 0.1 to 0.9, so if an object is maybe going to be off-screen, we are getting ahead of it and pulling the camera back preemptively. Secondly, the speed at which I pull the camera back needs to be able to accelerate in the case that something got off screen fast. 
 
camerablog2_orig.gif
All together it looks something like this.
 
When the player approaches the target for their pushed stone, the level designer has the option of rotating the camera to give the player a better sense of how lined up their object is. This camera feature was implemented very early in the game's development, and my play-testing has me questioning whether this is a helper or a hindrance to the player. Level designer Spencer says, "it depends."

camerablog3_orig.gif
 
When I write it out, the rules for the camera may sound simple. The reality is that it's a living system that needs new features and tweaks as the level design informs them. Just this week, I needed a function that would allow me to provide an additional amount of positioning to better highlight action down-screen from the stone and people. 
 
camerablog4_orig.gif
The action is behind you!
 
Despite my previously stated concerns that handling camera controls on the developer's side would be a headache, it's actually been a satisfying challenge. I make it easier by providing relatively few handles to tweak it on the level design side. 
 
​While I'm sure there are still challenges to come and changes to make, the current camera is actually pretty great.
 
Cheers,
​Spencer

 

Share this post


Link to post
Share on other sites

In your quest to make controls simple for the player and not have them have to deal with camera positioning, have you considered having a hybrid model where those who want camera control can turn it on in an option menu, or hit a button to take over the camera?

Share this post


Link to post
Share on other sites

In your quest to make controls simple for the player and not have them have to deal with camera positioning, have you considered having a hybrid model where those who want camera control can turn it on in an option menu, or hit a button to take over the camera?

Yeah, totally had to consider that when making this decision. I think you end up trying to decide between two design philosophies. The one, which is emblematic of PC games, is the expose everything philosophy. Sure some of it is a bit hard to access, but if a player wants, they can get in there and customize the game to their liking. The other philosophy, reflected more by console games, and especially mobile games, is to really only provide one experience. No you're not going to please everybody, but you do your best, and the experience is consistent. I wouldn't argue either of these is better, just have to decide what fits best with the game. To me, having a deeper camera system, accessible to the players who really want it, is antithetical my aforementioned thoughts on accessible design. I want Monumental Failure to be very "what you see is what you get".

In this weeks devlog I write out some thoughts after having seen a post mortem for the game Valley. Read it here.

Share this post


Link to post
Share on other sites

I'm pretty happy with the latest devlog. Getting in the character customization is really starting to make this feel legit, more whole, nearing complete. Copied here:

 

The design of Monumental Failure is hugely influenced by the design philosophies of local multiplayer games. That doesn't mean it's exclusively multiplayer, you can play it solo, no problemo! But, let's say you have some friends over, maybe you'll have more fun if you split the screen and fail together!

 
Anyways, one of the design ideas we are appropriating is character customization. In a multiplayer game, getting the player to customize and familiarize themselves with their characters imbues an immediate connection with their characters. This is especially helpful to combat the "I was looking at the wrong character/screen" problem people often experience with local multiplayer games.
 
mfscreenshot-0088_orig.png
 
When I started working on implementing character customization I wasn't sure how I would introduce the user interface required to allow the player to set their customization. I started with examining what the player could be customizing.
 
We have 4 different character bodies, and while it would be possible to let the player pick which one to use, I use the different body types to help clarify gameplay elements within the levels. This means the player won't choose body type and will instead be customizing the whole "team" of characters.
 
The characters have three attributes that can be swapped around, their skin color, their clothes color, and their hat. It felt important to us that the characters' skin colour stay relevant to the culture they are representing. That leaves us with just the hat and clothes colour to customize.
 
mfscreenshot-0095_1_orig.png
 
Conventional wisdom would suggest that character customization happens right around the time a player "presses START to join". This doesn't really make sense for Monumental Failure. Loading four characters in to a menu would make for a pretty crowded user interface. Additionally, not knowing your characters skin tone until you load a level would provide ambiguity to the characters finalized look. Not ideal for would-be fashionistas. 
 
This implies that character customization should happen after the level has been chosen, and if the screenshots haven't made it obvious, that's exactly what I did! 
 
This provided the additional benefit of having a pleasant character vignette to introduce each level, and even better, introduced a "Ready Up" feature. When the level loads, you have to press a button to start instead of being thrust immediately in to the gameplay. Honestly, that sounds like something I should have introduced a while ago :-P
 
mfscreenshot-0093_orig.png
 
I always find it to be a rewarding experience when the solution to a design problem is arrived on by this kind of deduction. Using design constraints and philosophies brought me to a unique solution for Monumental Failure's customization problem. A solution with benefits greater than the problem it solves.
 
Thanks for reading,
​Spencer

 

Share this post


Link to post
Share on other sites

Another week, another devlog. Originally appeared here.

 

Quote

The Levels are Done!

 

Last night Monumental Failure passed a significant milestone -- all the levels that will be included in the initial release are now done! Well, sort of... I still have several passes of game play and graphical polish to do, but none the less, we're getting there! Today I'm going to discuss some ideas that initially didn't work, and the solutions I found to make those bad ideas good.
 pario-marty-2-shockdroproll_orig.png
I was inspired by the design from this Mario Party 2 mini-game to challenge the player to stay on top of a cylinder. The constant shuffle and adjustment left and right should be an interesting challenge. Well, unfortunately for our physics driven game, once you started to tip a little bit, it wasn't long before you tipped a lot. Loss was too sudden. The solution? Conveyor belts, alternating between pushing you left and right meant you had to readjust, and if you got pushed all the way off, well, you probably saw it coming.
 struggle02_orig.gif
Much better :D
I had designed this crazy crane vehicle to be used in the Bayon Temple level, and for a long time it was one of the most confusing and glitchiest aspects of the game. At the start, the characters were physics objects standing within the vehicle. While it seems like physics objects would be in the spirit with the rest of the game, the result was that your character couldn't consistently press the buttons to make the vehicle go, and worse, they could get bounced right out of the vehicle. Oops! The solution was to simply make the characters part of the vehicle, rather than making them physics objects.
 screenshotsaturdayfb-sep-24_orig.jpg
When building the pyramid, you will have to traverse some crumbly stone columns that tip over, that ultimately help you get to your destination. The initial prototype used some green cylinders to represent these tipping platforms. When Jess tested them out, she didn't realise they were tipping and attempted to hop from one to another, and it didn't work and she was frustrated by it. The solution here was to better visualise that something was happening. Green cylinders got replaced with craggy, wiggling rocks. Particle systems create dust when the tipping starts. Crumbling sounds play, ending with a good thud when the tipping is done. The behaviour was then obvious.
 tips5_orig.gif
Those are just a few of the tweaks I've made up till now, and like I mentioned above, there's bound to be a few more. Given that the level design is inherently antagonistic to the player, it's important that the challenge is clearly communicated, and that failure clearly feels like a fault of the player. Simply put, I need to create a fair game.

Thanks for reading,
Spencer

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now