banner



Game Design Sprint And Crouch

This is my own personal account and analysis of an experiment I was a part of with my cohorts - you can read about that write-up here.

The Backstory

It was a Monday in December when it was suddenly sprung on me that myself and a few of my colleagues would be taking part in a quick experiment for the week that involved us taking a game concept my boss had been kicking around for a while, and running it through the GV Design Sprint. Partly to see if it could be leveraged within the realm of video game design & development and partly to see if we could take this nebulous concept and solidify it quickly.

When I say nebulous, I mean nebulous. Here's what we were given:

"It's called Atomic Pig...and it'll probably be a runner."

So there's a certain amount of exhilaration that comes from being that open-ended, however, as we dug into the process it became clear that having that broad an opening can end up causing some churn that the design sprint couldn't hammer out through process alone.

Into The Fray

As previously mentioned, this whole thing was somewhat sprung on our group - which means we took a short-cut from the typical way you'd approach a design sprint where you "Set the Stage" involving a little bit of a process getting that together. Our stage setting consisted of literally diving in - watching the design sprint introduction video, and immediately getting started. Lucky for us, our office already has a perfect "War Room" where we had ample whiteboards and other dry-erase compatible surfaces for literally throwing ideas onto the walls. We also are lucky enough to have the "supplies" necessary for this process.

Shortly after that though, we were off to the races! The team consisted of a few folks that aren't normally involved directly in projects I'm otherwise working on, so I really enjoyed the exposure to others' way of thinking. And nothing brought that to light quicker than day two of the whole process.

This day starts off by taking prime examples of already-existing "solutions" that can be remixed or improved upon. The latter portion of the day is where team members begin sketching and voting on ideas that have been floating around in their heads - the intention of which is gaining quick alignment among the members of the team on what "solution" begins inspiring and rallying them.

Where Thought Paths Fork

It was somewhere in this process that I started to notice a trend. We had a lot of really good ideas manifesting themselves onto our walls - but it was getting hard to see the coherent sum of those ideas aligning between team members. We had bits and pieces of features, mechanics, collectibles, and even transitional states - but it seemed as though the part that became nebulous would be what the core gameplay loop or experience was going to be for our players.

This became even more apparent on the second round of voting through the concepts and ideas that had been sketched - we were beginning to align on neat hooks - but the real meat of Atomic Pig wasn't coming together yet.

When Worlds Collide

The design sprint was working its magic - but this is where I felt things started to become unhinged from the reality of game design. While there are genres of games that can take a sort of "check-list" approach to what is expected of their gameplay:

  • RTS games having multi-unit selection & command
  • FPS games having the player able to jump
  • RPG's having stats for your character that can be improved upon

Video games aren't typically defined by a well-groomed list of tasks or features that can just be compiled and assumed as being both "the game" and fun. There are smaller nuances, overarching themes, and types of interconnections between gameplay mechanics that add to the overall experience. It's in that coherence that makes otherwise unknown games shine like well-polished diamonds.

Apps, however, are a completely different beast. Yes, there are nuances in the UX provided by an app that will ultimately provide the competitive advantage - but apps exist for a purpose - they exist to help their users accomplish a goal. For example you've identified a need for:

  • Tracking vehicle expenses over the life of car ownership
  • Finding a reliable ride to & from places
  • Analyzing the WiFi landscape around your home

These are all goals that can be clearly defined and addressed through specific features of the app itself. In short: running a design sprint on these goals is already providing a pretty clear "boundary" the team members' ideas can flourish within.

Contrast that to some goals for a video game:

  • Entertain the player
  • Provide good value to enjoyment ratio
  • Be a "runner" about a pig, and "atomic" fits in there somehow as well

You can start to see how the game idea might need a bit more definition before ramming it through the pipe of the design sprint.

The Net Result

The planning we did for the sprint and what we were going to test for ultimately came together and provided some very useful insight and critical course-correction that would've otherwise been missed had the sprint not occurred.

The team was energized from the collaboration and thought exercises and, assuming we push forward with actually developing Atomic Pig - we had some great insight into what our primary personas would likely enjoy as it applied to the game.

Additionally, given the retrospective that we hosted for the process too - the team was aligned on what was working and what wasn't for the overall concept.

You can read more about the group's lessons-learned from the Handrail blog.

The Aftermath And The Big 5

Once it was all over and done, it was through some discussion and retrospective with team members that it seemed as though that game ideas have a few larger overarching baskets in which major decisions about the game will drastically impact the prototypes and finished product.

These "Big 5" all represent factors that should be considered while putting together the concept and depending on which of them are nebulous or concrete - it'll likely have a big influence on how the team tackles design discussions related to it. Think of them like valves inside a network of pipes - if you "decide" on any one of them and turn on the water, it'll direct all of the creative juices down a more specific path.

And yes, you can always humor an off-the-wall or unconventional application within those spaces, but ultimately these five things seem to be the ultimate boundary for the game to exist within.

But largely if any of these are decided or given to the design team, it'll help reduce the alignment time needed for those involved.

Target Player / Primary Persona

Pretty straightforward - get a good idea for who the primary persona is that will get targeted by your design efforts. This helps narrow down scope and can assist in prioritizing what elements of the game should be developed first. Not only that, but it can also help establish what gameplay mechanics may not have a place in the concept at all.

