Post-Mortem: AquaBlock

AquaBlock is a turn-based puzzle game designed for mobile devices. In the game you piece together blocks to create a finished puzzle cube. The player can spin and rotate the puzzle cube to find the correct orientation that the blocks need to be placed. As the player progresses through the puzzles, they discover different block types and unique ways in which they can be used.

3 THINGS THAT WENT RIGHT

1. Utilizing Last Project's Assets
   AquaBlock is my second mobile release, a follow-up to MechDog. Fortunately through good scripting on MechDog, I was able to carry over many scripts and managers to expedite certain parts of development. The benefit of making scripts that are universal and transferable between projects should not be underestimated.

2. Performance Testing from Day One
   A lesson that I learned from my last project was that performance testing needed to be practiced during all points in mobile development. Although it was a time-consuming practice, the constant testing helped create straight-forward decisions on which post-processing effects were viable and what quantity of in-game effects were acceptable.

3. Task Managing for a Solo Project
   It was very important to use a task manager to stay on track during production. Even with a team size of one, the task manager was used in keeping tasks organized, prioritized, and minimized in scope. By visualizing tasks in the manger, I was able view which tasks were causing bottlenecks and put them on the back burner.

3 THINGS THAT WENT WRONG

1. Puzzle Playtesting is Different
   In skill-based games like shooters and platformers, you can have the same playtester replay a section multiple times and still collect useful data every time. This isn't the case with knowledge-based games like puzzles because they are solvable. Once a playtester completes a puzzle, they can simply rely on their memory to complete it again. Unless iterations on the puzzle completely change it, a old playtester's feedback isn't as valuable as a new playtester's feedback.

2. Not Setting Clear Goals for Polish Phase
   While there was a healthy amount of concepting in the early stages of development, additional concepting would have still been useful for polish. There was no set vision for how the game would finally look. Towards the end, it felt like a grab-bag of UX and FX ideas were being thrown at the game to see what would stick. Reinforcing the game's vision would have resulted in a more efficient polish phase.

3. No Competitive Research
   Because the puzzle genre was an unpracticed genre for me, I should have at least tried to benefit by having complete knowledge of the subject. Many of the design/UX problems faced during production could have been more fluidly solved by analyzing other puzzle games for possible solutions.

OUTCOME

Working on AquaBlock has taught me a few things.

1. Apply different types of playtesting for different game genres

2. Schedule more concepting breaks to refine and polish the game's vision

3. Look towards games of the same genre when suffering "Designer's Block"

4. Keep static scripts well-documented so they can be plugged into future projects

Post-Mortem: MechDog

