Basically, as far as tech development goes, this previous week marks a pretty noticeable leap forward. Along with two additional Micro Games, I also spent a lot of time researching mobile limitations and resolving minute issues as they appeared. Now, not only do we have a larger collection of basic games to display during presentations and testing, but the continuing creation of Micro Games should be even more streamlined with universal systems in place for scrolling and swiping.
iPhone Restraints While I did not expect to encounter frame drops this early in the project, it's probably better that I acknowledge these problems early when the possible causes are scarce. As it turns out, maneuvering multiple display objects over the stage will cause slight frame drops on various devices. This is more noticeable with older phones, but slightly noticeable with more modern devices.
Since these games involve simply mechanics and snapshots, the actual presence of these drops alone is not particularly noticeable to a player. They also can only be reviewed if the player is constantly interacting and moving large display objects on the screen, which human visibility is unable to accurately acknowledge any frame issues unless aware prior to the events. So, overall, the actual appearance of frame concerns is not only isolated within each Micro Game, but it's also difficult to detect unless you're the one developing it and providing stress tests on various devices.
Still, resolving these issues wherever possible still remains a priority. Particularly in the UpVote game, I was able to essentially remove all frame issues by condensing all the display objects into one bitmap, therefore limiting the amount of items being re-rendered on the screen during scrolling. This, along with limiting the amount of transparent filter images on the screen at any given time within the Filter game further resolved frame concerns for these Micro Games. Progressing forward I'll just need to continue examining the frame rate for each game added onto the system.
The UpVote game definitely took a lot of time to develop, primarily because of the fact that it needed to decent way of providing all of the 'upvotable' pieces in front of the user. After designing its structure for a bit, I began writing a file system that would be able to organize posts based on xml parameters. Each post has a poster, poster statement, and any number of comments. Comments contain comment names and commenter statements. Any of the objects, post or comments, can be upvoted. After writing a rather silly list of posts with characters, I also needed to tack on a list containing the possible names to randomly choose.
At the start of each game, the application acquires the list of posts and transfers references to a new vector. That vector is then shuffled, and reduced to the amount of posts required to display. From there, the application acquires a list of all possible names within the displayed posts, therefore randomly choosing a possible name for the user to find and upvote their posts or comments. This creates gameplay that will always be able to randomize the displayed posts, the order of the posts, and the names to search.
The mechanic itself is very simple, but a lot of time was spent developing the scroll mechanic. First, all the items needed to move up or down via scrolling, stopping at their ends. Second, a realistic slide needed to be implemented. This means that, after scrolling in any direction, the list would continue moving, utilizing a list of averaged speeds to continue, eventually slowing down to a stop. This is a common feature on most mobile devices.
After an extensive amount of developing and testing, as well as a conversion to bitmaps to prevent frame issues, the overall gameplay was present. Adding into the ability to tap on items to upvote was relatively simple, having already constructed the boxes for each post. In order to improve collisions, I added a bit of circular collision around each tap, allowing applications to utilize a encompassing circle of any size around the tap point, therefore increasing the area considered when tapped.
This was another game that I expected to take a short time to develop, but was also hindered by swiping. After converting scrolling to a better process handled by the Input class, I also added swiping, representing the horizontal interaction component.
This alone was not an issue, but I realized that, when moving between filters on the screen, I needed to create a more realistic transition that would take the swiping process to a more advanced stage. While this went through various iterations of improvements, it will be best to primarily discuss the final implementation.
Basically each image is swiped left or right, and upon reaching a far enough location, they are automatically pushed to the side and the next image transitions in. This is simply done by having all images move along with the others. Upon reaching a transition point, an animation takes over that moves all images into their appropriate spots before giving swipe control back to the user. This prevents the user from swiping too fast. Depending on which direction the user swipes, images are transferred from the front to the back or vice versa, therefore allowing them to continue swiping continuously in any direction.
There are a lot of little pieces that have been brought up regarding development, so primarily next week I'll be examining them and choosing a few aspects to prioritize for the next sprint. The game currently completely shuts down on exit, which should possibly pause gameplay instead. The game also views different on various iPhones, which will need some discussion to decide how to relate development for all smartphone devices. The game will also need a developer build to allow the selection of games for testing. Transferring the current project to Starling could also improve rendering procedures. And, additional games will still be important to continue expanding the testing pool, particularly games that utilize vibration, dragging, or movement.
Obviously, this is a lot, so I'll probably narrow it down more as I plan the sprint out a bit more. While I may quickly research everything, I'll definitely be developing at least one more Micro Game. Along with that, I intend to create a developer version, and potentially focus on utilizing a new phone mechanic.