Last night I attended the monthly Unity User Group meetup here in Toronto (shout outs to Adam for organising and Uken for hosting). This month, a few of the boys from Blue Isle Studio did an informal postmortem of their newly released game Valley.
The presentation was great. The guys demo-ed the game to the room, showed how those scenes were reflected in the Unity editor, and shared great thoughts on design and development. I am now super duper looking forward to biting into Valley this weekend. It's basically got Tribes' skiing. And grapple hooks. And double jumps! And set in Canada. And has cool sprite buddies. And spoopy government facilities. And and and...
When it came time to ask questions, I seized the opportunity for some insight on marketing. The question I asked was, "Was there any one marketing move you made that provided the most return?"
The answer was a simple "no". Instead, they responded that one of their marketing failures was miscommunicating the size of their studio. Valley is a game that looks so good, the fact that it was made by less than 10 people is lost on the audience. The game didn't have a personal touch associated with its promotion. They felt this hurt the game's reception.
While we've tried to create our own branding and marketing for Monumental Failure, neither one of our two-man team here at Scary Wizard Games is a marketing expert. Hopefully we can take some of the lessons learned from Blue Isle Studio and make sure we push our small studio status. Maintaining this dev log has been our attempt so far at making our studio more personable (as are the pictures of our dog on Twitter), but only time will tell if we've succeeded.
Thanks for reading!
💖Your bloggy buddy,
P.S: Don't forget to e-mail us, or hit me up on Twitter. I love talking games, and would love to talk to you! :D
I received a lot of good feedback the last time I wrote about some of the tools we are using to make Monumental Failure. I thought I'd do a cheeky follow up.
ScreenToGif. I've been using ScreenToGif since it was a preview version. The current version has a full featured editor, with options for cropping and watermarking and changing playback speeds and drawing it's simply an amazing free tool. Best of all, it just works! I've never had a problem using it, and when gifs are a better way of communicating your game than static screenshots, it's pretty key for the indie developer.
Neil Cicierega's Work Thingy. Yeah, so, the guy who made Bustin' has this little app that judges you when you're not working. You tell it which applications are work (ie. Unity), and when you use them it's happy and the timer goes up. When you don't use those apps it turns red and judgey and the timer no longer counts up. Simple, motivating, enlightening.
EmojiKeyboard. I'm no marketing wizard, but, @ScaryWizard's most popular tweets have emojis in them. Hardly scientific, but ¯\_(ツ)_/¯
I'm going to keep this post short and sweet, thanks for reading.
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.
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.
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."
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.
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.
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.
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.
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!
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!
For this week's dev log, I thought I might take a minute to write about a few of the tools I have been using to develop Monumental Failure.
Polyworld by Quantum Theory. I purchased their "Woodlands" pack a few weeks back. The pack can convert Unity terrain objects to hard edged objects, i.e. low poly. The package itself contains a few models, and a script that takes a textured model, and spits out a low poly copy.
This pack was great to use at the beginning of development to establish Monumental Failure's aesthetic. However, at a distance, the uniformity of Polyworld's terrain triangles becomes quite apparent, taking away from the "handcrafted" feeling that low poly art usually invokes, and the look and feel we want to achieve in the game. Relying solely on this pack to create our low poly look would be a mistake, so we've decided to develop the look on our own, using the pack as an enhancement when needed.
That said, Polyworld still gets a hearty recommendation from us here at Scary Wizard Games, and is a steal at 50 bucks.
Kino Fog by Keijiro Takahashi. If you're a Unity dev and you haven't heard of Keijiro, you've been missing out! He makes some of the most interesting screen space effects and releases them for free! Kino fog fades your geometry into the skybox. We're using this to avoid the need to create a skybox geometry, something that would rarely be seen with our game's typical camera angles.
InControl by Gallant Games. I had originally set up Monumental Failure's input settings to work with an Xbox 360 controller on a Windows PC. I assumed that when I plugged the controller into a Macbook, it would work. When it didn't, I knew it was time to purchase InControl.
InControl does its best to handle and generalise the input of a wide array of controllers. I'm hoping that replacing my current controller code with InControl will make Monumental Failure a simple plug and play. This peace of mind is definitely worth the 40 bucks InControl costs!
That's a quick summary of some of the tools I've been using. I'm hoping this might be helpful to some of you Unity developers out there!
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.
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
There's some weird banding in the grass that I'm going to have to polish that out. Iteration never ends!
Hello Scary Wizard fans!
Jess here! It's been just over three weeks since Monumental Failure was Greenlit, and we’ve been working hard to get the game ready. We were so caught up with getting our Steam Greenlight submission ready, that when the game got approved, our joy was quickly overtaken by one daunting thought: “Oh god, now we have to actually make the game!”
As a very casual gamer, and someone who, up until the beginning of this project, had just about no involvement in the gaming industry, I really had no idea what to expect as an artist working on a game, let alone an indie game.
The first monument model: a roman aqueduct.
The most challenging aspect of working on such a small team is having nobody to turn to when things go wrong. Spencer and I have very complementary skill sets, but neither of us really knows how to do the other one’s work. I know nothing about programming or coding, and Spencer’s no 3D artist. We’re both really working on our own, and only have ourselves to figure out any issues that come up. Fortunately for me, I’m always up for challenge.
My biggest challenge so far has been rigging the game’s characters. We decided to create a series of fun, low-poly characters to use in the game. Rather than having stiff characters with only moving arms, like the characters in the demo version Spencer creates, I figured I could design, model and rig up some cute characters to add some more appeal to the game. It should be easy, right? No big thing, I thought.
As someone who absolutely did not want to work in rigging or animation (yes, despite having studied those exact subjects), this was a hugely tedious task that I put off for a good while. Once I finally sat down to do the rigging, I figured since I’d aced my rigging courses in college, I'd be totally fine. Well it didn’t take long for things to go south, and I had to re-evaluate my approach and throw out all of my previous work. I did eventually get the rigs completed, but it was definitely a struggle. On the plus side, I can now rig up a character in just under 10 minutes flat, and that's an accomplishment I think I can be proud of!
These two look more prepared for a dance party than for some serious monument building...
Being a two man team means we are both constantly faced with tasks that we have absolutely no idea how to do, and yet we have no choice but to learn how to do them. I don't think there is any better way to learn to do this stuff than to jump right in.
We've been Greenlit! It's a great feeling to cross this milestone with the support of the community behind us. Thanks to everyone who voted for us! We could not have done it without you!
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 Failure's 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).
Toronto has a lot of raccoons, so when Jess proposed it as a logo I was down.
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.
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!
This was originally posted at https://www.idlethumbs.net/forums/topic/10838-devlog-project-stonehenge/?p=402447
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]
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 conceptualising 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 Gang Beasts. 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 and a split screen mode.
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.