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? 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! Thanks for reading, Spencer
0 Comments
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 InfernoLittle 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. DrawfulDrawful 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. OctodadOctodad 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.
Thanks for reading! Spencer 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. More news coming soon! Thanks for reading this post. Cheers, Spencer 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! The ramp is too short. But this doesn't mean you can't succeed. 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! That's the idea anyways. Let me know what you think. Cheers, Spencer |
Archives
March 2017
Categories |