© 2023 by Dawkins & Dodger Architecture. Proudly created with Wix.com

Featured Posts

Guiding The Player

March 10, 2017

 

 

Hustle Hobo - Dev Blog #002 : Guiding The Player

 

               In our game, Hustle Hobo, we faced a problem that we hadn’t foreseen earlier in development. While we had some fun mechanics implemented, we found that some of the most fun mechanics were distracting from the core experience that we intended. It may seem like the best option would be to ditch the other mechanics, but it had to be realized that the distracting mechanics were not dynamic. Though they alone were entertaining, their lack of interconnection with the actual game meant that they were limited to their own single purpose and, while distracting from the game, would also become dull quickly. Essentially, we had to clean up our game.

 

               Our solution was to first cut distractions, then we followed up by carefully designing restrictions to the player’s actions to make their playthrough smoother. Lastly, we decided on what we needed most- a main goal. Previously our game was heavily a sandbox game trying to be a management game. The problem with this design is that by having more to do in a management game, the less you’ll want to manage. In this case, freedom is not always better.

 

Cutting Content

 

               Once we got to the point that all our main mechanics were working and there were some models to implement, we decided it was time to clean up. After testing the game for a few weeks, we could point out the mechanics that were either distracting, or simply didn’t add anything substantial to the game. We hadn’t yet cut future content, only content that currently existed and proved to be ineffective. Though future content will have to be cut, that’s a discussion best held after cleaning up.

 

               An example of this was cutting the ingredients. The ingredients were meant to work with the core mechanic to add another layer of interaction, but we found that this content didn’t add as much substance as we’d hoped and the game may even be better off without it.

 

Create Restrictions

 

               Though small, there were many things that were changed to direct the player’s focus towards the main goal. Things such as players missing the item holder when placing an item, or creating a mess of broken glass were subtle, but add up. Previously we made Delivery Boxes destructible on collision, but once we realized this was the most entertaining mechanic in the game, we knew there was something wrong. The problem wasn’t that the rest of the game wasn’t fun enough, it was just that smashing a Delivery Box full of destructible glass flasks against the wall gave more instant gratification than the tasks we had the player do to work for gratification. This was essentially the heroine of our game; overly enjoyable, but overall destructive.

 

               We added things, such as Trigger colliders that allowed the players to go as far as to throw their items and still be able to lock it into the item holder smoothly. We also added randomly delayed Destroy() calls to the glass shards so they wouldn’t remain for long. These changes may have removed some of the realism we intended for, but the changes so subtle yet effective that I believe they help keep immersion intact more than the previous “realism”.

 

Create Clarity

 

               Our main problem with playtesting was clarity. Even with explanation, playtesters would become confused by the lack of indications and art assets. To address this, we added indicators that would appear above interactable objects and stations. These indicators would change based on the state of the player (the item they’re holding), that item’s state, and the state of the stations(the items they’re holding). The indicators tell the player where they can place the items and the next required step for functioning the station.

 

Create a Goal

 

               This may point may seem obvious, but our game had no levels or way to beat the game, so creating a sufficient goal was more difficult. We could have chosen to create a survival game where the player tries to earn the most money, but that just wasn’t rewarding enough. Instead, we chose to implement daily quotas to compliment the day/night system. During the day customers would come, but during the night the player would have down time to resupply their inventory and prepare for the next day. Along with this, the player would be required to make a specified amount of money every day to pay off their store. If they failed to meet these quotas, they would have their store taken from them.

 

               By doing this, we change the perception of what the game is about- it’s not simply about survival or messing around- it’s about management. Though we want the player to focus on the work and crafting systems, we also want them to feel immersed in their commitment to the store’s well-being.

Please reload

This site was designed with the
.com
website builder. Create your website today.
Start Now