Alrighty. So. I have really really been brainstorming about TotemHead's mechanical development. It's a game, yes, but what kind of game? I know the "hub" world is the village, and the "levels" are the communication you have with each character, and that's all just great. But what does that mean? Communication isn't a mechanic on its own. And so I sat down and I brainstormed and scribbled until I came up with something... real. I got about halfway done so I think it's sharing time.
I started with the basics; what is communication? The exchanging of information. Okay, so you bring a thought from point A to point B. That sounds like a good start to a game mechanic...
So ultimately I decided the mechanic would have two parts; the "Request", in which TotemHead sends a message to the target character to request information, and the "Response", in which the target character sends information back. Below is an example of the Request portion of the mechanic.
I started with the basics; what is communication? The exchanging of information. Okay, so you bring a thought from point A to point B. That sounds like a good start to a game mechanic...
So ultimately I decided the mechanic would have two parts; the "Request", in which TotemHead sends a message to the target character to request information, and the "Response", in which the target character sends information back. Below is an example of the Request portion of the mechanic.
The player will draw a line from TotemHead (represented above as the little TotemHead token), to a target character (in this case the squirrel). The line has a specific set of qualities based on how the user draws it; the length, shape, and speed.
The target character has a set of required properties for the line that must be met in order for the level to be completed. The line must reach a certain speed, shape and length. The line can be re-drawn as many times as necessary until these requirements are met.
As the player's line gets closer to the required properties of the line, it will become lighter, brighter, and will emit sparkles. The player uses trial and error to create the perfect Request line for each character.
Once all the requirements of the line are met, the "request" is complete. The second half of the mechanic will represent the target character's response.
So that's the mechanics I have developed so far. Each of the line properties will be stored as a number in the code so that it can be used again to generate the map used for the response half of the challenge. This will create a unique experience based on how perfect your line is in the first half of the game.
So that's the mechanics I have developed so far. Each of the line properties will be stored as a number in the code so that it can be used again to generate the map used for the response half of the challenge. This will create a unique experience based on how perfect your line is in the first half of the game.