MechDog is an endless runner created for mobile devices. In the game you control a dog in a mechanical suit who is racing across the desert. I collaborated on artwork with @stupaah, but everything design and scripting related was done by me. MechDog is also my first mobile release (I've only prototyped things in mobile before) so there were a lot of lessons and pitfalls during development.

3 Things that Went Right

1. Keeping an Updated Dev Blog
   The dev blog for MechDog was first started to share development progress and demonstrate design knowledge on my portfolio. An unexpected benefit from running the dev blog was that it provided a chance to reflect on design decisions. I was able to take a perspective that wasn't a developer's perspective by trying to write for a non-developer audience. Many game creators warn of the fallacies in trying to provided useful feedback when you become so entrenched in development; the dev blog provided a good way to take a unattached look at my own game.
2. Going for 3D Lighting
   The 3D lighting definitely adds something unique to the visual style of MechDog. I used the small scope of the game to my advantage and tried out this new visual looks that combines 2D assets with 3D tech. Although it took a lot more time and effort than I'd like to admit, the 3D lighting adds depth to the look of the game that I can't now imagine the game without.
3. Middleware service Integration
   There was a bit of hesitation on implementing middleware. The hassle of having to work with live 3rd party services was new and intimidating. Looking back on it now, it was a silly trepidation to have. Using Google Play Services was an easy way to have multiplayer features and including Unity Ads enabled me to create an interesting feature for the in-game shop. Adding new middleware features were low-risk and high-reward. 

3 Things that Went Wrong

1. Skipping Visual Concepting
   I foolishly made the choice to forego any visual concepting during pre-production. Between designing and developing, I left the art style of the game to come together during development. Unfortunately, the cobbled together art style is present in the game.There are many mismatching visual elements that hurt the game's presentation. Creating a visual concept for how I wanted the game to look at the start would have gone a long way to make the game's visuals feel cohesive. 
2. Ignoring Technical Limitations
   MechDog was a project that definitely went past its set deadline. A large chunk of time was lost to reverting visuals effects to try and save performance. It was in the middle of development when I learned that perf tests on mobile are different than on PC. Feature additions/changes that are innocuous on PC performance can cause unexpected hits on mobile. Adding frequent perf tests to my schedule from the start of development would have probably saved me dev time in the long run.
3. Underestimating Content Costs
   MechDog provided me the opportunity to really get into systems design (most notably the procedural level generator).Unfortunately, the time and effort I spent on systems design didn't factor in the associated content design. Game content is essentially fuel for a game system, and I made the mistake of only focusing on creating a good system. Procedural systems like the one in MechDog are great for stretching less content, but the game would have probably benefited from more enemy types and more upgrade options.

Outcome

Working on MechDog has taught me a few things.

1. Design new content at the same time as designing a new system
2. Keep an updated blog, it helps reflect on design decisions especially when working alone
3. Perform platform stress tests even if you are familiar with the engine
4. When working on mobile, plan for frequent performance tests rather than tabling them for the end 
5. Don't be afraid to give middleware features like Google Play Leaderboards a shot

Post-Mortem: Gravitos

Summary

The original goal of Gravitos was to create a short 5-10 minute experience for a general market of teens and up. Since then Gravitos has changed a lot (its target market, its accessibility, and much more). Mistakes were made on the project, with some being corrected during development and some which will have to serve as lessons for the future.
My personal goal for the project was to create a game that looked simple upfront but that contained underlying depth. Unexpectedly, getting the game to be complex was the simple part. Diluting down the mechanics into easy-to-learn ideas took the most effort on the project.

3 Things that went Right

1. Updated Development Builds at the End of Everyday
   The team made it a goal to have a unified build of the game at the end of the everyday. The intention was to make make sure the team had an updated build of the game to work off of at the start of each work day; this was most important when team members worked on the same assets. This daily practice proved effective in keeping development assets organized.

2. Building Modularly
   After a concept pitch session with industry mentors, the team was encouraged to scope down the game to fit our remaining production time. The cast of enemies in the game was condensed down and the core mechanics of the game were simplified. These changes and many others made to the design were easy to implement because the team was able to remove modules as needed.

3. Design/Art/Script Falling Under One Person's Responsibility
   From the get-go, the team aspired to make sure that every member of the team had a share in each pillar of Gravitos’ development. This deep-rooted involvement in the game, meant that each team member specialized in a certain feature of the game. This also gave each team-member experience with each pillar needed in game development.

3 Things that went Wrong

1. Forgetting about User Feedback and Aid in Pre-Pro
   At the start of the development, Gravitos did not have a goal for accessibility. The team naively thought that users would instinctively understand how to play Gravitos without any aid. During development, mentors convinced the team to make changes that would make the game more accessible. These unplanned additions replaced a large chunk of the work schedule that was previously dedicated to implementing wishlist items.

2. Not Stress-Testing the Engine
   When it came time to build the game’s levels, low framerates, collision errors, and other technical issues hindered level development. Out of the originally planned four levels, two had to be cut because of time constraints.

3. Gravitos’ Feature Creep
   Features that were not originally detailed out in the design document found their way into the game. These added elements strengthened the design of the game, so this is more a fault of not having the foresight or experience to document these things during pre-production.

Outcome

Working on Gravitos has taught me a few things.

1. Having a unified workflow is a major contributor to success.

2. User accessibility is equally important as game complexity.

3. Know the limitations of the technology that you are working with.

4. Keep in mind the smaller design needs that are usually overshadowed by the larger features.

5. Great Design comes from constant communication.