New Control Scheme Adventures

One of the biggest problems SunBots had at the end of last semester was its control scheme. The game used a dual stick setup, with the left stick controlling movement and the right aiming energy shots. Although our primary testers (~20 year old gamers) largely found this setup intuitive, we got significantly different feedback from the professors who played our game during greenlight deliberations, who generally found the setup a bit unwieldy. A dual stick setup requires a very high level of hand-eye coordination, which clashes conceptually with the rest of SunBots, which is generally casual-friendly.

Additionally, our game very strongly gives off a tablet vibe, due to its colorful aesthetic and simple concept. However, our movement alone made our controls too complex to work on tablet. On a planet, the player can only move one of two directions, clockwise or counterclockwise. However, simplifying this to a binary input is problematic. Left, right, up, and down mean different things depending on where on the planet the player is. On the north pole right is clockwise and left counter, but the opposite are true on the south pole. This led to us creating a sophisticated series of checks to properly translate the left analog input to what makes sense based on the player's general position, taking 8 different possibilities and condensing them into the two real outputs.

Since tablets don't have any buttons or tactile feedback, their range of input is limited. You only have so many discrete actions possible before they begin to blend into one another. Taking our complicated movement system and porting it to tablet would leave us with a mediocre product. So, we simplified, and cut direct movement entirely. Movement on planets wasn't ever a core part of our game; it was more a means to an end, the end being solar system movement. Now, the player has a constant velocity when on a planet's surface. They can press a single button (an easy input to port to tablet, once we begin seriously building tablet controls) to swap directions. This system works great; it never feels like you aren't in control, since the important control takes place in space. It just goes to show the power of simplification and outside the box solutions.

SunBots Second Semester Funtimes

It's been a very exciting development process so far for SunBots. Ever since settling on a concept we've been off to the races, and it's somewhat amazing how solid of a product we have after only 3 months and 4 people. But now it's time to really get going; we've double in size and with an extra 4 months, SunBots could be amazing. We've already got some cool ideas about how to expand on our premise from our new members. I don't want to talk about them now since we don't know what we'll pursue and what we won't, but suffice to say we're going to be doing a lot of cool new things.

Since we've just started our second phase of development, there's not much to talk about so far; we're still figuring out what we want to do and who will be responsible for what. We've been doing some housekeeping; cleaning up code, cleaning up our repository, basically making things easy for newcomers to get into and work with. Expect some fun updates next week. I'm very confidant we'll have lots of cool updates.

Final reflection

            Wow. This semester’s been quite the journey. I’ve spent so much time and energy working on Sunbots it’s easy to forget it’s only been about 3 months since the game’s inception, and that for the first 3 weeks it wasn’t even clear Sunbots would be our game. But through this whole process I feel like I’ve learned quite a bit about the process of game development, what makes ideas successful (or not successful) and much more.

            When our team first formed in late April, we had a couple meetings to try and brainstorm ideas for our upcoming Senior Capstone project. Unfortunately, we were in the final stretches of work on our Production II games, in addition to high end-of-semester workloads in our other classes, and were thus unable to come up with any ideas whatsoever. This was to be expected, and wasn’t particularly concerning; after all, we had months before the class even began; surely we could come up with something good during that time.

            We proceeded to hold several Skype meetings over the summer, and we had plenty of ideas then. Unfortunately, almost all of them were terrible. We seemingly had the opposite problem from April; with so much time, our ideas were overthought. They were all too cute high concept pieces that sought to say something important about the human condition or redefine what games could accomplish artistically or some other lofty goal, but no attention was paid to the basics of play. These ideas focused on interesting environments, or narrative settings, but a game needs to be fun to play, first and foremost.

An argument can be made that a game does not necessarily have to be fun, but simply engaging, and examples of such certainly exist in the wild (Spec Ops: The Line, Every Day the Same Dream, etc.). However, pulling off something like that takes a lot of skill, and requires an especially strong artistic vision. Quite frankly, I don’t think a team as relatively inexperienced as us would be able to pull it off. We can learn vicariously here; two years ago, a senior team produced The Return, a game which is often derided amongst the game cohort for being thematically overblown and mechanically unsatisfying; the Flash game Don’t Look Back delivered on many of The Return’s goals much more strongly, with a release several years before The Return. However, a team comprised largely of the same members made the puzzle game Loc during the same timeframe. Loc is based in interesting and engaging puzzle mechanics first and foremost, and although it has a (largely unnecessary) narrative component, by focusing on the mechanical play Loc delivered a very engaging experience, significantly more so than The Return.

