This log is mainly meant as a means to detail many of the tasks I completed over the last few months, examining various steps of the project cycle and reflecting on individual achievements and hurdles.
At the start of the project cycle, I was relatively content with using any development tools desired. My main desire was to at least have a project idea that would be both interesting and within scope. Given the priority working through other classes, work, and job searches, the project would need to have inherent value in order for me to actively engage in creating content. Beyond that, not only is scope an overt risk, but I doubt I would find myself iterating successfully on a project that would require excessive time and stress to complete.
The first idea that was suggested was a Planetary Exploration game. This would have been developed in Unity and would require a large number of systems to properly convey gameplay. Given the ability to explore some amount of 3D Vector math and mission-based design, this was of interest for a short while. However, given the amount of work that would be required from all disciplines, it became apparent that this was far out of scope, and optimism was not the best approach.
We started to look at some other brainstorming sessions, which got us away from just focusing on the Planetary Exploration game. During this time, we managed to compress the game into a movement-based exploration experience. However, not only did this detract from the cataloguing component, but movement-based games are extremely difficult to make. The player needs to be able to easily traverse terrain, while also having enough guidance to mix freedom and direction. Therefore, ultimately, this game was also left behind in favor of continued brainstorming.
Somewhere along the brainstorming process, Lisa suggested the brief idea of the player experiences what it would be like to be a modern teenage girl browsing through her phone applications. Within a single meeting’s time, we managed to transform the idea into a more solid state. The user would be able to experience compressed iPhone interactions in a series of rapid Micro-Games. We listed out a number of popular apps that could be converted into Micro-Games and the possible mixture of parodies that could work well in the game’s context.
Up to this point, I had been creating movement mechanics in Unity. Most of these mechanics were sound and worked properly, but they needed further direction to properly convey their use in the environments. Now, given the fact that the iPhone Simulator would be 2D, I briefly explored some potential options and decided on creating the game in ActionScript. This was mainly due to the accessibility of Flash tools, the ability to deploy from FlashDevelop, and the further option of testing gameplay remotely through SWFs.
Flash is typically not my go-to in terms of developing, but it made the most sense for this project. Given the containment of the Micro-Games, this would allow for fast development and shipment of prototype games to bring to QA. Furthermore, at the Emergent Media Center during the previous months, I had also developed some content in Flash, and therefore had created some tools to streamline the development process.
Early on in creating the iPhone Simulator, I focused on creating systems that would work for a long-term project. Creating separate Micro-Games for some of our ideas would have been easy, but I instead tackled the notion of ensuring that all Micro-Games shared the same foundation. I built a GameCycleHandler that would be able to run through the Micro-Games. This object essentially would own all of the Micro-Games, and would toggle between Icons, loading the Micro-Game, and exiting on an event calls. This would allow for further Micro-Games to easily be plugged into the system by simply adding them to the list. Once started, Micro-Games only need to send out an event call to declare a win or loss, and the GameCycleHandler will continue gameplay from that point.
ActionScript does have the ability to specifically handle touch interactions through events, but it also treats tap and mouse input the same. This not only is more efficient, but it also enables testing to act the same between the computer and iPhone. In this regard, I created a simple Input handler that would utilize tap locations and states to generate basic iPhone interactions.
While tapping is easily taken care of without much difficulty, scrolling and swiping require some additional development. The game would need to know two unique details to properly convey scroll and swiping. First, the Input system needs to know when these begin, since there is a difference between when the user just wants to tap the screen, and when they want to scroll or swipe. This can mostly be handled by only acknowledging a scroll or swipe if the user’s current tap-down is a greater distance than their initial tap-down.
For instance, if the user presses a button on the screen, the game will not register it as a scroll. However, if after they press the screen, they also move their finger downwards a few centimeters, the game will then understand that they are now scrolling. Once the game begins scrolling, it no longer waits for any tapping, but simply servers to update the scrolling logs. This applies in the same way to swiping.
The second part of the Input System is the trailing effect of scrolling and swiping. Given the details discussed beforehand, it is relatively simple to output a scroll amount depending on the difference between the current and previous positions of the tap-down, but iPhone scrolling does not work exactly in that manner. If you scroll downwards through a photo collection, then release, the scroll will continue to go and gradually lose momentum. This provides a very satisfying effect, and also allows the user to stop the momentum by tapping on the screen once more.
This provided to be a bit more of a challenge, and would require implementation of rolling averages for scrolling and swiping. Essentially each update of the scroll or swipe would also add the scroll amount to an ongoing vector. This vector would contain a limited amount of information, and when the limit is reached, the oldest value is dropped in favor of a recent addition. When the game pulls for the scroll amount, it doesn’t acquire the actual scroll amount from the last frame, but instead it averages the vector list and accesses the scroll amount from there. Once the user releases their tap-down, the vector continues to be updated, but the average retrieved is also added onto the list at a reduced amount. This means that over time the limited vector list will eventually undergo a gradual reduction until it stops scrolling. Beginning a new tap-down will also reset the vector list, therefore stopping the scroll or swipe.
Overall, creating the Micro-Games was a relatively simple process. Since each Micro-Game exists as its own contained game, it was easy to design the mechanics, implement a prototype version, and then further refactor and improve gameplay by tweaking various values. When designing each game, it was important to keep in mind the eventual require for difficulties and potential adjustments to limit the amount of time needed to return to developing the Micro-Game. This is evident with the Make the Pizza game, which required a lot of additional design work, but did not take long to adjust via code due to the fact that the systems were prepared for those types of changes.
Most of the time spent on developing games was devoted to improving the surrounding systems and developing the previously discussed Input handler. In many ways, I treated each unique Micro-Game as a means to properly implement a solution to the mechanics that could be used on future Micro-Games as well.
The only Micro-Game that proved a bit more difficult was the game surrounding the Accelerometer, which should not be too much on an issue going forward. At the time of development, I was primarily focusing on menu elements, but also began experimenting with the potentially for using iPhone movement as a mechanic. This is still feasible, but I would just need to devote a bit more time to building a proper system around it.
Ultimately, the menu component was pretty easy to add to gameplay. Using a State handler, each screen is easily contained in its own environment, and a single event call to the State handler enables any screen to move to any state. This decouples all of the menu screens and also allows programmers to quickly implement new content.
The Playlist screen took a bit more work, if only because it required a connection to the GameCycleHandler. Essentially, since the GameCycleHandler owns the games, it just needed a manner to send information to the instance in order to play one or more specific games. However, by allowing the GameCycleHandler to essentially turn on or off Micro-Games, this was also condensed down into a single event call to the GameCycleHandler, which would then return to the Playlist state after completion.
The game modes took a bit to develop the structure for, since they basically need to channel the GameCycleHandler in a manner that decouples the game rules from the gameplay. The GameCycleHandler only is concerned with flowing through the games, but it does report the status to the Gameplay state. Depending on the current game mode, sub-classes of the GameHUD can listen for the reports in order to determine the current progression through the game mode. From that point, they simply send out an event to change the state depending on whether the user has yet to win or lose the current game mode.
With most of the actual back-end content discussed, it is probably worthwhile to at least note some details concerning iPhone deployment. If done via a Mac, this can be completed using Xcode, which assists to streamline the certification and development process, as well as provide a tool for coding within the app structure. However, since I was utilizing Flash to create the game, this took a bit more work.
After paying the cost for the developer license, I essentially needed to work with several batch files while following a ReadMe to figure out how to manually generate the certification files. This process took a very lengthy amount of time to complete and debug, but once completed, allowed me to simply add the desired files to the project directory and deploy to the device. Going forward, I only need to worry about registering additional devices on the apple site, re-downloading a device file, and then replacing it within the directory once more.
FlashDevelop has a great process for debugging on the iPhone. First, I can simply rebuild the project and run the swf to test overall development pieces. This means that for the majority of the game creation, I can save time by just testing features out on the computer. When ready, I just need to have the device plug into the computer and hit the run button. If on debug mode, it tends to take a bit longer to install, but it does allow me to hit break-points and traces while utilizing the device. Otherwise, deploying on release basically enables us to create a fully-functional version of the game for the smartphones.
Early on, since I was also acting as the Producer on the project, I knew that we needed to push toward some of the stages if possible. This wasn’t because moving forward through stages was required, but because it would allow us to concentrate our development. Each stage offered a chance to meet deadlines, which would typically provide an incentive for production on the game. However, once we reached proving the vertical slice, there was not as much of a need for continuing to work on presentations, since polishing the game was more important.
By the time the Final Presentations were approaching, I actually reached a point were code development was not as crucial as polishing the current features. While I did continue improving and refactoring, additional implementations would not be able to have proper design tests, nor would they be able to obtain final art assets, so I mostly worked alongside the team on gathering the information and ideas for our presentation. So, for the final few weeks, we essentially held several work sessions to finish the art, tune some of the gameplay, and create our presentation format.
Heading forward, the next semester is definitely going to be a lot busier. With other courses, work, job interviews and tests, it will be important that I set weekly deadlines and continue to meet them. To assist, I will likely tackle some of the final over-arching features over the upcoming break, that way production can be spent focusing on creating new Micro-Games and tuning the systems already in place. Given the amount already available within the game, production will mostly be focused on working alongside the team to improve the gameplay and apply context and incentive for progression.