Crown Jewel
The one effect that I’ve neglected which I envisioned from the beginning was the actual filling animation of an individual wire in a cell. I should be able to do this now, since I now know how to use a Rectangle object to determine which portion of the sprite to draw. Filling just straight wires is not a problem, but it becomes more complex if a wire has bends or has intersections. This effect should be able to be achieved by first filling a small area from the origin side, then expanding outward in all three directions after the fill has moved passed the halfway point. This should be similar to how I expand the overlay on the piece cooldown, except it will expand in three directions after it reaches the halfway point.
I did go back and add the “coming from” variable to determine the flow direction. Also, I had to use the draw method which takes two Rectangle parameters, the source Rectangle and the destination Rectangle. Using only one Rectangle will make the sprite stretch, but with two Rectangles I was able to achieve the clipping effect. This clipping effect is what I needed to display the gradually filling wire in the cell. Using the default tile was a good way to test the clipping, since it fills the entire cell. This way I was able to determine exactly which regions are being clipped. After I got it working correctly, I replaced it with the real wire image. I’ll admit, I did hardcode the wire offset constant value and the halfway point constant. Technically, those values probably could have been derived from the cell size, but that would have made things way too complicated, with nothing to show for it. Additionally, I removed the dark yellow color of the filling wire, since it now has the visual animation of it filling. The wires now truly look like they are continually filling, but unfortunately I can’t capture that in a screenshot, so this development image and these handwritten notes (click to enlarge) will have to do for now.
Scrolling Background
Looked at some other puzzle games, and I noticed that most had scrolling for animated backgrounds. I thought this would be distracting at first, but I guess if the scrolling is slow enough it isn’t so bad. Plus, it makes the screen seem more “alive”.
However when I implemented this, the background jumped from the game level screen to the game win screen, since the game win screen didn’t have the scroll offset value. I made a few methods to allow the background scroll offset to be passed to the game win screen, and then back to the game level screen. I didn’t have the offset value changing in the update method in game win screen, which made the scrolling stop on the game win screen. I thought that this was okay, because there is already a lot going on with the rank values displaying. The offset is passed back to the game level screen, which is a new instance of the object. That is another issue that I may need to address later, if memory or performance becomes a factor. When the game transitions from the game win screen back to the game level screen, it picks up at the same scroll value, so there doesn’t appear to be any jumping in the background scroll animation.
Overall, this gives a feeling of continuity between all of the stages in a level. Then there is a visible shift (scrolling in the opposite direction) once the user moves on to the next level (completes stage N-10).