With an acute awareness that our concepts were more The Return than Loc and with summer swiftly drawing to a close, we staged a brainstorm session with specific restrictions. Each idea presented must be mechanically based, and if the idea was agreed to be strong it must be possible to create a prototype within a week demonstrating the core mechanic. The ideas that came from this process were much stronger. Of particular note was an on-rails platformer idea with a focus on “shifting”. This idea went through several iterations even before the semester began: it was fun, simple, but with great potential for expansion. It seemed for a few weeks that this would be our team’s game.

 However, the rail prototype had one main failing; rail platformers are HUGE right now, and it was hard to find a point of differentiation. Our game was engaging, sure, but it wasn’t particularly memorable. We’d avoided the trap of being pretentious, but being bland is similarly disastrous. I feel that if we had stuck with the rail idea we might have been able to come up with an interesting twist at some point; looking at VXT, that game has some similarities to the red-blue shifting prototype we made, and it’s not hard to imagine a parallel universe where that game evolved from our prototype.  But we at least weren’t feeling the creative spark with that idea, and we might have been doomed to mediocrity without a savior.

The game that would eventually become Sunbots did not have a very auspicious start. During the first week of the semester, Melissa had a vision for a game where a robot jumped between planets in space, with fully realistic gravity affecting their movement. She began prototyping, and the initial iterations were none too promising. They were in full 3D, mirroring actual planetary systems as one might expect, but actually navigating this space was incredibly difficult and confusing. It was hard to tell where planets were in relation to one another, how fast and in what direction the player was moving when they were jumping, and the prototype was generally not all that fun. But it was unique, and as the rail prototype’s derivative nature became more and more apparent with each passing week, we were desperate for another route.

So, we decided to try a radical alteration of the planet prototype to see if the idea was in any way workable. Mainly, we decided to shift the game from 3D to 2D. This severely limited the player’s movement options, and could have left the concept stale and uninteresting. But it was instead exactly what we needed. The removed dimension took our camera problems with it, as the singular plane of play meant we always knew the optimal viewing angle for the player. With our camera problem solved, we could easily show the players their movement relative to other planets since we could keep many planets in view at a time.

It’s not like this one change magically created Sunbots, or even solved all of the prototype’s main flaws (the controls in particular would take another week or two in order to be presentable) but its importance cannot be overstated. After the shift to 2D, it became significantly easier to see where the game could go in the future, and to be assured that it could be realized. Without the shift, we could not feel assured that our concept did not have inherent fatal flaws.

            Ultimately I think it’s fitting that our best idea had such an unassuming origin. It wasn’t the product of a specialized brainstorming session or some carefully honed high concept. Melissa had a vague idea of something that sounded like it might be fun, but it took a lot of iteration to get into an enjoyable shape. I think that iterative process is key to what made Sunbots work so well, especially when contrasted with our other ideas. Because we had no preconceived notions about how this was supposed to work, we were able to go wherever made the most sense in the moment, creating a stronger end product.

            As Sunbots came together, we began targeting two different demographics, as mentioned many times throughout the various presentations and stage challenges we’ve made over the semester: the young, and the young at heart. This is most clearly demonstrated via our art style, which is colorful, cute, and playful. Over the course of the semester our team’s received a lot of great positive feedback from testers and colleagues, and we were ultimately rewarded with a green-light for second semester. Clearly we were doing something right, and I believe our aesthetic direction is a key contributing factor. There were a lot of strong candidates this year, with many potentially good games getting cut in the interest of logistics. Any game wishing to avoid this fate needed to stand out, and visually nothing quite looks like Sunbots, especially amongst our peers. The game is like a storybook come to life; to my knowledge, only Kirby’s Epic Yarn has a similar aesthetic.

            However, this visual style has also caused complications. Sunbots has moderately complex controls, utilizing both analog sticks and all four shoulder buttons. Although it can be played with mouse and keyboard, it’s a game that’s been designed with a gamepad in mind. During QA testing, this control scheme has met with near universal positive feedback. Players required a few minutes of unstructured messing around to get the hang of things, but once they did they were lost in the game, controls no longer being a barrier.

            But our QA testing was limited in a way we didn’t quite realize until late into the semester; namely, every last one of our testers was a college student, age 18-22, with an interest in video games large enough that they’ve elected to spend $40,000 a year in order to learn how to make them. These are people steeped in the language of gaming, with entrenched muscle memory. They understand how a dual-stick game works; using the left stick to move the avatar and the right to aim shots makes complete sense to them.

