Posts Tagged ‘design’

Emitters, avatar en environment in details

Friday, October 21st, 2011

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)


Bubbles in details

Thursday, October 20th, 2011

Right below is the diagram of what a bubble is.  I’ll explain each variable.

Voice : well. speak and see how that goes!  Like we said before, we’ll use three main parameters for voice input : pitch, volume and duration.  Like FX suggested, we could have use crescendos and decrescendos, but we preferred sticking to a more simpler set of rules for the time being.

Influence strength : bubbles will be able to interact with their environment, just like our voice in real life can influence our surroundings.  However, this influence has a strength.  Per example, to be able to “capture” a certain emitter, you’d have to have a certain strength.  Or to the contrary, some emitters could be destroyed if your influence strength is too strong.  In a way. this is the “output” parameter of the bubble itself.  It is controlled by volume.

Inflence radius : this is the outer circle of the bubble.  Sometimes, you want it to be big to have a broader “appeal”.  Sometimes, you want it to be smaller, to be “quieter”.

Thickness : this is the actual thickness of the bubble, which is determined by pitch.  A lower pitch means a thicker bubble, which is pretty intuitive if you actually make the sound.  The thickness is, in a way, the bubble’s input recepient, meaning that it determines how the bubble will react to the environment’s different outputs.

Velocity : this is the speed at which the bubble travels.  This applies to when the bubble is dragged as well as when the bubble is flinged.  It is pretty intuitive to think that a small, sturdier and thicker bubble will travel at a smaller speed than a more “agile” one.

Stretchability : each bubble can be stretched via tactile input.  This will let the player fine-tune the bubble’s pitch and volume if he made a mistake while creating it (up to a certain degree).  A thicker bubble is harder to stretch, because its surface tension is stronger.

Burst level : this is a treshold after which a bubble will burst, thus forcing the player to create another one.  We could say it is the most punishing aspect of our game.  The thicker the bubble is, the harder it is to pop.  If the player screams in his iPad, it will also burst.

Size : well…this is the size of the bubble.  The longer the player speaks, the bigger the bubble is.  However, there is a but…

Maximum size : there is an actual size after which the bubble will burst.  This maximum size is determined by the thickness of the bubble.  The thicker it is, the harder it is to get it bigger.

Lifespan : each bubble will have a lifespan.  With that, we create 1) a challenge for the player 2) a way to manage the quantity of bubbles on-screen at the same time.  The bigger the bubble is, the smaller its lifespan will be.  This creates a nice balance between having large and useful bubbles and having smaller but more durable bubbles.

Manipulation : each manipulation would result in a small-to-great reduction of the bubble lifespan.  By manipulation, we mean either stretch, move or absorption and moving of objects.

OTHERS VARIABLES  (these are not on the diagram, but should be taken into account for programming or gameplay purposes)

Created : is the bubble created or not.

Coordinates : the position of the bubble on the screen.  The bubble emerge from the avatar’s position

Touched : is the bubble being touched?  Is it being dragged?  Is it being stretched?

Color / alpha : both of these properties could give new properties that are yet to determined to the bubbles.  However, it would be great to be able to play with these variables if we can.

It think it is all we need for early prototyping purposes, but if you think of anything else, don’t hesitate to tell us!

***Note : the actual visual impacts of each of these variables are still not decided.  However, we feel that what is the most important right now is to get the bubbles working on a pure gameplay-level.  After that, it should be easier to associate each of these properties to a visual cue (if there is a need to do so)***



Design meeting summary 3 : Dark of the Creative

Thursday, October 20th, 2011

Another meeting, another summary!  Yeh!

I’ll write a shorter post this time around…but other posts will come!

Basically, we thought that the first release should be focused on the four following components : bubbles, ripples, emitters and environment (mostly walls for the time being).  We have to add to that the actual player’s avatar.

I’ll detail each of these components over the next few posts, but I’ll do a little summary here, even though you probably already get the idea.

Quick description :

Bubbles :

Bubbles have a size, a thickness (pitch-controled) and an influence force (volume-controled).  The thicker they are, the sturdier they are (slower, but more resistant) They can burst if there is to much tension applied on them.  They are a mean to counter ripples effect, depending on their properties.  They can be stretched and modified to adjust some of their properties.  They can also bounce on some walls, at the expense of their size.  The player’s main concern with them is going to be their lifespan, which is limited. The bubbles can pass their properties to emitters.  Finally, they can push or absorb objects, such as emitters, depending on their influence force.

Ripples :

