Replay Value in Shrink & Grow
After meeting the amazing and wonderfully inspiring Matt Brown from Extraordinary Facility last week, I've decided to create weekly posts about my side projects. Hopefully this will help me retain my findings and also document best practices, but I imagine the benefits will extend to infinity and beyond. Here's to post number one!
Our first game was created as a final project for 12 week VR class at Upload SF. We originally had four people in total on our team, but by the end, Jay Jansen and were shouldering 99.999% of the work.
The idea was a puzzle game where you needed to use scale to fit puzzle pieces into a mold. It wasn't our first idea, but we liked the use of scale to modify object properties, and it wasn't something we'd seen before. We also thought it was a simple enough idea that could be executed within the short timeline. We did complete the game but not without problems. There were numerous bugs and performance issues and we were so burned out by the end, we threw the project into a folder and swiftly forgot about it.
Last weekend we decided to pick it up again. Our goal is to ship something, anything. Even if the entire game could be completed in less than 15 minutes, even if we scale down the mechanics even further, it's about getting it out the door. During this final sprint, we will be focusing on performance and refining a few mechanics.
The first challenge we want to tackle is replayability. Now I'm not talking about replay value on par with games like Diablo, where procedural level design is the star. But Shrink and Grow is not a super complicated game; find the puzzle pieces and return them to the pedestal. So we're thinking simpler. We want a feature which will always make things just interesting enough to make you play it at least twice, like Pacman or Space Invaders' enemy AI. We want you to narrowly fail once or twice before you are triumphant. Why? Because it makes winning that much more rewarding!... That and we're probably masochists XD
We don't need AI like Pacman though, so how does this relate to puzzle pieces? And how would we make someone want to play it again after they find all the pieces?
Enter Random.Range(0,0). Jay started with this thinking about randomizing their location which will at least make the game slightly different every play-through. He placed the script on the pieces' scale as well, so they would change their size every replay. But what if they fell onto the towering rock formations? or fell through the ground? Or if they got stuck between the terrain collider? It wasn't going to work, too many variables.
The idea was in the right place though. We needed something that could spread the objects within a zone as defined by a vector3 coordinate. So we sketched the image in Fig 01 and said:
Let's plot zones represented with cubes, where various pieces can spawn, and reference the position of the cubes so we may change the spawn region at any time.
Eureka! This could be the key to unlocking our replay value! Combining cube primitives with location and scale randomizers, may be the one tiny piece which makes the game worth playing more than once. We soon found this site which supported our idea.
That not all we've been working on. We also changed the tree colors, started optimizing the foliage, brightening the shadows, removing unnecessary lights, changing the shrink and grow buttons to a boolean, cutting our grass, figured out which robot was purple and which was yellow in Subsurface Circular, decided to include a snarky joke about kittens into each project, and so much more. But the randomizer was definitely the most profound due to the implications. It's no procedural map generator, but we'll get there one day.
print("Keep Looking Up");