This built up gaming knowledge sometimes colored the feedback we would receive. For instance, when I first built the gamepad controls for Sunbots, I assigned jumping to the A button. This is the default in gaming, especially for games related to platformers. Pressing A to jump is like understanding that a cut in film doesn’t break the continuity of a scene, a skill internalized to such a degree that it can be hard to imagine the medium without it.

Of course, this only applies to gamers who play on consoles; PC players do not internalize this. Therefore, we would occasionally get a tester with minimal console experience who found our jump controls lacking; namely, you use your thumb to reach the A button but both thumbs are often occupied by the analog sticks. These players would generally recommend the jump command be remapped to one of the shoulder buttons, which are accessed with your index finger. Their critiques made sense, and so we altered our controls, remapping jump to RB. We removed all mention of the A button being the jump command, and put the game in front of new testers.

They generally liked it, but more than a few felt the jump controls were counter-intuitive, and requested they be mapped to A. Even though there was no real difference between the two inputs in terms of how they impacted play, and even though RB was more easily accessible during play, pressing A to jump was so ingrained in players that they wanted to do it anyway. We found a very easy compromise in this situation, mapping jump to both buttons so that either preference was accounted for.

However, we also encountered another issue, one which we still have yet to fully resolve. During the green-light demo night, our game was played by the EGD and COR faculty responsible for determining what games would go forward. These players fell into a completely different demographic than the ones we got through the QA lab. They weren’t hyper coordinated 20-somethings, and some of the COR faculty had limited familiarity with gamepads in general. They found our game significantly harder than we had intended, and had difficulty understanding the controls.

Well, so what? We were still green-lit, and we could simply argue that a lack of familiarity with gaming conventions puts one outside of our target demographic, removing the need to cater to people who don’t understand how to use two analog sticks simultaneously. However, our aesthetics told a different story. They were inviting, accessible, and told people that this game was for everyone. In fact, we’ve been told many times that, because of our artistic style, we should really consider a mobile release, possible even making it our target platform.

The idea that brightly colored, up-beat games belong on tablets is fairly powerful right now. With dark, gritty games like Call of Duty and Grand Theft Auto breaking sales records on consoles, it can feel like only those types of games belong on a gamepad. For years, people have been calling for Nintendo to release their stable of brightly colored, friendly looking games on mobile devices. Noted games industry analyst Michael Pachter has gone as far as to call for Nintendo president Satoru Iwata to be fired for not porting Nintendo content to tablets (Peterson).

But let’s look beyond the impressive stats of Angry Birds and Candy Crush Saga. There is in fact a very good reason why you won’t find Mario games on iPhone, even ignoring that Nintendo owns the competing 3DS. Tablets are a very limiting platform for game development, and it has everything to do with controls. There’s only so much you can do by poking and swiping at a screen, and secondary input methods (such as gyroscopes) are often too imprecise to use in a game which requires precision, which is sometimes true of Sunbots. So far, no one’s been able to make a traditional platforming game with a traditional range of motion work on mobile. Sure, there have been great successes when the genre’s been reinterpreted (Temple Run, Rayman Jungle Run) but a game where you can go in any direction and jump at will has so far not materialized. Ports of games like Sonic the Hedgehog exist, but work quite poorly, since they utilize a virtual controller, which simply doesn’t work without tactile feedback. Since Nintendo games tend to require precise input, their games belong on traditional platforms, with analog sticks and physical buttons galore.

I feel the same way about Sunbots. There’s a lot of pressure for us to think about mobile, even from within the team, but I’m ultimately hesitant to pursue that platform. Although our game certainly has a “mobile” look, what makes our gameplay fun and unique is our movement system. Figuring out how to manipulate the gravity of all the planets in a system in order to travel is a hard but rewarding process; with an imprecise mobile control scheme this would be lost. Even games specifically made for mobile, such as Angry Birds, can suffer greatly (or even be crippled outright) by the imprecise nature of poking and swiping as input. Try making the same exact shot twice in a row in Angry Birds and you’ll see exactly what I mean.