Ripples have less properties, but are nonetheless very important.  They have a strength, which determines how each ripple will affect an object.  They also have frequency, which determines the rate at which the ripples will emanate from their source.  Finally, the ripple travel at a certain velocity to a certain distance from a certain angle.  They can bounce as well.

Emitters :

An emitter has a precise location.  Some can move around or be captured by bubbles and other don’t.  Each one has a specific sound that it will emit, whether it be the sound contained within a bubble or a sound designed by the awesome audio designer.

Environment :

This one is even less complex.  There would be two types of wall : bouncy and non-bouncy walls.  Bouncy walls would let some bubbles bounce on them.  Pretty straigth-forward, isn’t?

I will detail each component in the next posts in order for us to be able to prototype them efficiently. The next post is going to be about…(drumrolls) bubbles!


Different kinds of voice control

Wednesday, October 19th, 2011

Hi design team,

When you design the levels, think about these different ways of using the voice to influence the game physics :

  • Direct control

voice parameters directly influence the game physics. Ex : if you sing/talk louder, the bubble is bigger. We can consider the loudness of the sound, its length and its pitch. Parameters can also evolve over time. Ex : crescendo (soft start –> loud end). We could do the same with the pitch, starting low and ending high for example.

  • Indirect control

In this case, the effects on the game physics are defined by the relationship between the player’s voice and the background sounds/music. Ex : sing/talk in rhythm, sing the pitch of an existing ripple, try to match the loudness or length of a sound…

  • Layers
It’s a special kind of indirect control. The player records his voice and puts it into the environment (ripples ?), thus creating a background sound. He must then record a second vocal sample that interacts with the first one to influence the game physics. With several layers the player could slowly create a whole “musical composition”.

Design meeting summary 2 : The Creative Team Strikes Back

Tuesday, October 18th, 2011

Another meeting, another flow of great ideas.  I’ll write them down so that everyone can see in which direction we’re heading and make propositions.

RIPPLES + BUBBLES = RIBBLES? (not an actual working title…yet :P)

We thought that ripples and bubbles were both such good ideas that we just couldn’t let one go.  As a result, we found a clever way to merge the two concepts together.


As intended, bubbles will be the actual result of the player’s voice inputs in the game.  These bubbles will have different sizes, shapes, thickness, lifespan and other attributes depending on the player’s intention.  This way, voice becomes the starting point of every single action in the game.

Once created, the bubbles will be modifiable with tactile input.  This way, the player may stretch the bubble, change some of its attributes, etc.  We still have to figure out how far can the player go with the manipulation of bubbles, because we don’t want to invalidate the voice input, which could lose part of its meaningfulness this way.

Ooo, stretch stretch stretch! Stretch stretch stretch! Stretch your buuuuubble! Or not.

We also have to see if it is possible for these bubbles to store the voice sample that led to their creation so that we could replicate the player’s voice by manipulating the bubble in some way. Tech guys, I’m talking to you 😉

We would also introduce and “economic” system, whereas bubbles would have endurance and lifespan depending on their attributes.  Per example, a larger bubble could burst more easily than a smaller one.  The player would also be limited in the amount of bubbles in can create at the same time.  We’ll probably justify that by some kind of oxygen-like supply that depletes when bubbles are created.

Finally, bubbles’ edges could maybe fluctuate to a rythm (kind of like a soundwave) to give a visual cue of the voice input the player just made.  This will prove useful for the next part…

A visual display of the voice input (I'll never be a drawing artist...)


Instead of coming from the player, ripples would be created by “emitters”, which would become the building blocks of the puzzles/levels.

These emitters could be activated by the bubbles once you drag one on them.  The actual nature of the ripples would be directly related to your bubbles.   We liked how this represented a message being heard, transformed and then thrown back into a “conversation”.

The bubble gets converted in a ripple

Emitters could also act as obstacles.  Let’s say you want to cross a part of a level, but there are ripples so strong that they actually stop you from going further.  What’s great about this idea is that we’d be able to sync these ripples with the music and sound effects, thus creating an audio environment that is fully intertwined with gameplay.

Example :

One situation, many solutions

This is a basic example.  The player must get to the right side of the screen, but ripples are blocking his way.  He can either :

1) Activate the bottom emitter so that its ripples negates the top one’s.  However, in order to do so, he’ll have to match the pattern (by making a specific kind of bubble)

2) Make a thick bubble that will block the ripples temporarily, thus letting the player get across.

So that is what our two main mechanics would look like!  We’ll dig deeper into those in the next few days, so if you have ideas, don’t hesitate to share them!


We thought that our game should be a joyful one, so we would like to know if you like the following themes : drowning, death, limbo…ok, so maybe not joyful, after all…

