Most of the development for this sprint occurred toward the end of the iteration, simply because I was somewhat busy for most of the week. Following this week is break, but I figured I'd allow some of the work flow into the early parts of the break to further as much development on the Micro-Games. This should allow a bunch more game to be tested and have their corresponding art assets implemented within the next few weeks.
Overall, the game logic for Ripe or Rotten is very simple. The player is given a stack of profiles and must swipe them in the correct direction. Once art assets are available, these profiles will be based on whether the vegetable character in question is 'ripe' or 'rotten'. Ripe vegetables are swiped right, while rotten vegetables are swiped to the left. The player must correctly swipe X amount of profiles within the time limit, while also ensuring not to categorize any of them incorrectly.
The most difficult component of the Micro-Game was designing the actual profile visualization. Each profile, in order to be convincing, also requires some parody details concerning the vegetables name, age, and description. Furthermore, due to how quickly the player can process information, a large number of profiles is required. While writing the various descriptions for the profiles took a bit, it may take even longer to generate profile images for all of the vegetables. This will be needed to ensure that the player does not view all of the profiles within the first few games. At the current moment, this may require around 24 unique profiles. The descriptions at the current moment will also need revision through testing.
The actual logic is somewhat based on Find the Filter, enabling a similar method of swiping the images. However, instead of having all images slide onto the screen, profiles are stacked on top of each other, and the player essentially just flings them off of the stack. This mechanic was actually a bit easier to implement, but also required some additional rendering checks to only display the top few profiles to prevent any performance problems.
While mostly in a prototype form, the Micro-Game was implemented as a very simple horizontal 'runner' that would make further use of the landscape perspective. The player controllers a ship moving through space. Obstacles approach on the right, and the player can tap any part of the screen to move vertically to that location. Regardless of where the player taps, the ship is bound to its X position, and simply lerps to the Y position. The user can make individual tap commands, or they can hold their input down to constantly move the ship.
Most of the development in this area revolved around creating the simple AI to generate asteroids. Aside from setting out some asteroids at the start of the game, every few moments another group of asteroids is created off-screen. Each spawn has a chance of creating 1-3 asteroids, each taking up different lanes. Since there are four lanes, there will always be a navigation area for the player to move through.
At the current time, all the player must do is avoid the asteroids for the set duration. There may be potentially to advance some of the gameplay, but given the Micro-Game format, it should not become too much more complex. If anything, the speed at which asteroids move could be varied over time to curve the difficulty.
Move the Ball isn't actually a new Micro-Game, but one of the developed Micro-Games that was put on hold for a while due to its dependency on the tilt functionality on the mobile device. Originally, the accelerometer was not responsive enough for the gameplay, so it was temporarily scrapped. Given the potential for tilt functionality in other Micro-Games, I decided that it was worth revisiting for a bit to examine alternative solutions to some of the issues encountered.
After researching and implementing the gyroscope functionality, I was eventually able to improve the movement of the ball within the game. Now, the movement is much more responsive, and there are far less bugs or unpredictable location adjustments.
The only issue remaining relates to the definition of the gyroscope functionality in comparison to user expectation. Essentially the data provided is based on the change of tilt. This means that if the player were to hold the mobile device still for a while, the change would result as 0 for X, Y, and Z rotations. This is only an issue since it also means that the user could be holding the mobile device at an awkward rotation, and then struggle for a moment to properly move the ball.
Basically the data normalizes after a while, requiring the player to understand the need to acknowledge the mobile devices base axis, and then tilt from that basis. Over time, another basis will be taken, and the user must continue tilting based on the new medium. Most of this is apparent in many apps, but it may take a bit of tuning to teach the user how the tilt functionality is handled by the device.
With three new Micro-Games implemented, we're about halfway to the eventual goal of thirty Micro-Games. Ideally, if we can output at least five each week, we should be able to meet our goal within the next three or four sprint cycles. In order to do so, the next pack of Micro-Games will need to be developed with detailed designs to allow the programmers to focus a bit more on implementation, and also limit the amount of changes required following QA tests.