I spent most of my development time this week working on getting the cannon to work the way I want it to. As I was drawing up a sprite to use for the cannon I had the idea to make it look more like a mechanical arm. I like the idea of the arm acting as a sphere generation and containment unit that releases when the player taps.
In my post from the first week I listed three things I needed to do now that I had the bricks and balls interacting the way I wanted them.
- Auto oscillating cannon that changes color automatically.
- Ball vector based on cannon position.
- Ball color based on cannon color.
I spent about 12 (non-consecutive) hours writing a lot of really bad code trying to get those first two done. Eventually after learning something about SKActions and converting a radian angle value into a vector I came up with a simpler solution. I deleted all the unnecessary code I had written over three days and replaced it with one method and a handful of lines of code.
Because I was using a mechanical arm/containment device to hold on to the spheres before they shoot out into the playing field I decided that it wasn’t necessary for the cannon to change colors. The ball itself, sitting in the clutch of the mechanical arm, was enough to indicate to the player what color they were working with. To make the action of releasing and reloading the spheres more interesting I added a scaling action to the incoming sphere. Now when you shoot a ball, the next ball appears in the claw of the mechanical arm at a scale value of 0.1 and scales up to full size over the course of a half second. I find the effect visually satisfying.
I’ve thought of other little details I can add to this setup to make the game more squishy, like animating the claw when the spheres are released or animations for brick hits. I’d also like to add a color trail to the ball to help provide feedback to the user. Sometimes when the ball hits a brick close to the wall it actually contacts the wall first and changes color for a brief instant before it hits the brick. This can cause confusion sometimes because the color change is imperceptible and it can look like a red ball hit a red brick, but the brick didn’t break. I think the color trail behind the ball would help alleviate confusion there.
But for the coming week I think I should work on nailing down a scoring system and the basic structure of the software piece. I think I should at least add a home screen and a game over or level progression screen.
I have committed myself to attending the P.I.G. Squad (Portland Indie Game) art and code night this Monday the 25th. I hope to share what I have so far and get some feedback from the folks I meet there.