doc-workflow-proposal/docs/intro.md

---
sidebar_position: 0
slug: /
---

# Introduction

## 1. Executive Summary

For years, the company has successfully produced hundreds of casino-style games using a self-developed internal workflow. \
While this approach has proven sufficient in terms of volume and delivery, it lacks the structure and collaboration found in industry-standard practices. \
As the company continues to grow and take on more complex projects, it is crucial to evolve our processes to meet higher expectations for quality, efficiency, and cross-team coordination.

This proposal outlines a shift toward a more professional, standardized workflow that promotes proper planning, documentation, and collaboration across all departments—Game Design, Art, and Development. \
By adopting this new workflow, we aim to reduce rework, improve communication, enhance team morale, and produce higher-quality products that align with modern game development standards.

## 2. Background

The existing workflow for game development follows a sequential, department-isolated process that has been in place for several years. This process generally unfolds in the following stages:

### Project Initiation

New projects are initiated at the request of upper management or external clients.

The Project Management (PM) team receives the high-level requirements and project details.

A kickoff meeting is organized to begin the project. However, attendance at this meeting is typically limited to the PM team, a representative from the Business Analyst (BA) team, and the head of the Game Development department. Individual contributors or other departments such as Art, Game Designer (GD), or Quality Control (QC) are rarely involved at this early stage.

### Task Distribution and Team Handover

Following the kickoff, the PM team distributes tasks to each department based on the high-level scope.

Each team begins work independently, with minimal cross-department collaboration during early planning. The responsibilities of each team are as follows:

  #### Game Designer

  - *The GD team creates an initial **Game Design Document (GDD)**, which serves as a guideline but often lacks comprehensive detail.*
  - *They **design a wireframe** for the game’s UI to illustrate the layout and basic flow.*
  - *A **list of required assets** (images, animations, effects) is generated and handed off to the Art team.*
  - *The GD team also participates in **reviewing the completed art assets** and **validating the initial game prototype** once it is published on the SAT environment.*

  #### Art, UI/UX

  - *The Art team **receives the asset list** directly from the GD team.*
  - *Based on the list, they **produce all static and animated visual assets** without much context regarding gameplay mechanics or implementation details.*
  - *Upon completion, the assets are **returned to the GD** team for review and approval.*

  #### Game Developer

  - *The DEV team begins their work once they **receive the GDD and approved art assets** from the GD team.*
  - *They **build a prototype** version of the game and **publish it to the SAT environment** for internal testing.*
  - *After feedback and iteration, the team **continues development** until the final version is complete and **deployed for QA***.

  #### Quality Control 

  - *The QC team **receives the final build** from the DEV team.*
  - *Testing is conducted based on a standard set of common test cases as well as project-specific cases, if available.*
  - *Bugs or issues identified are **reported back to the DEV team** for resolution.*

### Project Finalization and Delivery

Once the product passes QA testing, the PM or BA team prepares the final build for delivery.

QC team along with the Game Developer finallize the product on LIVE environment before ending the project life cycle and move on to other projects.

## 3. Problem Statement

### Lack of Shared Accountability

The first obvious problem is the siloed workflow, where each department operates independently with minimal collaboration and limited visibility into each other's processes.

While the efforts of each department ultimately contribute to a completed and released game, most team members do not perceive themselves as actively building the game. Instead, their tasks are often viewed as isolated items on a checklist — assignments to be completed and handed off on schedule, rather than components of a shared creative product.

This task-based mindset leads to a *lack of ownership and responsibility* for the overall quality and success of the game. When individuals focus solely on completing their specific assignments without understanding or caring about how their work fits into the bigger picture, several issues arise:

- Problems are treated as someone else’s responsibility ("not my part"), leading to gaps in quality control.
- Teams are less likely to flag potential issues early or propose improvements, since they do not feel accountable for the final result.
- Bugs, design inconsistencies, and gameplay flaws are more likely to be passed downstream or discovered too late in production.
- Morale suffers, as team members feel disconnected from the creative purpose and impact of the product they are helping to build.

This disconnect between task execution and product ownership contributes directly to a fragmented development culture, where collaboration is minimal, innovation is stifled, and accountability is weak.

### Lack of a Professional Game Development Mindset and Workflow

Another core issue is the absence of a professional, industry-standard game development mindset across all departments. \
While individual teams complete their assigned work, they often do so with limited awareness of best practices in modern game production. \
This results in inefficiencies, avoidable rework, and quality inconsistencies that could be prevented with a more mature and informed approach.

#### Game Designer

- Game Design Document is often superficial, missing critical information and presented in a laughable unprofessional format.
- There is no clear process for keeping track, maintaining or updating the GDD as the project evolves.
- As a result, other teams often lack the context needed to align their work with the intended gameplay experience.

#### Art, UI/UX
- The Art team frequently operates without a strong foundation in game-specific art principles, such as game rendering process, optimization for performance, and platform-specific limitations.
- Without involvement in gameplay planning, artists may unintentionally create assets that are difficult to implement or misaligned with technical needs.

#### Game Developer

- Developers operate more as implementers than as engineers contributing to a scalable and maintainable product.
- Most of development framework lacks detailed technical documentation.
- There is no consistent version control practice allowing code review, task tracking, debugging process.

#### Quality Control

- Testing is heavily focused on end-user functionality, primarily through manual test cases and expected behavior scripts.
- There is little to no practice of alternative testing methods such as:
  - Regression testing
  - Performance profiling
  - Platform-specific compatibility testing
  - Edge case or scenario simulation
- QC is not involved in earlier development stages, limiting their ability to contribute proactively to game quality.

#### Workflow

The current workflow has been heavily shaped by years of experience developing casino-style games. While this familiarity has enabled fast production cycles and efficient reuse of common systems, it has also created a rigid process that does not scale or adapt well to new genres or innovative gameplay.

When the company takes on projects outside of the casino genre (minigame, canvas rendering lobby, multiplayer social game,...), the number of issues increases significantly.

- GDDs fail to capture the complexity of new mechanics or interactive systems.
- The art team may lack the stylistic or technical adaptability required for new genres.
- The DEV team must reinvent systems or stretch outdated architecture to fit unfamiliar gameplay models.
- The QC team lacks reusable test strategies for games with real-time interaction, branching outcomes.

This results in:

- Delivery timelines become unpredictable due to unforeseen complexities.
- Teams are forced into reactive development cycles, relying on last-minute fixes rather than forward planning.
- Quality drops significantly as workflows break down and teams struggle to collaborate effectively outside their usual comfort zones.

## 4. Proposed Solution Overview

To address the critical issues outlined in the previous section, we propose a complete restructuring of the game development workflow toward a more *collaborative*, *professional*, and *scalable model*. This new approach will adopt best practices from the game industry, promote cross-functional communication, and ensure every team contributes to the product’s vision from the start—not just their assigned deliverables.

The proposed solution focuses on:

- Adopt the industry-standard processes, tools, and documentation practices.
- Establishing a unified pre-production process with full team participation.
- Enabling continuous collaboration between departments throughout development.
- Promoting a culture of ownership, accountability, and shared product understanding.

These improvements are not just process changes—they represent a shift in mindset. From working in silos to working as a *cohesive game team*.

The [next section](category/proposed-solution) provides a detailed breakdown of the proposed workflow changes.