next up: prefab deletion, clear button, multiple goals, prefab highlight selection (in editing mode), show goal linked to block selected, goal selection and changes, ripple radius adjustment (editing mode), goal radius adjustment (editing mode)
Environment, Architecture I
Today the design team wanted to figure out and solidify mechanics for the prototype since we still had a lot of ideas that weren’t mixing with each other. We managed to get a breakthrough in terms of how the mechanics all interact with each other to create compelling puzzles, and went about designing one.
At first we tried designing the very basic first puzzles the player would experience, but we were hitting roadblocks. So we had the idea to try designing a more complex puzzle that would help us work out the mechanics and then strip the pieces away from that to create the first few interactions. I’ve embedded the video below that shows the more intricate puzzle that helped us achieve this goal, and are hoping it would be the final puzzle in the prototype! To understand the video you have to know about our breakthrough. To solve the puzzle the switches you would activate are pathways that the bubble has to flow over. Ripples would be used to create the optimal conditions to allow your bubble to flow on a pathway, and the player can only flick bubbles, not drag them. The design team will present this to everyone during our next meeting so we can finally start designing our December prototype. For next thursday our goal is to get a “grey box” level running on an iPad!
I included the flowchart we made yesterday in the GDD if you want to check it out!
Basically, after the splashscreen (where we’ll strongly recommend to play with headphones on), all the players see is some kind of visual turmoil, through which we can’t see anything.
The first time, he’ll only have the option to press Play. When he does, he’ll be prompted to speak in some way (text or icon), which will make the turmoil thingies disperse for the players to start the first level.
However, when he gets back to the game, the menu screen will let him either continue his game or start a new one.
The overall structure of the game is pretty simple. After completing the first level, the players will have access to the overworld, from where they’ll go to other levels. This zone is surrounded by the same “turmoil” from the beginning. As the player unlocks level, the safe zone will grow and let him access new places and so on…(this is not very important right now, as we’ll be doing a single beta test level, but please keep this in mind for the long term!)
The game automatically saves the player’s progress after the completion of tasks/puzzles in the levels. On this subject, if the players close the app temporarily to check theirs emails, when they’ll come back, they’ll be exactly where they left. However, if they completely close the app or their iPad, then they’ll be brought to the Start menu the next time they play and their game will resume at the last checkpoint.
I had some thoughts on level design and environment. To craft a convincing environment true to our thematics and game mechanics, the way the level is presented to the player has to happen in a non linear fashion. In a sense, navigating the environment is informed by the core thematic as the rest of the game. This sticks to the core belief that every single interaction of the game has some meaning and isn’t done just for the sake that “all other games do it so ours should too.” Originally we were thinking in terms of “metroidvania” which was creatively constraining and lacking in originality.
An example of non-linear level progression: the character is moving in a spiral cavern, and when they reach the center the walls of the spiral transform into the next game environment (or level) causing a sense of disorientation and instability. This has to be tempered of course, but there are a lot of different ways to play with the expectations a user might have when navigating a linear environment that are really fun and exciting! Rather than moving from left to right, from point A to point B, the game’s progression is artistically more abstract.
I’ll snap up pictures of some sketches on the whiteboard in the TAG lab and add them to a later post. It will make more sense with real examples.
I just wanted to let you know that I’ve set up the game design document, which is available in the Ethereal GDD section of this website. This is just a first draft, so it is bound to grow in the next few days, as I’ll complete some of its sections. Of course, there is some stuff there that is beyond my reach, especially the visuals and sound design sections, so feel free to add sketches or paragraphs.
I think we should have a code if we have to write down things in the GDD.
Normal : text explaining the game
Bold : metrics
Italic : something else?
Hopefully, it will be completed some time next week.
Here are some early visuals. More to come soon.
Down the drain
The light at the end of the tunnel
The next three components are maybe less criticial than the previous two, but it is important to describe them, as they will come into play not matter what.
Position : the emitter has position. That’s pretty much it.
Moving / static : the emitter can be stuck to a position, or can move around, either in a fixed direction or in freeform
Can it be captured by bubbles? : self-explanatory
Is it captured by a bubble? : idem
Size : again, this seems pretty obvious.
Direction : if the ripple created by the emitter is not 360 degrees wide, then the emitter should have a visible direction that is going to hint in which way the ripples will be heading
Synthetic sound : each emitter will have a sound that it will emit. This sound can be musical or a sound effect designed by the team or the sound of a bubble that has been converted.
On/off : some emitters will be on all the time, but others will have to be activated or de-activated by the player
Rythm : does the emitter emit continuously or only in little bursts (if so, at which rate?)
Position : the position of the avatar
Size : the avatar will have a size, probably the same throughout the game
Direction : the avatar must have a visible forward direction, because that’s where the bubble will be spawned from.
Color and alpha : we should put this variable in, as it may prove useful later in the development, if we want to give special properties to the avatar, which he will pass to the bubbles he’ll make.
Velocity : the speed at which the avatar travels after the player’s input
Strength : because we want the avatar to be essentially powerless and useless, its strength would be close to zero, in a way that any ripple would affect him.
ENVIRONMENT (mostly walls)
Camera : the camera will be centered on the player’s avatar to enhance the feeling of exploration as it travels through the contiguous environments. However, it should be far enough in order to be able to get a good idea of the surroundings and manipulate bubbles even after a great distance.
Fluid : if we decide to go with fluid simulations, we’ll have to take into account its properties
Color and alpha : again, this is the idea of giving special properties to walls and obstacles
Wall properties : additionnaly to color, the walls could have visibles traits that would give them special properties (such as letting bubbles bounce)