Bernard Hwang

Level Designer

Solo Project: F-Gravity

Download, DigiPen, Solo ProjectBernard HwangComment

Download F-Gravity (Windows)

Genre: Puzzle

Summary:
This project was the last of three assignments created for James Portnow’s (of Extra Credits) DigiPen class. For the final assignment, I was tasked with creating a puzzle game.

My Role:

  • Solo Project

Development Time: 1 month

Publish Date: 12-16-12

Post-Mortem:
The turn-based puzzle genre is one of the easier genres to playtest for. There are exact measurables such as turns taken and time spent per turn; and even the intangibles such as fun factor, thanks to how each puzzle’s start and end are clearly defined, are easily defined by the player. This is is why it was a shame that F-Gravity was not playtested to reveal it’s glaring issues. Technical issues aside, F-Gravity fails to create a proper interest curve. The difficulty is present when it is not needed, early on when the player is unclear of the game’s mechanics; and too low when it is needed the most, when players are reusing the same thought patterns used to solve the previous puzzle.

Post-Mortem: F-Gravity (Board Game)

Post-MortemBernard HwangComment

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.

Solo Project: Gather

Download, DigiPen, Solo ProjectBernard HwangComment

Download Gather (Windows)

Genre: Top-Down Shooter

Summary:
This project is the second of three assignments created for James Portnow’s (of Extra Credits) DigiPen class. This project is an arena-based top-down shooter. Originally starting out as a Game Jam game, Gather is the fully realized version.

I always tend to look back on unfinished projects or unattempted concepts when put under the pressure of creating something fast. There is some sort of cathartic feeling after completing a half-completed thought.

My Role:

  • Solo Project

Development Time: 1 month

Publish Date: 11-11-12

Post-Mortem:
A novel mechanic requires copious testing. While the visual aesthetics and feedback was there, the interest curve is not there, the character is sluggish, the player isn’t taught how to be successful at the game. These facts would come up with rigorous testing.

Again I tried novel mechanics, but a game will never turn out well simply by implementing my thoughts. This could have been a great piece with more attention given to the player’s needs.

Solo Project: PrototypeMan

Download, DigiPen, Solo ProjectBernard HwangComment

Download Prototype Man (Windows)

Genre: Platformer

Summary:
This project is the first of three assignments handed down to me by James Portnow of Extra Credits, in his DigiPen class. In this assignment, I explored which mechanics and aesthetics worked to create a 2d platformer.

My Role:

  • Solo Project

Development Time: 1 month

Publish Date: 10-06-12

Post-Mortem:
There were many obstacles that got in the way of player exploring the central mechanic. Death should not have been the only way for the player to learn. There are plenty of other ways to teach and give a player space to practice a mechanic other than the through the threat of demise. Using an extreme such as player death shined a light on a problem I suffer as a designer: I get trapped trying to accomplish the big picture.

I need to become cognizant of what each moment of my game is doing to my player. There are a number of exciting set pieces and challenges, but most of them are bogged down by too much traversal, being too far from a spawn point, finicky controls.

Post-Mortem: HookShot

Post-MortemBernard HwangComment

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