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: F-Gravity (Board Game)

F-Gravity was created for a tactical combat board game assignment. After being asked to clarify how F-Gravity met the genre requirements, I conducted a game analysis to prove F-Gravity was indeed a tactical combat game.

Introduction

When designing F-Gravity, I thought to create a small scale battle utilizing unconventional means of combat believing it would be one way of meeting the assignment's requirements. I opted to design a game that was simple in terms of having to calculate stats and dice rolls.

Features

In pursuit of a simple design, I designed a 1v1 scenario where small scale actions would be coupled with a larger purpose through the passage of turns and simulation.

• Players were given high movement rates (2 spaces was relatively high on a 8x4 board) to encourage traversal around the map.
• Players were also given multiple abilities (move, flip, portal) for which they had a limited amount of resources to use for (2 actions) to force tactical decisions. Both the movement rate and choice in abilities were intentionally designed/iterated upon to match the features that define tactical combat games

Unconventional Attack Methods

The mechanics utilized for attacking in F-Gravity are most likely the source of ambiguity when it comes to deciding whether the game is a tactical combat game or not. "Crates" in the game do not easily fit into any role found in a traditional tactical combat game. "Crates" serve the purpose of adding a layer to the level's architecture, impeding and redirecting player paths; but at the same time "Crates" also serve as a controllable force / long range weapon that can be shared by both players.

Through the use of a small action (portal, gravity flip), players cause a crate to move which will potentially eliminate the other player in future turns. I saw this as a way of causing players to weigh the value of the spaces they move to and/or the actions they take, which helps define F-Gravity as a tactical combat game.

Playtesting

From playtesting, it was clear that players were making tactical decisions every turn. Without thinking several steps ahead with each move, players would be easily defeated.
Playtesting also showed that iterations had to be made to the layout of the map.
Previous versions of the map featured many narrow passage ways, which gave player's fewer possibilities for tactical decisions to be made. After iterations, more of the board space was utilized, allowing more freedom of movement and also more opportunities for attack.

Conclusion

F-Gravity's primary gameplay is based on tactical decisions. The gameplay leaves little room for error and allows players to reap a victory for analyzing the field and employing the right tactics. And although obscured, "Crates" do act as a player's forces/weapons which further places F-Gravity in the tactical combat genre.

Post-Mortem: HookShot

HookShot is a top down racing game that lets players drive sci-fi cars that use powerful grappling cannons to sling around obstacle filled circuits. This project was my second freshman game created at Digipen and my first time as team artist.

3 Things that went Right

1. Scientific Research
   Hookshot was the first project I worked on that built off of real-world sports. Before and during pre-production I made it a personal goal to try and learn and become involved in motorsports for the benefit of the project. Learning the shared nuances of racing helped give a stable vision that aided the game’s design.
2. Lengthy Pre-Production
   HookShot is currently the team project that I spent the most time developing. As Acting Producer for the first few weeks of the project, I tried to learn from the mistakes made on my past project and set aside a large amount of time for pre-production. This assured the team would move into development with a solid design above all else, leaving nothing left to be haphazardly created in the final days of the project.   
3. A Lot of Testing
   The team made it a habit to conduct playtests twice a week. Constantly seeking out outside perspectives, helped keep the project motivated to design. The influx of opinions gave the design team much to work with for the duration of the project. The back-to-back playtests allowed game components to have their own compartmentalized test.

3 Things that went Wrong

1. Mixed Development Models
   The project went through many drastic changes throughout production. From engine changes, role swaps and design overhauls, there were many points in the project’s timeline that the project was in precarious position. A major change was the project’s unplanned transition from a waterfall to an agile model in the middle of production. Trying to incorporate frequent iterations without originally planning for them led to project conflicts and lack of team unity.   
2. Poor Pipeline for Playtest Feedback
   The team did a great deal of playtesting, but the decision to do so was made weeks after pre-production. The project lacked a pipeline to efficiently set up playtests and take in information from the playtests. The team needed to designate specific goals for every playtest. The team came into the habit of playtesting merely for the sake of playtesting; the idea to conduct weekly playtests was a good one, unfortunately there was no forethought or planning before acting upon the idea.
3. Crisis of Leadership
   The team lacked a definite leader from the start of development. Roles were assigned to each team member, but the responsibility of each position did not feel concrete. There was no clear understanding of which member did what, and in this confusion members would often overstep their bounds. When asked who led the team after the game had gone gold, the team did not have one clear response. The team needed to assign a project leader who could maintain consistency in team member’s responsibilities.

Outcome

Working on HookShot has taught me a few things.

1. Gaining use out of user playtests requires careful planning
2. Agile development favors small teams and ALSO inexperienced teams
3. Team confidence is important to keep up

Post Mortem: Lymph

This post mortem was done for Lymph, my first game created while attending Digipen.

Lymph provided me my first experience as a producer on a game project. As well, Lymph was also the first game that I have worked on intended with an educational purpose.

3 Things That Went Right

1. Identifying Overscope in Pre-Production
   The team trimmed down the scope of the game in the early stages of pre-production. Keeping in mind their limited time frame, they decided to schedule their time for the creation of only the core essentials of Lymph. Further mechanisms were put on a wish list that would be completed if the project moved ahead of schedule.
2. Defining the Target Market
   Early on in pre-production, the team decided to create a game that provided an educational purpose for children. This goal helped guide many of the team’s design and development decisions. The team always considered how they could make the game more medically accurate while staying approachable for children.
3. Early Prototype
   By designing gameplay mechanics that were not easily comparable to other games, the team decided to build an early prototype of the game that would help test out their design. Doing this also helped the team establish a unified vision for the game. The prototype proved to be useful in providing an understanding of the game’s design to the team members.

3 Things That Went Wrong

1. Poor Schedule Management
   The team had the good start of creating a schedule from the initial stages of the project. Team members were scheduled to work during the same hours, but class schedule differences segmented the teams work hours. The lack of unified work hours meant that redundant work was often created, wasting valuable time. Having the ability to work the same hours would have been beneficial for the project.
2. Low Level of Communication
   As mentioned previously, the segmented work hours proved detrimental to the team. One of the negative effects of working separately was the low level of communication. Not communicating with other team members lead to development mistakes and design follies. The team needed to find some sort of efficient intermediary form of communication if solidified work hours was not an option.
3. Rush into Production
   Lymph was an existing prototype before it was introduced to the team. This lead the team to feel confident enough to rush into production after a quick pre-production phase. The negative effects of this were seen in the late stages of the project timeline, when design and asset oversights started popping up. More time could have been spent in the pre-production detailing out the deliverables of production.