Actually, we thought that the game could happen in the in-between moment that exists while you’re dying.  This “hallucination” moment paves the way to abstract representations and lets us establish different moods, just as if life was flashing before the player’s eyes.

Each level would then become a way for the player/character to solve an issue of his past.  Of course, this would only be hinted at, as we don’t want any actual backstory.  But I think everybody can relate to the fact that before dying, we must come at peace with our past.   This could have an impact on gameplay, as the “goal” of each level would be to get rid of a dissonant element (visual or musical) to make everything harmonious before we leave this world.  And in the end, when everything is over…silence.

Design reunion summary

Monday, October 17th, 2011

***I’m copying the e-mail on the blog.  It’ll be easier to comment!  I also included the sketches I talked about (I know, probably not worth the wait 😛 )***

Hi guys!

Ian, Saleem and I met this afternoon to talk about basic game mechanics.  We came up with a few ideas that we think fit well within the project, so here is a recap.


We briefly touched the subject and, because water seemed so popular Tuesday, we agreed that the game should probably take place in an abstract representation of the underwater world.  The main song will be The Little Mermaid’s “Under the Sea”!…ok, that’s just my fantasy.


Like it was mentioned at the first meeting, a constant vocal input to move the player around would get annoying pretty fast.  So we established that it would probably be better to let the player control his avatar via the touchscreen.  We think a tap’n move dynamic, where the character goes where the last touch was registered,  would be adequate and straightfoward, but it’s still up in the air.


We were wondering if the game should use a side-scroller view or a top-down perspective.  Side-scrolling would be great, but we want to make sure that our game doesn’t get compared to much to Aquaria, which also happen to take place underwater.  This question is still up in the air, so we would love to know what you think about that.


The first control scheme we came up with revolves around the idea of ripples.  Like sound, ripples are waves that spread out all around its emitter.  We think it would be a great visual representation of the player’s input, almost to a 1 : 1 basis.  It is very immediate and related to what the player is physically doing.  On top of that, it gives us a lot of room to make some interesting level design.

Different sound inputs, different ripples

The player would be able to reach his goals by using the different kinds of ripples he can make.  Those may move objects out of the way, break obstacles, etc…However, some kinds of ripples will be more appropriate against certain situations, which is where the player will think, to reflect on how to modulate his voice.  This will be where the fun begins!

Use ripples to get objects out of the way

Stronger ripples could break glass, as weaker ones could not


Another great thing is that the sounds and music of the game could have an impact on gameplay if they also lead to the creation of ripples that may hinder the player’s progress.

Colliding ripples could have their effects be negated


The second possibility would be to use bubbles as the main action device.  With vocal input, the player would create a bubble with certain properties.

Different sounds, different bubbles

Then, by dragging the bubble around, he would accomplish actions that would let him progress.  Some bubbles would be thicker, but harder to move around, or others could be thinner, but would pass through slits or whatever.  In a way, the action happens in two steps : bubble creation, which is solely vocal, and bubble manipulation, which is solely tactile.

Vocal input to tactile input

A lot of design possibilities

As with Ripples, environment sounds could also be represented by such bubbles and have a great impact on gameplay.  In a way, in both cases, the gameplay interaction becomes the meeting space of the player’s vocal inputs and the game’s outputs.


Finally, we thought about giving players the ability to directly manipulate the environment.  His voice would have different kinds of influence on objects, depending on what these objects are.  This would let us design a lot more of gameplay interactions using voice and, possibly, gesture or tactile input, as the focus shifts from the player to the environment.  It also keeps the aspect of novelty throughout the game, because the player will keep exploring and discovering new causes and consequences as he play. The fact that one kind of input, like volume, would have an impact on two objects at the same time would create a nice interdependance that would be great for puzzle design.  Possibilities are endless…maybe too endless. This may be quite a handful to program, as every kind of object will have a unique behavior.

Every kind of object reacts differently to voice


Like we discussed at the first meeting, the game would have and overworld, through which the player would have access to the different levels.

What we thought was that at the end of each level, the player could receive a new “tool” that would let him 1) do some awesome circuit-bending with either music or voice samples 2) progress in the Overworld by, like Ian put it, “tuning his own voice”.

This gives kind of a meaningful purpose to the game.  The player must use his voice to complete the levels, but that’s not enough.  He has to “tune it” to get understood and progress.  This seems like a very strong, though abstract, theme / narrative that really ties together neatly the voice input and the gameplay mechanics.


So  that’s pretty much it!  Please feel free to comment on any mechanic, as it will only get better with everyone’s input.