Making Sunbots has been a great learning experience for me. I’ve learned what makes ideas good and not-so-good, although the greatest lesson there was that you sometimes can’t get the complete picture without a little digging. I’ve learned the importance of aesthetics, and how they can sell your game, and sometimes even sell a different game entirely. I’ve even learned a little about myself; during the course of this project I’ve really enjoyed the work I’ve done as a makeshift second programmer. I like the problem-solving aspects of that job; you have a specific goal in mind, and you work to accomplish it. In contrast, I haven’t enjoyed the design work nearly as much, since it can so often be a game of guess and check, where you don’t know if you’ve done something right until you get a bunch of other people to play it and gauge their reactions. This is reflected in our team composition moving forward; we acquired two new designers but no new programmers, sine I’ll be transitioning to full-time programming work next semester. I’m very happy with what we’ve accomplished so far, and I can’t wait to see what we’ll accomplish in the future.

Works Cited

Peterson, Steve. "Pachter: "I Don't Know Why Iwata Is Still Employed" Gamesindustry.biz.

GamesIndustry International, 05 Dec. 2013. Web. 09 Dec. 2013.

AI demonstration

I chose to research obstacle avoidance steering. This technique is basically what it sounds like: it involves steering a moving object such that it will never collide with obstacles. We do this via the use of raycasting. The moving object casts the rays; one straight forward, on angled above, and one angled below. If none of these return a collision, than it’s business as usual. However, if a ray returns a collision, the player moves parallel to the collision point’s normal, away from the obstacle.

Fig 1: The bottom ray has returned a collision. The green line is the normal to the collision point, and the gray line is the parallel the player will travel along.

However, this wasn’t quite enough to achieve the desired effect. When the AI unit isn’t avoiding obstacles, it’s moving towards a goal on a linear path. Therefore, if the AI encountered an obstacle it was because said obstacle was in between the AI and its target. What this lead to was a stuttering effect; one frame, the AI would detect a collision and steer to avoid it. Now the AI wasn’t facing the obstacle anymore, so next frame it would turn to face its target. But since it’s only moved one frame’s worth of distance, it would be right back to facing the obstacle, repeating the process. Since it got that frame of movement in the AI eventually made its way around the obstacle, but it was an ugly process.

            To circumvent this, I implemented a buffer for defaulting to target seeking. Before switching to the target seek steering, the AI would raycast in that direction, with the same spread as a normal cast. If the raycast returned a hit, the AI kept on its avoid steering, but if it returned nothing, the AI switched back to target seek steering. This cast was a little longer than the obstacle detection cast, since otherwise the AI got out of range prematurely and would stutter similar to how it would stutter without the check at all.

