First Commit

.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

README.md

@@ -0,0 +1,41 @@
+# Website
+
+This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
+
+## Installation
+
+```bash
+yarn
+```
+
+## Local Development
+
+```bash
+yarn start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+## Build
+
+```bash
+yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+## Deployment
+
+Using SSH:
+
+```bash
+USE_SSH=true yarn deploy
+```
+
+Not using SSH:
+
+```bash
+GIT_USER=<Your GitHub username> yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

docs/01-proposed-solution/01-gd-team.md

@@ -0,0 +1,98 @@
+---
+sidebar_position: 1
+title: 'GD Team'
+---
+
+# GD Team
+
+The Game Design (GD) team is responsible for crafting the game's mechanics, systems, interface, and overall user experience. Additionally, the GD team plays a crucial role in cross-department communication and maintaining up-to-date documentation of features and requirements. To enhance their effectiveness and align with industry standards, the GD team should adopt the following improvements:
+
+## Implement a Proper GDD
+
+In professional game development, the Game Design Document (GDD) is typically divided into multiple structured documents or sections, each tailored for different development phases and target users—such as developers, artists, UI/UX designers, and QA/QC testers.
+
+To meet industry expectations, the GD team must evolve from producing only high-level overviews and wireframes to maintaining **complete, structured, and living GDDs**. These documents should follow proven formats used by established studios and large-scale projects.
+
+### 📚 Reference GDD Sources
+
+**Publicly Released GDDs**
+
+These examples provide valuable insight into real-world GDD structures and expectations:
+
+| Game / Studio                                 | Preview Image                           | Link                                                                 |
+|----------------------------------------------|-----------------------------------------|----------------------------------------------------------------------|
+| Grand Theft Auto (Race ‘n’ Chase) – Original GDD | ![GTA](../img/gta.png)                | [View PDF](https://www.gamedevs.org/uploads/grand-theft-auto.pdf)   |
+| Deus Ex – Annotated GDD                       | ![Deus Ex](../img/deux.png)             | [View PDF](https://drive.google.com/file/d/0B2_-knUokw90RzIwUEJsU2pYdWs/view?resourcekey=0-dqmq9k501fBUBDoUEgv4Sw) |
+| Dirty Bomb – Full Design Document             | ![DirtyBombGDD](../img/dirtybomb.png)   | [View PDF](http://db-design.splashdamage.com.s3-eu-west-1.amazonaws.com/dirty_bomb-game_design_document.pdf) |
+| PGSoft – Slot Game Information GDD            | ![PgsoftGDD](../img/pgsoft.png)         | [View Site](https://www.pgsoft.com/download/)                       |
+
+**Premium GDD Templates**
+
+Templates available from platforms such as **Notion** and **Nuclino** offer modern, interactive, and highly customizable frameworks for building GDDs.
+
+![Notion](../img/notion.png)
+![Nuclino](../img/nuclino.png)
+
+## Adopt Modern Tools for Game Design
+
+Traditionally, GDDs have been managed using Word, PowerPoint, or even informal chats in Teams. These methods make it difficult to track changes, maintain consistency, or ensure accessibility for other departments.
+
+To ensure clarity, maintainability, and team-wide collaboration, the GD team must adopt modern, industry-standard tools designed specifically for collaborative game development.
+
+### ✅ Recommended Tools
+
+| Tool                          | Purpose                          | Benefits                                                                                     |
+|-------------------------------|----------------------------------|----------------------------------------------------------------------------------------------|
+| **Notion** / **Confluence**  | GDD Documentation                | - Real-time collaboration<br></br>- Structured templates<br></br>- Version history<br></br>- Easy cross-referencing |
+| **Miro** / **FigJam**         | Flowcharts & UX Mapping          | - Visualize game flow<br></br>- Brainstorm features<br></br>- Create interactive UI screens            |
+| **Figma**                     | UI/UX Wireframes                 | - Clickable prototypes<br></br>- Pixel-perfect layouts<br></br>- Seamless handoff to Art and Dev teams  |
+| **Game Engine Prototypes**<br></br>(e.g., Cocos Creator, Unity, Godot) | Gameplay Prototyping | - Test core mechanics early<br></br>- Validate design feasibility<br></br>- Enable shared playtesting |
+
+## Organize the GDD with Change Log and Centralized Repository
+
+To improve version tracking and ensure consistent document access, the GD team should maintain a structured GDD repository with an embedded **change log** and well-defined access management.
+
+### ✅ Change Log Implementation
+
+Each GDD should include a clear **change log** that documents:
+- Date of change
+- Editor name
+- Summary of updates
+- Reason for the change (e.g., meeting feedback, client revision)
+
+This promotes transparency, reduces miscommunication, and establishes a reliable record of design decisions.
+
+### 📁 Centralized Document Repository
+
+A single source of truth should be used to host all GDD files. We recommend **Microsoft SharePoint** for its:
+- Secure access and permission control
+- Integrated version history and rollback features
+- Compatibility with Microsoft Teams and Office
+- Tagging, search, and commenting capabilities
+
+![Microsoft SharePoint](../img/sharepoint.png)
+
+### 🧭 Suggested Folder Structure
+
+Organize the GDD repository with a consistent structure to support fast navigation and cross-functional access:
+
+```
+/ProjectName/
+├── GDD/
+│   ├── 00_Overview.md
+│   ├── 01_Feature_Detail.md
+│   ├── 02_UI_UX.md
+│   ├── 03_Assets_List.xlsx
+│   ├── ...
+│   ├── 99_Changelog.md
+├── References/
+├── Meeting_Notes/
+├── Archive/
+```
+
+By maintaining a well-organized repository and standardized documentation practices, the GD team will improve production efficiency, cross-department alignment, and product quality.
+
+:::tip
+[**Game Design Skills**](https://gamedesignskills.com/) is a valuable resource for expanding your design toolkit and learning from industry best practices.
+:::
+

docs/01-proposed-solution/02-art-team.md

@@ -0,0 +1,55 @@
+---
+sidebar_position: 2
+title: 'Art Team'
+---
+
+# Art Team
+
+The Art Team plays a vital role in shaping the player's visual experience. However, under the current workflow, the team’s involvement is largely limited to executing asset requests—drawing images/animations based on lists provided by the GD team—without deeper integration into the game design process. While this has sufficed for basic visual delivery, it introduces several critical problems that directly impact both game quality and performance.
+
+## ⚠️ Current Issues
+
+### Lack of Game-Centric Art Knowledge
+Art is created with little consideration for how it functions within the game engine or interacts with gameplay systems. As a result:
+- Assets may be unoptimized, causing performance issues such as frame drops or memory overhead.
+- Elements may appear visually appealing in isolation but fail to communicate clearly or read well on actual game canvases, especially across varying screen sizes.
+- Animations may not conform to engine capabilities, requiring extra developer effort or rework.
+
+### Disconnected from Gameplay Context
+Artists often have no visibility into the player experience, level pacing, or interactive systems. This prevents them from:
+- Suggesting improvements to asset usability or feedback clarity.
+- Understanding how visual hierarchy affects UX/UI.
+- Adjusting the style to support gameplay mood or genre conventions.
+
+### Task-Only Mindset
+The current process fosters a task completion mentality, where the focus is on finishing the checklist rather than contributing to the visual identity of the game. This leads to:
+- Missed opportunities to propose stylistic direction or polish ideas.
+- Low creative engagement and undervaluing of the art team's potential.
+- Friction when design or dev teams require visual revisions the art team didn’t anticipate.
+
+## ✅ Proposed Improvements
+
+### Involve the Art Team in Pre-Production
+
+- Include the Art Team in early concept meetings and kickoff sessions.
+- Encourage the team to contribute ideas for visual themes, UI/UX direction, and animation styles.
+- Allow artists to collaborate directly with GD and DEV to ensure alignment between artistic vision and gameplay systems.
+
+### Build Awareness of Technical Game Art Principles
+
+- Provide internal training or documentation on how art assets affect game engine performance (e.g., texture size, draw calls, overdraw).
+- Introduce key optimization techniques such as:
+    - 9-Slice Scaling for scalable UI
+    - Sprite Atlases for efficient rendering
+    - Tileable Textures and Modular Design for environments
+    - Proper Pivot Point Positioning for accurate animation behavior
+    - Texture Compression Awareness for specific platform (WEBP, DXT, PVRTC)
+- Encourage artists to consider screen readability, resolution flexibility, and resource usage when creating assets.
+
+### Adopt Game Engine as a Collaborative Tool
+
+- Equip the Art Team to work directly with game engines (e.g., Cocos Creator, Unity) to test and review how their assets behave in-game.
+- Allow artists to preview scenes, animations, and UI within the engine to catch visual or functional issues early.
+- Encourage collaboration with developers and technical artists to optimize rendering and improve asset integration workflows.
+
+By embedding the Art Team into the full development cycle and building their technical capabilities, the studio can achieve a more cohesive, scalable, and high-quality visual standard across all projects.

docs/01-proposed-solution/03-qc-team.md

@@ -0,0 +1,47 @@
+---
+sidebar_position: 2
+title: 'QC Team'
+---
+
+# QC Team
+
+The Quality Control (QC) team is responsible for validating the quality, stability, and correctness of the final game build before release. However, in the current workflow, their role is often limited to final-stage testing, relying heavily on the GDD and art previews to create test cases. This narrow scope significantly limits the effectiveness and depth of QA coverage.
+
+## ⚠️ Current Issues
+
+### Late Involvement in the Development Cycle
+- The QC team is brought into the project only after the game is nearly complete.
+- By this time, most design and technical decisions are already locked in, leaving little room for early detection of system-wide issues or usability flaws.
+
+### Over-Reliance on GDD and Art Previews
+- Test planning is based almost entirely on the GDD and static visual references, which are often incomplete or outdated by the time testing begins.
+- This results in missed edge cases, incomplete test coverage, and delays caused by last-minute clarification requests.
+
+### Lack of Proactive QA Practices
+- The team often focuses only on end-user experience testing (e.g., basic functionality, navigation, or win conditions).
+- There is minimal use of structured QA methodologies such as:
+    - Regression testing
+    - Boundary testing
+    - Performance and stress testing
+    - Compatibility testing across platforms and devices
+
+## ✅ Proposed Improvements
+
+### Involve QC from Pre-Production Phase
+- Include QA representatives in early design discussions and kickoff meetings.
+- Enable them to understand feature intentions, risk areas, and gameplay logic from the start.
+- Allow the team to begin drafting test strategies and scenarios early, not just test cases after implementation.
+
+### Establish Internal Test Documentation
+- Encourage QC to build and maintain their own living Test Plan and Test Specification documents based on direct project participation, not just GDD handoffs.
+- Track bugs, testing scenarios, and coverage status using industry standard format
+
+### Adopt Broader Testing Methodologies
+
+Train and assign the team to cover various QA techniques beyond user experience, including:
+- Functional, non-functional, and exploratory testing
+- Automated testing skillset
+- Stress/load testing (FPS, memory, asset loads)
+- Multi-platform compatibility validation
+
+By embedding the Art Team into the full development cycle and building their technical capabilities, the studio can achieve a more cohesive, scalable, and high-quality visual standard across all projects.

docs/01-proposed-solution/04-game-dev-team.md

@@ -0,0 +1,55 @@
+---
+sidebar_position: 4
+title: 'Game Dev Team'
+---
+
+# Game Developer Team
+
+The Development team is responsible for implementing game features, integrating assets, and building the final product experience. While the current workflow supports small-scale casino-style games, it has become increasingly outdated and limiting—both in terms of team growth and technological capability. To evolve with industry standards and scale to more complex projects, the DEV team must adopt better tools, practices, and collaboration models.
+
+## ⚠️ Current Issues
+
+### 1. Improper Use of Project Management Tools
+- Development tasks are currently managed through **OpenProject**, which is more suitable for PMs than for developers.
+- This results in disjointed workflows, weak integration with version control, and lack of proper branching or merge request tracking.
+
+### 2. Technological Stagnation
+- The tech stack remains focused on traditional web-based casino game development.
+- There's minimal effort to explore newer tools, platforms, or game engine advancements.
+- Modern game architecture and optimization practices are underutilized.
+
+### 3. Single-Developer Workflow Model
+- Most games are built by a single developer from start to finish.
+- There is limited collaboration, peer review, or code reuse.
+- Knowledge silos form, and shared technical standards are difficult to enforce.
+
+---
+
+## ✅ Proposed Improvements
+
+### 1. Use Gitea for Development-Centric Project Management
+- Replace OpenProject with **Gitea** for handling:
+  - Git repositories
+  - Issue tracking
+  - Branching strategy
+  - Pull requests and code reviews
+- This enables a more efficient and transparent development workflow.
+
+### 2. Modernize Game Development Practices
+- Encourage the team to:
+  - Stay updated on current engine and framework capabilities (e.g., Unity, Cocos Creator, WebAssembly)
+  - Learn and apply advanced architecture patterns: modularity, ECS, DI, plugin systems
+  - Utilize tooling like **profilers**, **linting**, **CI/CD**, and **debugging environments**
+- Dedicate R&D time to explore new platforms and technologies (e.g., mobile-native, multiplayer systems)
+
+### 3. Shift Toward Collaborative Game Development
+- Build small, multi-developer teams for selected projects.
+- Promote practices such as:
+  - Code review and pair programming
+  - Shared libraries and reusable modules
+  - Technical leadership and mentoring roles
+- This encourages long-term scalability and continuous team learning.
+
+---
+
+By transforming the Development team’s process, toolset, and structure, the studio can better adapt to changing market needs, improve internal efficiency, and prepare for larger and more ambitious titles.

docs/01-proposed-solution/_category_.json

@@ -0,0 +1,11 @@
+{
+    "position": 1,
+    "label": "Proposed Solution",
+    "collapsible": true,
+    "collapsed": false,
+    "link": {
+        "type": "generated-index",
+        "title": "Proposed Solution",
+        "description": "Propose solution to be applied for each department."
+    }
+}

docs/02-approach.md

@@ -0,0 +1,51 @@
+---
+sidebar_position: 2
+---
+
+# Approach
+
+The current development workflow has been in place for many years and has proven effective for delivering a high volume of casino-style games. However, its deeply ingrained nature makes it **difficult to change without disruption**. Attempting to overhaul the entire pipeline across all teams at once may introduce confusion, resistance, and new types of inefficiencies.
+
+To mitigate risk, the recommended approach is to **pilot the new workflow on a separate, small-scale project**. This allows us to validate and refine the new processes in a controlled environment without interfering with ongoing productions.
+
+## 🔍 Selecting a Test Project
+
+We propose choosing a **non-casino-style project** that is simple in scope but different enough to challenge current assumptions. This helps ensure that the new workflow can scale to genres beyond our existing comfort zone.
+
+Potential candidates for this pilot project include:
+
+- 🕹 **A simple minigame** with clear gameplay loops and modular systems  
+- 👥 **A social game** prototype focused on user engagement and progression  
+- 🎮 **A mechanic-specific prototype**, such as turn-based combat, platformer movement, or multiplayer interaction  
+
+These formats allow us to experiment with new design-document structures, team workflows, art standards, and QA strategies in a real-world context.
+
+---
+
+## 👥 Forming the Pilot Team
+
+A small, cross-functional team should be assembled to execute the project under the proposed new workflow. The team should include representatives from:
+
+- Game Design
+- Art
+- Development
+- QA
+- Project Management (optional support)
+
+Critically, the team should be led by a **dedicated Project Lead or Director** who:
+
+- Understands the goals of the workflow transition  
+- Can enforce collaboration and documentation standards  
+- Tracks progress, identifies pain points, and proposes adjustments  
+- Acts as the communication bridge between leadership and the pilot team  
+
+---
+
+## 🎯 Objectives of the Pilot
+
+- Validate the practicality of the new workflow and tools in a production setting  
+- Collect feedback from all involved roles  
+- Measure delivery efficiency, product quality, and team satisfaction  
+- Identify blockers and iterate on workflow adjustments before full adoption  
+
+Once the pilot project is completed and reviewed, the studio can move forward with broader implementation across teams with greater confidence and alignment.

docs/03-milestone.md

@@ -0,0 +1,59 @@
+---
+sidebar_position: 3
+---
+
+# Milestone
+
+To ensure structured execution of the pilot project and proper evaluation of the new workflow, we propose the following milestone plan. Each milestone represents a phase of development aligned with industry practices, with built-in checkpoints for review, feedback, and documentation updates.
+
+## 📌 Phase 1: Pre-Production
+
+- ✅ Assemble the pilot team across all key departments
+- ✅ Select and define the non-casino pilot project
+- ✅ Conduct project kickoff with full team involvement
+- ✅ Create initial GDD, art style guide, and technical documentation
+- ✅ Define tooling and workflow expectations (e.g., Gitea, SharePoint, Figma, Confluence)
+- ✅ Establish communication and tracking channels (e.g., weekly sync, retrospective format)
+
+## 📌 Phase 2: Early Development
+
+- ✅ Begin iterative prototyping of core features
+- ✅ Conduct design and art reviews during implementation
+- ✅ Initiate collaborative testing planning (QA building their own test docs)
+- ✅ Monitor use of tools and workflows to validate team engagement and clarity
+
+## 📌 Phase 3: Production Development
+
+- ✅ Finalize major systems and implement full game loop
+- ✅ Continue multi-discipline collaboration (GD–DEV–ART–QC)
+- ✅ Track and log workflow bottlenecks, miscommunications, and productivity pain points
+- ✅ Conduct internal playtesting and polish passes
+
+## 📌 Phase 4: QA and Finalization
+
+- ✅ Full testing round with structured bug reporting
+- ✅ Conduct performance testing, UX testing, and edge case checks
+- ✅ Finish documentation: changelogs, postmortem notes, feature spec verification
+
+## 📌 Phase 5: Workflow Evaluation Report
+
+- ✅ Conduct a team-wide retrospective on the pilot workflow
+- ✅ Collect feedback from all roles (Design, Art, DEV, QA)
+- ✅ Analyze the impact of the new process on:
+  - Communication
+  - Quality
+  - Development speed
+  - Rework rates
+  - Team morale
+- ✅ Compile findings into a **Final Workflow Change Report**
+
+## 📌 Phase 6: Expansion Plan
+
+- ✅ Use report insights to:
+  - Adjust workflow gaps or team practices
+  - Prepare updated templates or onboarding guides
+- ✅ Propose applying the improved workflow to:
+  - Another pilot project
+  - A more complex game
+  - An upcoming **casino-style game**, once proven successful
+

docs/04-expected-outcome.md

@@ -0,0 +1,58 @@
+---
+sidebar_position: 4
+---
+
+# Expected Outcome
+
+By successfully piloting and refining the new workflow, we expect to see measurable improvements across all departments. These improvements will not only enhance production efficiency and product quality, but also foster stronger collaboration, professional growth, and long-term scalability.
+
+---
+
+## 🎯 Game Design (GD) Team
+
+- Produce **structured, maintainable GDDs** with clear sections for gameplay, UI, and asset planning
+- Gain visibility into downstream implementation, resulting in more practical and testable design decisions
+- Collaborate more effectively with Art and Dev to reduce feature gaps and iteration cycles
+- Serve as a proactive hub for interdepartmental alignment and vision consistency
+
+---
+
+## 🎨 Art Team
+
+- Develop assets with greater awareness of **technical constraints and gameplay context**
+- Propose and maintain **style guides** and **visual direction**, rather than just fulfilling requests
+- Use game engine previews to **self-evaluate asset integration and quality**
+- Reduce rework and friction caused by disconnected production flow
+
+---
+
+## 💻 Development (DEV) Team
+
+- Adopt developer-first tooling (**Gitea**) for better code management and tracking
+- Stay up to date with modern tech stacks, best practices, and performance optimization techniques
+- Build collaborative systems instead of working in isolation
+- Contribute to scalable, maintainable frameworks that benefit future projects
+
+---
+
+## 🧪 Quality Control (QC) Team
+
+- Involve earlier in the process to **understand intent** and build test strategies proactively
+- Use structured **test plans** and diverse testing methods beyond basic user flow validation
+- Contribute to gameplay quality, not just bug reporting
+- Improve confidence in releases through deeper and earlier validation
+
+---
+
+## 🤝 Overall Team Outcome
+
+- **Improved communication and accountability** across all teams
+- **Fewer misalignments** and last-minute changes due to clearer shared understanding
+- **Higher product quality** with more efficient iteration loops
+- **Greater flexibility** to take on diverse genres beyond casino-style games
+- A more **engaged and empowered team culture** that encourages feedback, ownership, and innovation
+- Clear documentation and reporting that supports future scaling and onboarding
+
+---
+
+This pilot initiative is not just about testing a new process—it’s about elevating the team’s mindset and capabilities to meet modern development standards and unlock new creative potential.

docs/05-risk-and-mitigation.md

@@ -0,0 +1,20 @@
+---
+sidebar_position: 5
+---
+
+# Risks and Mitigation
+
+While transitioning to a new workflow offers clear long-term benefits, it also introduces short-term risks and challenges. The following table outlines key risks associated with the pilot initiative and provides mitigation strategies to address them effectively.
+
+| ⚠️ **Risk** | 🔍 **Description** | ✅ **Mitigation Strategy** |
+|-------------|--------------------|-----------------------------|
+| **Resistance to Change** | Team members may be hesitant to move away from familiar habits and tools. | - Select open-minded and adaptable team members for the pilot<br></br>- Communicate the purpose and benefits clearly<br></br>- Provide training and support during transition |
+| **Initial Productivity Drop** | Learning new tools or adapting to new workflows may temporarily reduce development speed. | - Choose a small, low-pressure project for the pilot<br></br>- Plan extra buffer time for onboarding and process alignment<br></br>- Encourage learning over rushing deadlines |
+| **Incomplete Adoption** | Some team members might partially follow the workflow or fall back to old habits. | - Assign a strong project lead to monitor and enforce standards<br></br>- Hold regular check-ins to guide and realign<br></br>- Use shared documentation and visible workflows (e.g., Notion, Gitea) |
+| **Tooling or Integration Issues** | New tools may not integrate smoothly or lack certain features. | - Start with tools that are widely used and have community support<br></br>- Keep backup methods (e.g., Google Docs, Trello) in case of tool failure<br></br>- Evaluate tools during the pilot and adjust based on feedback |
+| **Misalignment with Core Production Needs** | The new workflow may not immediately apply to casino-style projects. | - Design the pilot with broader genre goals in mind<br></br>- Document what works vs. what needs adaptation<br></br>- Apply successful parts of the workflow incrementally to future casino games |
+| **Leadership Bottleneck** | If the pilot lead lacks authority or time, progress may stall. | - Choose a leader with decision-making power and experience<br></br>- Clearly define their role and allocate dedicated time to the project<br></br>- Provide escalation support from management if blockers arise |
+
+---
+
+With careful planning, strong leadership, and incremental rollout, these risks can be mitigated to ensure the success of the pilot project—and ultimately, the broader workflow transformation.

docs/06-evaluation-and-measurement.md

@@ -0,0 +1,42 @@
+---
+sidebar_position: 6
+---
+
+# Evaluation and Measurement
+
+To determine whether the new workflow provides tangible benefits, it is essential to establish clear evaluation criteria. This will help measure success, identify areas for improvement, and provide data-driven justification for scaling the workflow to larger teams and projects.
+
+## 📊 Evaluation Categories
+
+The pilot project will be assessed across the following key areas:
+
+| 📌 **Category** | 🔍 **Evaluation Focus** | 📈 **Measurement Method** |
+|----------------|--------------------------|----------------------------|
+| **Process Efficiency** | Was the new workflow easier to follow and maintain? | - Compare time spent in each phase vs. old projects<br></br>- Count handoff errors, missed steps, or unnecessary revisions |
+| **Cross-Team Collaboration** | Did departments work together more effectively? | - Track the number and quality of cross-team syncs and feedback loops<br></br>- Survey team members on communication clarity |
+| **Tool Adoption** | Were new tools (e.g., Gitea, Notion, Figma) effectively used? | - Review activity logs, usage frequency, and team feedback<br></br>- Identify which tools improved productivity |
+| **Output Quality** | Did the project result in a more stable, polished product? | - Monitor bug count and severity at each phase<br></br>- Assess playtest feedback and visual/polish consistency |
+| **Team Engagement** | Did the team feel more involved, empowered, and clear on responsibilities? | - Conduct anonymous surveys<br></br>- Use retrospective sessions to gather qualitative feedback |
+| **Knowledge Retention & Documentation** | Was knowledge better preserved and shared across departments? | - Check completeness of GDD, art specs, test plans, and changelogs<br></br>- Evaluate how easily new members could understand the project state |
+
+---
+
+## 🧾 Reporting Structure
+
+After the pilot project is completed:
+
+1. **Internal Retrospective Meetings**  
+   - Each team (GD, Art, DEV, QC) conducts a mini retrospective
+   - Identify what worked, what didn’t, and proposed changes
+
+2. **Cross-Department Debrief**  
+   - A full-team meeting to review interdepartmental collaboration and tool usage
+
+3. **Final Evaluation Report**  
+   - Compiled by the Project Lead
+   - Includes metrics, feedback, and recommendations
+   - Used to determine whether to scale, revise, or pause the new workflow
+
+---
+
+By combining **quantitative metrics** and **qualitative feedback**, we ensure that the evaluation reflects not only speed and output—but also long-term sustainability, team morale, and development quality.

docs/07-references.md

@@ -0,0 +1,129 @@
+---
+sidebar_position: 6
+---
+
+# References
+
+The following sources and case studies support the concepts and challenges discussed in this proposal. They highlight real-world examples where workflow, collaboration, or documentation practices had a significant impact on project success or failure.
+
+---
+
+## 1. **Final Fantasy XIV – The Flower Pot Performance Issue**  
+**Topic:** Technical misalignment between teams leading to unintended performance problems  
+
+**Summary:**  
+In Final Fantasy XIV, a seemingly simple feature—adding decorative flower pots to player housing—caused unexpected performance drops. The root cause was a lack of technical alignment between the **UI team** and the **engine/rendering team**. Each flower pot used the **same high-complexity shader** originally designed for **player characters**, drastically increasing the rendering load when multiple pots were placed.  
+
+Although both teams produced high-quality work independently, their lack of shared technical constraints or collaborative review caused a massive increase in draw calls and shader complexity—resulting in degraded performance.
+
+**Lesson:**  
+This case illustrates that **two well-executed features built in isolation can combine to create a major issue**. Without shared technical planning, documentation alignment, or early review, even simple systems can clash in costly ways. Cross-team collaboration and engine-awareness are critical, especially when reusing core systems.
+
+## 2. **Anthem – Design Vision vs. Technical Reality**  
+**Topic:** Unrealistic design expectations and lack of technical alignment  
+
+**Summary:**  
+During early development, the design team for *Anthem* envisioned a world with **four large explorable cities**, each with unique environments, quests, and NPC ecosystems. This was part of their ambition to create a living, dynamic sci-fi world. However, the team failed to properly validate whether this vision was technically feasible in the chosen engine (Frostbite)—an engine known to be inflexible and poorly suited for large-scale RPG world-building.
+
+As development progressed, it became clear that:
+- The engine **could not support multiple large city hubs** due to memory constraints, loading issues, and performance bottlenecks.
+- There was **no clear communication** between designers and engine programmers early enough to adapt the design accordingly.
+- Instead of iterating or compromising gradually, the team had to **cut the entire plan down to a single city (Fort Tarsis)** late in development.
+
+This resulted in:
+- Wasted development time and resources
+- Broken expectations for both the design team and leadership
+- A final product that felt much smaller and more static than initially promised
+
+**Lesson:**  
+This highlights the risk of building ambitious game designs in isolation without consulting engineering or testing feasibility early. **Good design ideas are only successful when grounded in technical reality and validated collaboratively** across departments.
+
+## 3. **Hades – Success Through Iteration and Cross-Team Collaboration**  
+**Topic:** Effective design-development alignment and agile workflow  
+
+**Summary:**  
+*Hades*, developed by Supergiant Games, is widely regarded as a model of modern indie game development. Despite its smaller team size and budget, Hades achieved critical acclaim through an **iterative, transparent, and collaborative development process**.
+
+Key success factors included:
+- **Tight collaboration between design, art, narrative, and engineering**, with regular feedback loops
+- Early and ongoing use of **playable prototypes** to validate mechanics and pacing
+- Clear, living documentation for gameplay systems, character dialogue structure, and progression logic
+- A deliberately scoped, modular design that allowed gradual content expansion without risking system collapse
+- Use of **early access** as a structured feedback and testing phase, enabling the team to refine systems in real time
+
+Unlike large AAA productions, the Hades team did not rely on isolated handoffs or waterfall-style pipelines. Instead, they embraced a **shared responsibility model**, where all departments were involved in shaping and refining the game throughout development.
+
+**Lesson:**  
+Hades demonstrates that **small, well-aligned teams with open communication and flexible planning can outperform larger studios** when the workflow encourages iteration, ownership, and cross-discipline collaboration.
+
+## 4. **Cyberpunk 2077 – Broken Integration from Siloed Development**  
+**Topic:** Teams worked in parallel without cohesive integration planning  
+
+**Summary:**  
+CD Projekt Red developed Cyberpunk 2077 with multiple teams working on quests, AI, open world, and cinematic systems—but in silos. These teams often lacked synchronization, resulting in systems that didn’t align or integrate properly.
+
+**Issues:**  
+- AI and quest logic didn't cooperate  
+- Mid-project engine upgrades broke existing features  
+- QA was brought in late, unable to test systems holistically  
+
+**Lesson:**  
+Cross-department collaboration and technical validation are essential throughout development—not just at the end. Integration must be a continuous process.
+
+## 5. **Destiny – Tooling and Team Isolation**  
+**Topic:** Technical silos caused by poor documentation and disconnected pipelines  
+
+**Summary:**  
+During Destiny's development, different departments at Bungie created custom tools for world-building, scripting, and narrative. These tools were incompatible, and teams lacked shared documentation.
+
+**Issues:**  
+- Writers and level designers could not see how content interacted  
+- Integration only happened late in production  
+- Bugs and mismatches emerged due to isolated testing  
+
+**Lesson:**  
+Tool fragmentation is a form of siloing. Cross-functional infrastructure and shared documentation are vital to avoid disconnects.
+
+## 6. **Mass Effect: Andromeda – Lack of Shared Animation Direction**  
+**Topic:** Disconnected animation, mocap, and narrative pipelines  
+
+**Summary:**  
+Andromeda's awkward facial animations stemmed from narrative, mocap, and animation teams working in isolation. Voice work was recorded before final scripts, and there was no cohesive review process.
+
+**Issues:**  
+- Animations looked robotic and lacked emotional tone  
+- Scenes lacked consistency across performance layers  
+- Rework was minimal due to time pressure and workflow friction  
+
+**Lesson:**  
+Narrative-heavy games require real-time collaboration between performance teams. Emotion, timing, and scene context must be shared.
+
+## 7. **Battlefield 2042 – Disconnected Studio Teams and Late QA**  
+**Topic:** Cross-studio development with poor synchronization  
+
+**Summary:**  
+Battlefield 2042 was developed across multiple global studios. Each worked on isolated systems—vehicles, maps, backend—without aligned testing or documentation standards.
+
+**Issues:**  
+- QA joined late and couldn’t test integration properly  
+- Features built in silos didn’t mesh (e.g., scale vs. pacing)  
+- Bugs and performance issues overwhelmed the launch  
+
+**Lesson:**  
+Cross-studio projects demand tight coordination, aligned pipelines, and early QA involvement. Silos at this scale are extremely costly.
+
+## 8. **God of War (2018) – Unified Creative Vision and Technical Collaboration**  
+**Studio:** Santa Monica Studio  
+**Topic:** Cross-departmental cohesion and long-term planning  
+
+**Summary:**  
+God of War's reboot was a massive technical and creative success. The project succeeded because of a **strong creative director (Cory Barlog)**, early alignment between departments, and a clear long-term vision shared by everyone.
+
+**Success Factors:**  
+- Cinematic, level, and gameplay teams met regularly  
+- The engine team worked closely with animation and camera designers  
+- A living design document guided production across all stages  
+- Team retrospectives were used frequently to resolve tension and misalignment  
+
+**Lesson:**  
+A strong unifying vision and proactive collaboration between disciplines allow for ambitious features (like the no-cut camera) to be executed successfully.

docs/intro.md

@@ -0,0 +1,145 @@
+---
+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.

docusaurus.config.ts

@@ -0,0 +1,135 @@
+import type * as Preset from '@docusaurus/preset-classic';
+import type { Config } from '@docusaurus/types';
+import { themes as prismThemes } from 'prism-react-renderer';
+
+// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
+
+const config: Config = {
+  title: 'Proposal',
+  tagline: 'Mercury',
+  favicon: 'img/favicon.ico',
+
+  // Future flags, see https://docusaurus.io/docs/api/docusaurus-config#future
+  future: {
+    v4: true, // Improve compatibility with the upcoming Docusaurus v4
+  },
+
+  // Set the production url of your site here
+  url: 'https://your-docusaurus-site.example.com',
+  // Set the /<baseUrl>/ pathname under which your site is served
+  // For GitHub pages deployment, it is often '/<projectName>/'
+  baseUrl: '/',
+
+  // GitHub pages deployment config.
+  // If you aren't using GitHub pages, you don't need these.
+  organizationName: 'facebook', // Usually your GitHub org/user name.
+  projectName: 'docusaurus', // Usually your repo name.
+
+  onBrokenLinks: 'throw',
+  onBrokenMarkdownLinks: 'warn',
+
+  // Even if you don't use internationalization, you can use this field to set
+  // useful metadata like html lang. For example, if your site is Chinese, you
+  // may want to replace "en" with "zh-Hans".
+  i18n: {
+    defaultLocale: 'en',
+    locales: ['en'],
+  },
+
+  presets: [
+    [
+      'classic',
+      {
+        docs: {
+          sidebarPath: './sidebars.ts',
+          // Please change this to your repo.
+          // Remove this to remove the "edit this page" links.
+          editUrl:
+            'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
+          routeBasePath: '/', // Set to '/' to serve docs at the root URL
+        },
+        blog: {
+          showReadingTime: true,
+          feedOptions: {
+            type: ['rss', 'atom'],
+            xslt: true,
+          },
+          // Please change this to your repo.
+          // Remove this to remove the "edit this page" links.
+          editUrl:
+            'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
+          // Useful options to enforce blogging best practices
+          onInlineTags: 'warn',
+          onInlineAuthors: 'warn',
+          onUntruncatedBlogPosts: 'warn',
+        },
+        theme: {
+          customCss: './src/css/custom.css',
+        },
+      } satisfies Preset.Options,
+    ],
+  ],
+
+  themeConfig: {
+    // Replace with your project's social card
+    image: 'img/docusaurus-social-card.jpg',
+    navbar: {
+      title: 'Workflow Proposal',
+      logo: {
+        alt: 'Mercury Logo',
+        src: 'img/mercury-logo.png',
+      }
+    },
+    footer: {
+      style: 'dark',
+      links: [
+        {
+          title: 'Docs',
+          items: [
+            {
+              label: 'Tutorial',
+              to: '/docs/intro',
+            },
+          ],
+        },
+        {
+          title: 'Community',
+          items: [
+            {
+              label: 'Stack Overflow',
+              href: 'https://stackoverflow.com/questions/tagged/docusaurus',
+            },
+            {
+              label: 'Discord',
+              href: 'https://discordapp.com/invite/docusaurus',
+            },
+            {
+              label: 'X',
+              href: 'https://x.com/docusaurus',
+            },
+          ],
+        },
+        {
+          title: 'More',
+          items: [
+            {
+              label: 'Blog',
+              to: '/blog',
+            },
+            {
+              label: 'GitHub',
+              href: 'https://github.com/facebook/docusaurus',
+            },
+          ],
+        },
+      ],
+      copyright: `Copyright © ${new Date().getFullYear()} My Project, Inc. Built with Docusaurus.`,
+    },
+    prism: {
+      theme: prismThemes.github,
+      darkTheme: prismThemes.dracula,
+    },
+  } satisfies Preset.ThemeConfig,
+};
+
+export default config;

package.json

@@ -0,0 +1,47 @@
+{
+  "name": "doc-workflow-proposal",
+  "version": "0.0.0",
+  "private": true,
+  "scripts": {
+    "docusaurus": "docusaurus",
+    "start": "docusaurus start",
+    "build": "docusaurus build",
+    "swizzle": "docusaurus swizzle",
+    "deploy": "docusaurus deploy",
+    "clear": "docusaurus clear",
+    "serve": "docusaurus serve",
+    "write-translations": "docusaurus write-translations",
+    "write-heading-ids": "docusaurus write-heading-ids",
+    "typecheck": "tsc"
+  },
+  "dependencies": {
+    "@docusaurus/core": "3.8.1",
+    "@docusaurus/preset-classic": "3.8.1",
+    "@mdx-js/react": "^3.0.0",
+    "clsx": "^2.0.0",
+    "prism-react-renderer": "^2.3.0",
+    "react": "^19.0.0",
+    "react-dom": "^19.0.0"
+  },
+  "devDependencies": {
+    "@docusaurus/module-type-aliases": "3.8.1",
+    "@docusaurus/tsconfig": "3.8.1",
+    "@docusaurus/types": "3.8.1",
+    "typescript": "~5.6.2"
+  },
+  "browserslist": {
+    "production": [
+      ">0.5%",
+      "not dead",
+      "not op_mini all"
+    ],
+    "development": [
+      "last 3 chrome version",
+      "last 3 firefox version",
+      "last 5 safari version"
+    ]
+  },
+  "engines": {
+    "node": ">=18.0"
+  }
+}

sidebars.ts

@@ -0,0 +1,33 @@
+import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
+
+// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
+
+/**
+ * Creating a sidebar enables you to:
+ - create an ordered group of docs
+ - render a sidebar for each doc of that group
+ - provide next/previous navigation
+
+ The sidebars can be generated from the filesystem, or explicitly defined here.
+
+ Create as many sidebars as you want.
+ */
+const sidebars: SidebarsConfig = {
+  // By default, Docusaurus generates a sidebar from the docs folder structure
+  tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
+
+  // But you can create a sidebar manually
+  /*
+  tutorialSidebar: [
+    'intro',
+    'hello',
+    {
+      type: 'category',
+      label: 'Tutorial',
+      items: ['tutorial-basics/create-a-document'],
+    },
+  ],
+   */
+};
+
+export default sidebars;

src/components/HomepageFeatures/index.tsx

@@ -0,0 +1,73 @@
+import Heading from '@theme/Heading';
+import clsx from 'clsx';
+import type { ReactNode } from 'react';
+import styles from './styles.module.css';
+
+type FeatureItem = {
+  title: string;
+  Svg: React.ComponentType<React.ComponentProps<'svg'>>;
+  description: ReactNode;
+};
+
+const FeatureList: FeatureItem[] = [
+  {
+    title: 'Easy to Use',
+    Svg: null,
+    description: (
+      <>
+        Docusaurus was designed from the ground up to be easily installed and
+        used to get your website up and running quickly.
+      </>
+    ),
+  },
+  {
+    title: 'Focus on What Matters',
+    Svg: null,
+    description: (
+      <>
+        Docusaurus lets you focus on your docs, and we&apos;ll do the chores. Go
+        ahead and move your docs into the <code>docs</code> directory.
+      </>
+    ),
+  },
+  {
+    title: 'Powered by React',
+    Svg: null,
+    description: (
+      <>
+        Extend or customize your website layout by reusing React. Docusaurus can
+        be extended while reusing the same header and footer.
+      </>
+    ),
+  },
+];
+
+function Feature({ title, Svg, description }: FeatureItem)
+{
+  return (
+    <div className={clsx('col col--4')}>
+      <div className="text--center">
+        <Svg className={styles.featureSvg} role="img" />
+      </div>
+      <div className="text--center padding-horiz--md">
+        <Heading as="h3">{title}</Heading>
+        <p>{description}</p>
+      </div>
+    </div>
+  );
+}
+
+export default function HomepageFeatures(): ReactNode
+{
+  return (
+    <section className={styles.features}>
+      <div className="container">
+        <div className="row">
+          {FeatureList.map((props, idx) => (
+            <Feature key={idx} {...props} />
+          ))}
+        </div>
+      </div>
+    </section>
+  );
+}

src/components/HomepageFeatures/styles.module.css

@@ -0,0 +1,11 @@
+.features {
+  display: flex;
+  align-items: center;
+  padding: 2rem 0;
+  width: 100%;
+}
+
+.featureSvg {
+  height: 200px;
+  width: 200px;
+}

src/css/custom.css

@@ -0,0 +1,30 @@
+/**
+ * Any CSS included here will be global. The classic template
+ * bundles Infima by default. Infima is a CSS framework designed to
+ * work well for content-centric websites.
+ */
+
+/* You can override the default Infima variables here. */
+:root {
+  --ifm-color-primary: #2e8555;
+  --ifm-color-primary-dark: #29784c;
+  --ifm-color-primary-darker: #277148;
+  --ifm-color-primary-darkest: #205d3b;
+  --ifm-color-primary-light: #33925d;
+  --ifm-color-primary-lighter: #359962;
+  --ifm-color-primary-lightest: #3cad6e;
+  --ifm-code-font-size: 95%;
+  --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
+}
+
+/* For readability concerns, you should choose a lighter palette in dark mode. */
+[data-theme='dark'] {
+  --ifm-color-primary: #25c2a0;
+  --ifm-color-primary-dark: #21af90;
+  --ifm-color-primary-darker: #1fa588;
+  --ifm-color-primary-darkest: #1a8870;
+  --ifm-color-primary-light: #29d5b0;
+  --ifm-color-primary-lighter: #32d8b4;
+  --ifm-color-primary-lightest: #4fddbf;
+  --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3);
+}

src/pages/index-may.tsx

@@ -0,0 +1,44 @@
+import type {ReactNode} from 'react';
+import clsx from 'clsx';
+import Link from '@docusaurus/Link';
+import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
+import Layout from '@theme/Layout';
+import HomepageFeatures from '@site/src/components/HomepageFeatures';
+import Heading from '@theme/Heading';
+
+import styles from './index.module.css';
+
+function HomepageHeader() {
+  const {siteConfig} = useDocusaurusContext();
+  return (
+    <header className={clsx('hero hero--primary', styles.heroBanner)}>
+      <div className="container">
+        <Heading as="h1" className="hero__title">
+          {siteConfig.title}
+        </Heading>
+        <p className="hero__subtitle">{siteConfig.tagline}</p>
+        <div className={styles.buttons}>
+          <Link
+            className="button button--secondary button--lg"
+            to="/docs/intro">
+            Docusaurus Tutorial - 5min ⏱️
+          </Link>
+        </div>
+      </div>
+    </header>
+  );
+}
+
+export default function Home(): ReactNode {
+  const {siteConfig} = useDocusaurusContext();
+  return (
+    <Layout
+      title={`Hello from ${siteConfig.title}`}
+      description="Description will go into a meta tag in <head />">
+      <HomepageHeader />
+      <main>
+        <HomepageFeatures />
+      </main>
+    </Layout>
+  );
+}

src/pages/index.module.css

@@ -0,0 +1,23 @@
+/**
+ * CSS files with the .module.css suffix will be treated as CSS modules
+ * and scoped locally.
+ */
+
+.heroBanner {
+  padding: 4rem 0;
+  text-align: center;
+  position: relative;
+  overflow: hidden;
+}
+
+@media screen and (max-width: 996px) {
+  .heroBanner {
+    padding: 2rem;
+  }
+}
+
+.buttons {
+  display: flex;
+  align-items: center;
+  justify-content: center;
+}

src/pages/markdown-page.md

@@ -0,0 +1,7 @@
+---
+title: Markdown page example
+---
+
+# Markdown page example
+
+You don't need React to write simple standalone pages.

tsconfig.json

@@ -0,0 +1,8 @@
+{
+  // This file is not used in compilation. It is here just for a nice editor experience.
+  "extends": "@docusaurus/tsconfig",
+  "compilerOptions": {
+    "baseUrl": "."
+  },
+  "exclude": [".docusaurus", "build"]
+}