A while back, Kotaku ran a great article on Matt Hall, specifically around the "rules" he likes to guide himself on when designing games. Ever since reading that nothing has solidified the use of a persona within the game industry as much as his comment about Amanda.

"This is Amanda. Meet Amanda. Amanda doesn't care about embedded skill trees. She cares about her Pony and she wants to feed it sugar and pat it every day."

That kind of solidification around your target audience is what is going to align design efforts the quickest. It'll help focus the team on the elements that Amanda is going to find most appealing about her interactions with the game.

If you had Amanda as your primary target player - then the rest of the design team is going to be able to utilize her persona as a great guideline for what elements of gameplay can and should be considered.

Story/Setting/Narrative

Do all games need stories to be enjoyable? Absolutely not - but coming into the design sprint knowing if this has been created will absolutely help drive creative thinking around a core theme and story.

If this is left open the team can exercise their creative thinking and come up with a variety of backdrops for the game to take place in. This affects everything from narrative and setting tone to art style for characters and locations.

Player Actions/Core Gameplay Loop

This is the real meat and potatoes of the players' experience - however it's also a bit more ethereal in terms of definition.

The easiest way to describe this is being the loop of actions and reactions that occur as a result of the players' input and serves as the basis of interaction with the game itself. For example:

  • Tetris has the player rotate a series of pieces of geometry in order to create a contiguous row of pieces to score points
  • Doom allows players to navigate and shoot within 3D levels
  • Pokemon Go has the player walk their keister around local areas to acquire items and monsters for their personal collection

I'm painting with very broad strokes but the concept is the same - what is the activity or action I, as the player, am going to partake in for 90% of my experience with the game itself.

Gameplay Perspective

Out of all of the Big 5 this one is probably the most straightforward of them all - what perspective am I, as the player, going to experience the game itself. Here's a few examples of what I mean:

  • Call of Duty has me playing from my characters' perspective, on the ground, from their eye-view
  • Super Mario has me playing from a 2D side-scrolling perspective
  • The Division has me experience the world from an over-the-shoulder chase camera view

This will dictate a large portion of how the control scheme of the game is going to come to fruition - if you change your perspective, you have to change the inputs given to the player to control the action on-screen.

Genre

For me genre is the method in which we, as feeble humans, fulfill the instinctual desire to categorize and organize the intangible. Video games suffer from a bit of this same thing, as there's often so much cross-pollination of ideas and concepts throughout many of them that it begins to get hard to nail them down.

I'd even go far as to argue they exist as a means for folks to begin to center their expectations and imaginations when discussing video games with each other. For example, if I began talking to you about a game you'd never heard of - it'd advance our conversation greatly if I used the phrase:

"It's like Diablo; in a futuristic apocalyptic setting, but with less demons and more guns as loot drops."

You'd start to understand what some gameplay elements might be like and subconsciously decide for yourself how the game would play assuming you understood that Diablo is a classic example of a Role Playing Game (RPG). From that information you can assume a few things safely in our conversation.

As one of the "Big 5" - having this component locked in or yet-to-be-decided also opens up a lot of creative freedoms in either scenario. But it can serve as an excellent means of guiding the thinking along well-received concepts with spaces players are familiar with.

Not that it's important; but I was talking about Borderlands if you were curious.

In Conclusion

I think that the form and guidance the design sprint can offer is a powerful tool that design groups can utilize to rapidly find the concept that resonates best with the design team while getting as close as possible to meeting business goals.

To apply this process to the act of designing and, ultimately, developing a video game however, seems to require a few tweaks:

  • As a part of the "Setting the Stage" phase - ensure that there is clear indication on what, if any parts of the Big 5 have been locked in or concretely decided upon as a part of the business strategy
  • Focus or Extend Day 2 - concentrate on narrowing down and riffing on ideas that seem to run in alignment among the team members. Consider limiting sketch & vote sessions to smaller time frames of an hour or less even, to potentially take each of the Big 5 that haven't already been decided upon to gain alignment assuming you need to maintain the strict 5 day cycle
  • If you have the time, consider taking more than a day (I know, this breaks the 5-day thing) for the process of sketching and narrowing ideas within each of the Big 5 that haven't already been decided
  • Consider having team members focus on bringing cohesion to strong threads with the Big 5 that seem to line up for a strong game concept for Day 3's discussions on top candidates and storyboards
  • During Day 3 - Facilitate open discussions on the "top candidates", ensure nobody is married to an idea and be adaptive with concepts that are out there
  • Again, games are an amalgamation of concepts and cross-pollinated ideas that can find homes in unusual places - so rather than tossing an idea out altogether, see if it makes sense for a strong thread of design to find a home in an unconventional way

I'd absolutely love to hear or see stories about other game developers who give this a shot. This was just my analysis on the whole process, but overall it was an exercise in rapid creative thinking that was awesome to be a part of.

If you'd like to share your experience with the design sprint, feel free to reach out to me through Twitter, or here in LinkedIn as well.

Game Design Sprint And Crouch

Source: https://www.linkedin.com/pulse/how-five-days-google-design-sprint-applied-game-what-grant-poock

Posted by: mcguireectilow.blogspot.com

0 Response to "Game Design Sprint And Crouch"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel