GameLoop Quick Start Guide
Extension
ExtensionThis guide is created as a step by step intro to the main features of the GameLoop library.
- Install the VectorSpace and MathLib Quarks. Evaluate the following to install (note that Quarks need SVN to be installed):
- Get the latest SuperCollider Plugins: http://sourceforge.net/projects/sc3-plugins/files/ The Plugins include the required MoogVCF UGen as well as the Ambisonic Toolkit.
These are the resources you need to run the examples. For a full list of resources and instructions see the first note at GameLoop_Overview.
Basics
We will start simple so be patient until we reach the interesting sounding part. We will need a decoder for the sound output.You can choose from a selection of different decoders but for now let's use the simple stereo decoder from the AmbIEM Quark:
Now we need to create the environment for our sounds to live in. Let's assign it to the environment variable ~gameloop:
Now we will add a unit to our environment. A unit is a convenience class that is comprised of an entity and one or more representations. For now we are not going to worry about the particulars. It's enough to know that the SVUnit stands for "Sound and Visual Unit" and that it creates for us an entity, a sound representation and a visual representation. At the most basic level an entity has a radius that describes its size and a position in space.
Not very exciting but it is a start. Since we did not specify any input we can hear the default Impulse based sound (we are at the center of the space). Since the space is 40 x 40 the center is (20,20). The sound appears 2 metres left and 2 metres forward. Notice that we had to pass the environment(~gameloop) to the SVUnit so that it knows where to add itself. Also notice the number of representations on the visualisation counter. To remove the entity:
Motion and Interaction
Still working with the default sound let's make it move around.
The maxSpeed argument limits the maximum speed of the sound. The motion of the SVUnit is defined by calling the .force_ method on its contained entity. The method expects a function that is passed the entity. In this case that force is calculated by the Arrive Steering behavior. This behavior moves the entity from one place to the other, in this case from the starting position (18,22) to (20, 20.5).
We can change the target position of Arrive on the fly. Evaluate this a few time to move the entity to random points.
We are going to have a look at the rest of the Steering behaviors a bit later. For now let's see how the entities can interact with each other. By default entities do not interact but this can be changed by setting their collisionType to \static or \mobile (the default is \free). \mobile entities interact with every other entity while \static entities only interact with \mobile ones. This distinction is useful for saving processing power by avoiding unneeded collision checks.
Let's make two of our default sounding units collide.
Although we can see the visual feedback of the collision nothing happens in terms of sound. The reason is that if we want a result from a collision we also have to define the collisionFunc argument of the entities contained in our SVUnits. Here is a simple example.
The collisionFunc argument is passed a function that expects two arguments: 1) the entity itself 2) a list of the objects that our entity is colliding with. In the above example we simply removed all the units involved in the collision.
Custom Inputs
GameLoop is using JitLib NodeProxies. The input of a SVUnit is defined in the input argument. The argument expects a function that is passed the current speed as an argument. This is very important as it allows us to shape the sound accordingly. As we've already seen if nothing is provided the input defaults to 'Jack the Mosquito' but let's try as an input a slightly modified example from PlayBuf's help file.
Navigating the Environment
We can move around the virtual space by adding a camera.
Focus the viusalisation window by clicking on it and use the left/right arrows to rotate and front/back to move forward and backwards. You can click the add Fence button in the GUI to get a better sense of the boundaries of the space.
Remove the camera.
More on Steering Behaviors
Let's now have a look at the rest of the available steering behaviors. I am going to provide a brief demonstration. For details about individual paramateres refer to the help files for each behavior.
A very useful steering behavior is the PathFollowing steering behavior. With it we can define a path for our unit to follow. You can think of it as a kind of automation but instead of defining exact movement you are guiding the sound towards a path which it follows based on its internal characteristics (maxSpeed, mass etc).
Notice how the unit stops at the last location. The path takes a second argument that allows us to close the path into a loop. By default it is set to false but let's change it to see what happens.
We can change the loop on the fly. Let's define a random one with the loop parameter set to true.
The Steering behavior Seek works in the same way as Arrive but does not deccelarate when reaching its destination. This makes sense when our unit is chasing something.
Let's now change the seek value. Notice how the unit moves aroung the spot instead of stopping at it.
Another useful steering behavior is Wander that allows us to send our unit in a random but natural looking walk. Before we start though let's make our unit a bit slower to have a chance to observe it before it wanders out of the screen.
And here is the example:
Bear in mind that steering behaviors can be combined. At the moment a very simple implementation has been realised with the .sum method of ForceManager. In the future I am hoping to add some more advanced methods for combining steering behaviors1 .