Fig 2: The player is avoiding the blue planet.  Although the obstacle detection (red rays) is giving the all clear, the buffer (blue rays) is telling the player that a switch would be premature. Therefore the player will keep avoiding the obstacle until they have fully cleared it.

            Over the course of my research I used 3 main sources. I first looked at an article by Craig W. Reynolds of Sony Computer Entertainment America discussing various AI behaviors (found here http://www.red3d.com/cwr/steer/gdc99/). Of particular interest was his section on obstacle avoidance steering. He discussed the common method of avoiding obstacles based on bounding spheres, as well as the general theory of only caring about objects in the AI’s movement path, and only caring about the closest object at that.

            From there, I found a forum discussion on gamedev.net (http://www.gamedev.net/topic/632735-help-with-obstacle-avoidance-behavior/) that brought up the alternate method of raycasting. The users “slicer4ever” and “IADaveMark” discussed the benefits of bounding spheres vs. raycasting. Although I intended to demonstrate this technique using spherical obstacles regardless of my approach, I decided to use raycasting since it was the more general solution, working for any convex shape. Finally, I found a great starting point for my work using the pseudo-code found in “Artificial Intelligence for Games” by Ian Millington and John Funge.

            This technique has uses for many action-based games, since it solves a very common problem. Many games require AI to successfully navigate around obstacles, and if said obstacles are constantly moving or being dynamically created or destroyed, A* pathfinding becomes wildly impractical. This technique relies on raycasting, an expensive process, meaning that it is unsuited for platforms with constrained processing time, such as mobile.   

Lessons learned from Cookie Clicker

Earlier this year, the browser game Cookie Clicker swept the internet. It's an absurdly simple game: you click a giant cookie to get cookies, and then spend those cookies to get more cookies via upgrades. You quickly reach an absurd number of cookies, but there is by design no grander goal. Your entire purpose is to make more cookies. This is a game that sounds monumentally stupid on paper, almost like a parody. And yet, it's been a huge legitimate success. Many people play it and derive enjoyment from doing so, despite (or more likely because of) how silly it is. It's easy to simply write this game off as a novelty or a fluke, something that gained popularity simply through audacity that cannot be replicated.

However, if you look beneath the surface there's actually something here worth studying. At its heart, Cookie Clicker is a game about resource management. Your goal is to maximize your production of cookies, but you can spend cookies now to make more cookies in the future, and you can choose whether to spend them quickly on cheap items, or save them for something that will have a greater effect. Lots of games feature more complex versions of this same interaction, usually involving an additional variable, such as damage (do I spend 100 sun for a peashooter now, or save 200 for a repeater later?) or some other consideration (do I use star power to survive the tricky solo or on an easier section I know I can keep a good score multiplier through?).

This basic idea has applications for Sunbots. Currently, our game features only one resource: sun energy. You collect sun energy from planets, and use it to expand the sun and fight its decay (avoiding one of our game's lose states and achieving its win state) but also use it to more easily maneuver your character. A more recent feature involves using it on the planets as well, charging them to allow them to produce more energy over time. This is where Cookie Clicker comes in. Where Cookie Clicker first gets fun is the first moment you produce an 'absurd' amount of cookies. Where this point lays is different for everyone, but around 1,000,000 is a good benchmark. Progress in Cookie Clicker starts out very slowly; one cookie per click, no automatic production. Your first improvement (for your average first-time player, anyway) will be a cursor, which produces 0.1 cookies per second. From this slow production, you can build up auto-clickers, getting your automated production up to the point where you no loner have to obsessively click yourself, before you reach critical mass and revel in how many cookies you are now producing. From humble beginnings, you have wealth, an embarrassment of cookies. This is the fundamental emotional underpinning of the Cookie Clicker experience, the feeling of going from rags to riches entirely through one's own work.

This is what can be applied, not just to Sunbots, but any game about maximizing and managing resources. Starting small, making growth start slowly, but increase faster over time until you have more resources than you know what to do with; this is the core of an inherently enjoyable resource system. Cookie Clicker exemplifies it so well because it consists of the entirety of gameplay. It is a distillation of a common design element, all the more potent for the lack of filler. By looking at the fun in Cookie Clicker, we can apply a similar mentality to our burgeoning resource system. In general, all games can benefit from knowing what their individual elements contribute in a vacuum and how they best work on their own, so they might also know why and for what purpose they might be utilizing said elements. 

Decision Time

So far in my posts I've covered the progress on the rail platformer prototype. However, as I hinted in my last post this is not the concept our team is ultimately developing. Instead, we're pursuing an idea we're calling Sunbots. In this game, the player is a robot gathering energy from various planets in a solar system. Their goal is to deposit this energy into the sun, which is slowly dying. Since the game takes place in space, each planet has gravity which affects the player, and the challenge comes in utilizing these gravitational forces to effectively navigate the system. 

We liked this idea better than the rail game because of its uniqueness. Very few games use gravity outside of a force to keep you on the ground; even Super Mario Galaxy mainly used it for set dressing rather than truly exploring it as a concept. However, this idea was also significantly more risky. Since complicated gravity systems basically don't exist in gaming (the main exception we found, Gravity Pods, was a puzzle game in the vein of Angry Birds rather than a game with a directly controlled avatar) there isn't a strong well of battle-tested ideas to pull from when working on this.

When we first prototyped Sunbots, we did so in a fully 3D environment. 3D is sort of a default for a lot of game design, but it seemed to make sense for this concept; a large part of the fun of it seemed to be in movement and exploration, both of which work well in 3D. However, we quickly ran into problems. The vast majority of 3D games are mainly controlled on a 2D plane. The player may move up or down, but often only through the terrain or temporarily via jumping. Most of your day to day movement is along the X and Z axes. Adding full 3D control makes things a lot more complicated, and this was acutely felt in our game's camera.

Plainly put, the camera didn't really work with the movement. Our game world, by necessity, had a fair amount of empty space, with respectable distances between planets. Unless you were right by a planet, it was very hard to tell in what direction you were moving. Since there was full 3D movement, you could be pulled in a LOT of different directions. You could be looking at one planet, thinking it was the one you were going to land on, only to be blindsided by a closer planet behind you that you've never even seen. We tried making the camera lock on to the closest planet so player would know where they were going, but all that did was limit the sense of freedom in the movement, and make it hard for the player to see anything around them. If we were going to move forward with this, the camera and movement systems were going to be a constant struggle. This was going to be a very hard challenge.

Oftentimes, when you come up to an impossible looking problem. it's a sign that you're asking the wrong question. We were trying to make our idea work in a 3D space. As it turned out, we didn't actually need 3D to capitalize on what made our concept special. The core of this idea was the inherent interesting nature of a full gravity system, and the fun that could be found in mastering such a system and exploring via it. All of this was improved when we shifted our focus to a 2D plane.

 
It became much easier for players to see where they were going and how they were getting there. With everything on the same plane, the camera didn't have to worry about its Y position, and simply had to exist above the player, moving with them. We could keep our wide planet spacing, and be sure the player would know the galaxy's layout, not having to worry about what direction they happened to be looking in. Once we removed a dimension, things began to click. Our prototype wasn't perfect at such an early stage, but we no longer had a massive unsolved question about the core concept's viability. With this change, we knew that what we wanted to do was possible, and worthwhile. We had our game.  

Difficulty and the prototypes

When we let off last time, we had a few different iterations on a rail-shifting platformer mechanic. We had a version where the player could physically shift to parallel rails, and a version where the player could shift between two colored layers in the same physical space.

The point of a prototype at this early stage in development is to demonstrate a specific mechanic and explore its viability. You don't want to include extraneous systems or elements, for two reasons: they can distract from the core experience you made the prototype to test in the first place, and they can also be a resource hog. Part of a prototype's appeal is that it's quick and dirty, and if done right you can get a sense for what's worth investing significant time and resources into before you have already done so. Therefore, in the interest of simplicity I did not give any thought to the actual level layout presented in the prototype. I threw some blocks on the rails and figured that was good enough. After all, we're testing the mechanic, not the level design. Why spend time fussing with developing a polished play-space if you don't even know if it's for something worthwhile?

The results from the prototype's first round of outside testing were therefore surprising. Players consistently remarked that the prototype felt too easy, and that they felt like maybe it would be more fun in later levels. More than one player noticed that both versions of the prototype were completable using only one mechanic, i.e. only jumping or only shifting. Because the prototype did not require players to actually use all the key mechanics, initial testers were unable to discern how the mechanic actually felt to play.

So it was back to the drawing board. The testers needed challenges which required interesting uses of the key mechanics, so the next iteration delivered just that. There were challenges which required jumping, challenges which required shifting, challenges which quickly varied between the two, challenges which required both at the same time, heck, there was even a later version which combined both shifting ideas into one prototype, featuring challenges which required all introduced mechanics in quick succession. These prototypes were ultimately more successful. Players were able to fully experience the shifting mechanic, and provide valuable feedback because of it.

Of course, this level of challenge density still wasn't ideal. These later prototypes had the problem of being incredibly difficult; players could easily die dozens of times in a couple minutes. Overall skewing too difficult is better than skewing too easy; players may get frustrated, and you may not get the average tester through the entire prototype, but at least they get to experience the key mechanics in a game context, as opposed to a prototype where the key mechanic might as well not even exist. Ultimately, as a team we decided to pursue another game idea entirely (more on this next time!) meaning that this was the last iteration of the rail platformer. However, if it were to get more attention, the difficulty would probably be lowered somewhat, just to create an ideal environment for players to experience the key mechanics. When creating an effective prototype, it isn't enough to simply throw in the key mechanic; there are often key sub-systems or supporting elements that are necessary to show your intent. In this case, it was difficulty.