Archive for the ‘Programming’ Category

Blocks

Thursday, January 26th, 2012

 

 

I drew a visual depiction of how the blocks should function, and their emergent properties. 

 

 

 

Solidifying the Already Solid Game Mechanics

Friday, November 4th, 2011

In the previous post, Saleem showed an example of our most aesthetically pleasing puzzle so far. So, me not being able to get out of focus on one thing, and since the programming team seem to have not correctly implemented ripples as we need them yet, I took the liberty of implementing the code I wrote a couple posts back.

So here’s a similar design from the previous post (please ignore YouTube’s crap at the beginning):

http://www.youtube.com/watch?v=ZlOCh_WL1Jo

The white marks places where the force of the ripple “field” is strongest (well, it’s really the magnitude of the velocity vector). This video doesn’t show direction of the force. I inspected the field by replaying the simulation only showing the velocity in given directions, and the parts marked green seem to be reachable (provided the outer 4 emitters are directed like cones). However, it is hard for others to visualize until color is implemented.

Ethereal Ripples

Thursday, October 27th, 2011

EDIT: I fixed a couple things. Notably, I added the constant MAX_AMP, so that the stored amplitude is always positive. This prevents the loss of information and saves memory. When retrieving the amplitude from the map(x,y), we can just take the length of the vector and subtract the MAX_AMP.

I wrote a short technical document about how to implement ripples.

I’M GLARING AT YOU PROGRAMMERS!

I’ll read it over tomorrow when I’m not starving to catch any mistakes.

NOTE: Yes, I know that the ripple source doesn’t go on forever and remains the same amplitude (never decays). This is to remain consistent with the rules we need the ripples to follow, but is not physically accurate.

How to make a bubble in ten days…hum, minutes

Thursday, October 27th, 2011

Hey,

I made a script to create bubbles in Unity.  This is actually my first script ever, so please be merciful! 😉

Just drag the script on any Sphere (or any object, for the matter), and it will do what is does.  I didn’t figure out yet how to change the bubble’s thickness and make it visible, so I used a color code.  Just shift between red (thinner) and blue (thicker) by pressing Alt or Command (or vice-versa).  Use space to make the bubble grow.

This is just for early prototyping and some of the bubble’s functionalites are still absent.  Of course, the main issue will be to incorporate voice, but its actual components are already there (duration = pressing spacebar, pitch = thickness, volume = growthSpeed)

If you want to play with the bubbles, you can drag the Rigid Body and Drag Rigibody components on top of it, but don’t forget tu uncheck Use gravity.

You’ll also see that I’ve started coding the bubble’s reaction with its environment, in this case, a wall, so you can add a wall to the scene and give it a WallProperties script including a pop boleean variable to make your bubble explode!

Anyway, I would love to see what the real programmers think of this!

PS : sorry for the messy indentation, WordPress doesn’t seem to like code-pasting…

var growthSpeed : float = 0.1;

var lifespan : float = 5;
var lifespanSpeed : float = 0.1;
var maxSize : float = 10;
var thickness : Material;
private var grow : float = 1;
private var canGrow : boolean = true;
private var created : boolean = false;

function Start () {

thickness = renderer.material;
thickness.SetColor(“_Color”,Color.red);
}

function Update () {

if(thickness.color == Color.blue);
maxSize = 6;

if(Input.GetButton(“Jump”) && canGrow) {
transform.localScale=Vector3(grow, grow, grow);
grow+=growthSpeed;
lifespan-=lifespanSpeed;
}

if(Input.GetButtonUp(“Jump”) && canGrow){
created=true;
canGrow=false;
}

if(Input.GetButtonDown(“Fire1”) && canGrow)
thickness.SetColor(“_Color”,Color.red);

if(Input.GetButtonDown(“Fire2”) && canGrow)
thickness.SetColor(“_Color”,Color.blue);

if(created)
lifespan-=Time.deltaTime;

if(grow>=maxSize || lifespan<=0)
Destroy(gameObject);
}

function OnCollisionEnter(collision : Collision){
if(!collision.gameObject.GetComponent(WallProperties))
return;
var wall = collision.gameObject.GetComponent(WallProperties);

                 if (wall.pop)
Destroy(gameObject);
}

The Shallow Water Equations

Wednesday, October 26th, 2011

I believe that we need to use the Shallow Water Equations to simulate the ripples on a 2d plane. The height map generated would then be rendered based on extremes, for instance, only heights after a certain cutoff would be rendered, to generate the “sonic wave” effect yet provide the organic visual and interaction we are hoping for. I’m trying to find an algorithm that does the simulation and isn’t coded in MatLab or some obscure oceanic simulation software. Stéphanie also mentioned that she would contact the TML for help, since Michael is busy. – Ian

GPU Water Simulation (using SWE)

2D Fluid Simulation in C (needs to be extended to extract heightmap and add gravity)

 

Simulating Ripples in Unity

Monday, October 24th, 2011

The obvious technical problem with our design is how to implement ripples.

Luckily, I did some searching and found this. I am not near my MacBook so I have not had a chance to mess with the code, but we can do so tomorrow. The good news is, benbritten’s code provides a great starting point.

For this game, the cancel effect of capillary waves will have to be amplified with reduced accuracy. This is to give the player some leeway in skill, and prevent the game from becoming unfair, what with the inaccuracy of microphone input anyway.

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.

EMITTERS

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?)

AVATAR

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)***

 

 

Unity for dummies

Tuesday, October 18th, 2011

Hey!

Because we’re working with Unity, it would be great if everyone had at least a basic knowledge of what we’ll be dealing with!  I’ve been trying to learn Unity myself  for the past couple of weeks, so I gathered a few resources that I would like to share with you.

1) http://www.unity3dstudent.com/category/modules/

These tutorials are great and can be done within 2 or 3 hours.  You’ll learn the very high-level functions of Unity, but it is a great way to get familiar with the interface.

2) http://unity3d.com/support/documentation/ScriptReference/index.html

This if the official documentation for Unity and it can quickly become overwhelming, but I think going at least through the overview will be very helpful.  After that, straight to bookmarks, as it will be very useful when coming new integrated functions of which you don’t know all the possible parameters.

3) http://unity3d.com/support/resources/tutorials/penelope

It is a pretty extensive tutorial for an iPhone game.  I’m doing it right now and it is very enlightning, especially for when it comes to dealing with touches.

4) http://answers.unity3d.com/questions/index.html

This is a great resource, as most of the questions you’ll be asking yourself will already have an answer here (I think)

5) Other resources (I haven’t really dug into those, but I think I may do so in the near future)

http://www.3dbuzz.com/vbforum/sv_videonav.php?fid=808bf515c69066eb13df7952c0d54711

A lot of videos (736!), but they are well categorized to fit every need.  I have done 3D Buzz tutorials in the past and was always satisfied (no, they did not pay me to say that)

http://www.unifycommunity.com/wiki/index.php?title=Tutorials

Other tutorials, but they seem to be built around older versions of Unity.  Not sure if they still apply, but eh! at least we know they exist!

There are probably way more resources than that, but I think those cover most of the ground.