I decided to look into Beads for audio generation within Processing. From the early stages of prototyping my seeking particle system (shown below), I found that I craved some sort of sound-representation of the particle motion onscreen; rather than designing sound first and then adding visuals, I decided I would generate audio based on visuals. I had the initial idea that I could use Beads to generate individual sine waves (and a series of harmonics) for each particle onscreen, and map the frequency of the sine wave to be based on the position of the particle from left to right. This ended up being less musical than I was hoping. Lots of different frequencies generated together sounds like wind or surf (and synthesizers use noise generators to accomplish the synthesis of these sounds). I was hoping for something a bit more musical, and I was hoping to be able to distinguish pure notes. I brainstormed a bit and then realized if I divided the screen up into sections, I could form a musical keyboard over the screen, and if I tweaked the harmonic relationships of the sections, I would be able to generate harmonies between the particles, even if they were far apart. This ended up working better than I expected! I began at this point to tweak what I had in order to obtain a game feel I was happier with. I was also playtesting from the perspective of wanting it to be a viable instrument… An instrument you could play with and get lost in, or that someone might want to sample from.
The game went through two main phases of development i guess you could say. The entire process started with the idea of avoidance being the main aspect of the game rather than collision. The first iteration was with some simple boids that roamed the screen freely and were repelled by the mouse or by the other circles roaming the screen. The problems we ran into with this was that it only looked great if there were an absurd amount of triangles on screen. far more than a tablet could handle. So we started coming up with ideas and eventually stumbled upon the boids tending toward each other. This turned out to be the biggest help to the project because it lessened the amount of triangles needed but still made it possible to experience the satisfying scatter effect. From this point on the main changes to the game were simple tweaks. We changed the way the mouse worked to be more conducive to tablets by having the mouse only trigger when pressing. We also added a trail effect to when it was repelling to give both a visual idea of what was happening as well as a nice way to keep track of your movement. Some simple color scheme variations was how we finished off the project.
Although Space Journey is certainly a fun game to play, its primary purpose is not to encourage players to win or lose — rather, it is to simulate an interactive system, in which nearly every member has a positive or negative effect on other members of the system. As Shiyuan pointed out in her post, this particular game took heavy inspiration from the aquatic system described in chapter 3 of our textbook. But, rather than stick to Earthly concerns, we took our game into space! As the primary method of interaction we were working with was the speeding up and slowing down of objects, it only seemed natural to create a ‘black hole’ that would bend gravity and slow down the oncoming vehicles. We also created a sci-fi-esque ‘white hole’ that has the opposite effect — all objects that approach it speed up. Both ‘holes’ slowly move around the screen, adding additional interest for the player. From there, a deep navy background successfully creates the feeling of being in outer space. The player controls the yellow circle, and is pursued by an orange space-ship-like vehicle. In turn, the orange vehicle is chased by a blue triangle, followed by a trail of smaller blue circles. Each time the orange ship collides with the player, a futuristic sound plays, and some ripples emerge on impact. Each time the orange ship gets the player, it increases in size, until it can become almost impossible to avoid. Conversely, each time the blue triangle successfully catches the orange ship, it decreases the size of the ship, and it can become quite easy to avoid. This returns the game to the idea of an ‘eco-system’ of interaction, in which the player must deal with multiple environmental variables.
For our group game, we decided to use the hider/seeker labs to make a game about running naked through people’s pools while getting chased by police. You score points by being in pools, and if you get caught, it’s over. We first made a little skin-tone dot to represent the player, and a vehicle chasing it. We wrote the code so that pools would appear in 3 random spots for the sake of variety. But we had trouble getting it to move how we wanted it to (automatically, steering towards the cursor/finger). We ended up with a player character that just teleports to wherever the mouse is clicked. That’s as far as it went for a while. To solve the movement problem, we just replaced the little player-dot with a second vehicle, in its own class, that chases the cursor while being chased by the enemy vehicle. Collision was still difficult to figure out. We thought that putting the player character in its own class would help, but it didn’t. We also still had no idea how to make the code detect when vehicles were in water, since the parameters/coordinates were randomized. And so there could be no score. Also, we made the colors awful. We changed the hideous color palette. We eliminated the player’s class. It’s now just Vehicles one and two — the peach-skinned arrow is the player, and the navy blue arrow is the police. We had to ditch the random pools idea because it made the next part super difficult: vehicle-in water detection, and vehicle slowdown while in water, which affects the enemy slightly more than the player. We’ve got a score-counter going as well. Collision between vehicles now ends the game, with a ‘Game Over’ message as the police escort you off the screen. We had a breakthrough — every mechanic works as it should.
Space Journey is a single-player game based on the hider/seeker concept. In this game, the player is controlling a yellow circle that can move anywhere in the screen. An orange triangle, the seeker, is chasing after the player. At the same time, the orange vehicle also has its own seeker—a blue triangle with a tail. When the orange vehicle successfully touch the player, two things will happen: the size of the vehicle will increase, and a ripple effect is produced. The ripple effect is accompanied by a sound intended to create a space, futuristic feeling. The effect itself is built based on an array of white rings that sets off and recycles according to the screen touch. When the orange vehicle is chased down by its seeker, counter effect will take place: its size will decrease until it is almost invisible. Besides the basic chasing mechanism, there are two environmental variations: two circles are doing clockwise and counterclockwise circular motions. When the player reaches the black zone, the orange chaser will slow down significantly. With the blue vehicle’s effect, its size will diminish very quickly.If the player reaches the white zone, the orange vehicle will immediately speed up, and accordingly it will enlarge quickly. The inspiration of the game come from the idea of dynalinking (Preece, chapter3). Within a pond ecosystem, perch, beetle, stickleback, and tadpole form a food web that each has its own prey, enemy, and also some irrelevant, mutual-existing members. In this game, I want to simulate this web so that not only the player is chased by a seeker, but the seeker itself is also being chased by something else. Similarly, there is no interaction between player and the blue vehicle, just like perch and tadpole in the ecosystem. For future improvement, I want to add several other environmental variations that can introduce new members and actions to the system. It does not have to be triggered by the player, like the black and white regions. The orange vehicle and the blue vehicle (and its tail) can be initiators, as well as subjects of new movements.
I’m really enjoying coding Inversion because each time I run the code, I feel the difference in play from the tweaking I do. Initially, I had the player (square) move around freely while the enemies (triangles) did the same. Then I had the enemies chase the player while the mouse was pressed. I thought I’d make barriers, and the objective would be to make enemies run into them and destroy themselves. I changed my mind. The enemies chase the player UNTIL the mouse is pressed, however, while the mouse is pressed, an obstacle rises from the bottom of the screen. Right now, I’m working on collision, as well as different positioning of the growing obstacle, perhaps coming from a different side of the screen. I’m also thinking about adding particles once I’ve coded the collisions.