Just A Humble Swordsmith

Shipped On

Team Size

Role

Producer

Duration

Jan 2022 - May 2022

Just A Humble Swordsmith was my first team project at DigiPen. This project allowed me to showcase my production, technical, and design skills, which ultimately allowed our 3-person team to ship this game on Steam after 4 months.

This game was my first game project at DigiPen, which we published on Steam during my first year.

I worked with a systems designer and a technical design lead.

I was responsible managing scope and deliverables to ship the game on time.

I hosted playtests with over 20 First Time Users to support the design team.

If you want to hear the full story - read on!

Preproduction

Where We Began To Make A Game

An Early Concept

To create a common understanding of our game idea among our team, I leveraged visual documentation.

I used flowcharts to illustrate what our game's core game loop might look like, as well as what the systemic requirements our game would need.

This allowed our team to focus on delivering a vertical slice of our game's early prototype.

Left: Core game loop representation.

Right: Game component breakdown.

A Clear Path

As I took responsibility for building our game's prototype, I communicated early and often with my team to ensure my work in-engine reflected the team's vision for the game.

I created preliminary wireframes for the game's visuals to acquire buyoff from my team. This allowed me to focus on aligning my technical direction with the overall design.

For example, I iterated on a mockup game menu with our lead designer until it met our expectations in terms of scope and clarity.

A wireframe for the opening menu of our prototype

The Prototype

I used my technical and systems design skills to build character customization, weapon crafting, and a battle system. This provided our instructor/client with a clear understanding of the kind of game we intended to ship.

By building key systems early, I enabled our design team to begin experimenting and balancing game components such as characters and weapons.

Because of this, our team produced a prototype with all the planned core game loops as described in our early concept with additional time to add minor polish to such as preliminary art and animations.

The prototype crafting and adventurer selection menu

Production

Where We Built The Game

Setting Priorities

Our prototype was received with positive remarks, and we now had to provide a feature-complete game before the close of the semester.

As the team's producer, I directed, managed, and empowered our team by leveraging project management tools to schedule and prioritize our work.

For example, I created a game macro planning document to help our team determine what weapons and monsters would appear at which points in our game, which allowed our team to determine what content to build first.

Additionally, I built a comprehensive schedule to allow the team to optimize our work flow based on dependencies.

The Gantt chart schedule, showing the dependencies of our design tasks.

A Player-First Approach

I personally collected extensive playtest data in order to ensure that we had objective data to inform design choices. This was to ensure that any design decision was made to enhance the player experience.

I created a playtest survey to collect data from players who were not able to playtest in-person, which also allowed me to codify player responses such as player demographics to determine what kinds of players were and were not enjoying our game.

Additionally, I conducted over 15 live playtests where I took detailed notes as I observed players engage with our game. I used this data to compile an analysis report that helped identify and classify potential problems and solutions. This allowed our team to have productive week-to-week conversations on what to focus on based on the players' point of view.

Slide1

Slide2

Slide27

Slide1

1/27

The playtest analysis report I created during production

Law Of The Loop

As our final deadline approached, our team discussed all the possible areas of improvements as highlighted from the playtest data. It was clear there were far too many improvements than we had time for before the game was to ship. As a producer with a deep understanding of the tech and systems within our game, I led the effort to focus and iterate on the most essential parts of our game.

I examined and prioritized all potential improvements with my team. All improvements were classified under "Need To Have", "Should Have", or "Want To Have". Our daunting list of over 30 improvements shrunk to less than 10 essential improvements after a single meeting.

As a result of this, our team was able to iterate quickly and improve the parts of the game with the highest "return on investment". Many of our improvements were centered around the crafting system of the game, which was updated the most during this phase.

The crafting screen in the final build of Just A Humble Swordsmith

Reflection

Where I Look Back

Lessons Learned

This was my first attempt at making a game with a small team, and a successful one at that! It was well received by DigiPen and we were encouraged to put the game up on Steam. I can't help but feel proud of our accomplishment, but I also learned some valuable lessons along the way:

Information is power. Our team benefitted from the collection and interchanging of information. This was from frequent design conversations between the team as well as information gained from playtests. Seeking information to reduce the inherent subjectivity of design makes for better teamwork and a better game.

Players know best. By spending a couple hours with play testers, I learned so much more about how to improve our gave than if I had to speculate using only my design knowledge. Observing players engage with our game was easily one of the most rewarding and insightful parts of this project.

Design in every task. I took on many hats during this project: producer, technical designer, system designer, user researcher, and artist. Although much of my work was outside my official role as producer, I knew the holistic design of the game depended on each of the tasks I undertook. Whether I was conducting playtests, writing documentation, drawing monster art, or building the game, all of these tasks were integral to an engaging player experience.

Shipping means compromise. Even now, I look back at our game and still think of the 10 out of 30 improvements we addressed and wish we somehow found time to address all 30 improvements before our game went up on Steam. I anticipate this won't be the last time I have to make cuts to scope and prioritize some problems over others in order to meet deadlines and avoid crunch. I think I handled it well during this project and will continue to keep scope in mind in the future.