This was a fun experiment. Most everything I set out to do is done. A few things didn’t work out, due to the fact that I dug myself into a design-hole early on and that I barely know how to work Processing at all. The things that didn’t work were mostly secondary to the core mechanics, except for the one that was to be a core mechanic. The game-ness of the game was fairly stunted as a result (I’ll get into that shortly). But the framework is still there, I’m happy with the colors and general design of the thing, and at risk of sounding cliched I’ve brought [most of] my idea to life. All by my lonely. That’s something to be proud of, I think.
I’ll start with what worked. Collision detection was a huge worry early on — “how do you explain to Processing how to recognize when a moving object is touching an object that’s both growing and moving?!”…..It also didn’t help that I’d decided for aesthetic purposes to position the circles halfway off either side of the screen. As it turned out, the answer was some fairly simple ‘if/then’ algebra, involving x-coordinates and radii and distances traveled, in relation to the width of the screen. Also, the only movement in the game is horizontal and every object is a circle, so that simplified things. When you tap the screen, a slightly-random-sized small circle (‘planet’) is generated just off the player’s side of the screen (the right side) at the y-coordinate of the tap. The planet flies left from behind the player-circle and when it touches the enemy circle, it pushes left by either 0.25 or 0.5, depending on which half of the random-planet-size spectrum it was constructed.
The player-growth mechanic was next on the itinerary, but that would depend on an array of ghosts, whose initialization would depend on the x-position(s) of the array of planets. I was unable to figure out how one array could birth a second array, so in lieu of a ghost mechanic, I had to figure out another way of making the player-circle grow (and this is where it fell short of being an actual game). I attempted a couple of solutions. I tried drawing horizontal lines from (0,planetY) to the player’s side of the screen, and calculating the player’s growth based on the relation between that line’s y-coordinate and the player’s radius. But as the player’s radius changed, so did its relation to the placement of the lines. That threw the whole thing off, but it did look kind of neat and I’d like to try and re-implement it in the future.
My stopgap solution to the player-growth problem was this: If a planet with an even-numbered radius passes through a certain y-column, then the player grows by either ‘a little’ or ‘a little more’, depending on the size of the planet. This works well enough to skip the ghosts thing entirely and just demonstrate the concept, but the constant threat of ghosts was supposed to be a huge source of tension because your only means of fighting the ghosts is the thing that creates more ghosts. Ideally, the ghosts would fly crookedly or in varying patterns so that the player wouldn’t know where they would emerge from behind the enemy-circle or what kind of path they’d be moving on. If the only thing to throw planets at is as big or bigger than the screen, then the need for y-axis aiming of any kind is eliminated, and there is no real player choice.
Other problems:
- I’m still confused about the order in which Processing drew my objects, and why the color and line code from one object’s tab would find its way into the next one. The planets took on the stroke data from both larger circles (the first planet thrown is always player-blue and the rest are enemy-red), and changing the background color ended up only changing the color of the enemy-circle. This was frustrating but not huge.
- The inclusion of sound is as big a mystery to me now as it was when we started.
- No interface elements (Game Over screen, timer; though I do sort of like the way it just sits still when the game’s over)
- Planets stick around after they’re supposed to have moved offscreen or stopped being rendered entirely. I’m not sure why (in retrospect I probably shouldn’t 0have committed to such an array-heavy set of mechanics).
