Looking Back: What I Set Out to Do
When I began this journey in September, I wanted to create an educational game that didn’t feel like one — something that would teach players about AI’s environmental impact through experience rather than lectures. As I wrote in my first entry, my goal was for “players to have fun, explore, and mess around… gaining knowledge without even realising it.”
Now, several months and countless late nights later, I can reflect on what worked, what didn’t, and what I’ve learned through this practice-as-research journey.
What Worked Well
✅ The Core Mechanic: Manual vs. AI
The central “choose between manual work or AI assistance” mechanic successfully embodies procedural rhetoric. By making AI the easier option with hidden consequences, the game’s rules themselves make an argument about convenience versus sustainability.
Evidence: Playtesters naturally gravitated toward the AI option initially, then expressed surprise and guilt when they discovered the consequences. This emotional response suggests the mechanic is working as intended.
✅ Visual Design & Atmosphere
The pixel art aesthetic struck the right balance between approachability and professionalism. As predicted by Risley et al.’s (2025) research on abstraction in serious games, the stylized visuals prevented the office setting from feeling “dull or uncomfortably close to real-life work.”
✅ Technical Integration
Building both the game prototype and this development log as a unified web project was ambitious, but successful. It demonstrates proficiency with modern development tools (Godot, Astro, React, Tailwind) while creating a cohesive portfolio piece.
What Needed Improvement
⚠️ Tutorial & Onboarding
The Problem: Multiple playtesters and my professor noted confusion about controls and how to access minigames.
Why It Happened: As the developer, I knew the controls instinctively. I failed to recognize that first-time players needed explicit guidance.
The Lesson: User testing early and often is crucial. What’s obvious to the creator is rarely obvious to the player.
The Solution: I’ve now documented plans for visual interaction prompts (“Press E”) and contextual tooltips, as detailed in my Entry 10.
⚠️ Environmental Theme Connection
The Problem: The professor identified a gap between the environmental themes and the actual gameplay mechanics, specifically questioning how word sorting connected to environmental issues.
Why It Happened: I prioritized getting a working minigame over ensuring it perfectly aligned with the game’s message. The sorting mechanic was technically achievable, so I built it without fully considering thematic coherence.
The Lesson: In serious games, mechanics must embody the message. Technical feasibility shouldn’t override thematic alignment.
The Solution: The wind farm site assessment minigame (Entry 11) directly addresses this by making environmental evaluation the core gameplay task.
⚠️ Difficulty Scaling
The Problem: The current minigame doesn’t have a clear progression of challenge.
Why It Happened: I focused on getting one version working before thinking about variation and escalation.
The Lesson: Replayability and progression should be considered from the start, not added afterward.
The Solution: Multi-dimensional scaling system documented in Entry 12.
Unexpected Challenges
The “Tutorial Loop” Frustration
I spent weeks stuck on basic Godot problems, watching the same tutorials repeatedly before the solution finally clicked. This cycle repeated multiple times. Initially frustrating, this process taught me:
- Persistence matters more than immediate understanding
- Taking breaks provides fresh perspective
- Sometimes the answer was there all along; I just wasn’t ready to see it
This mirrors the broader learning process: expertise comes from struggling through problems, not from having everything come easily.
The Scope Management Challenge
I initially envisioned multiple endings, complex NPC relationship systems, and elaborate basement revelations. Reality constrained these ambitions. Learning to scope appropriately for a semester-long project was crucial.
Key Insight: A polished, cohesive prototype is more valuable than an ambitious but incomplete project. The core mechanic matters more than feature quantity.
How Feedback Shaped the Project
Academic Feedback Impact
My professor’s assessment identified three critical gaps:
- Need for better tutorials
- Stronger environmental theme connection
- Clarity on difficulty scaling
Each of these prompted substantive design iterations documented in Entries 10-12. This feedback validated the practice-as-research approach: external critique drives meaningful refinement.
Peer Playtesting Impact
Watching friends struggle with controls I found intuitive was humbling and educational. Their confusion directly led to:
- Control instructions on the game page
- Plans for in-game prompts
- Clearer task objectives
Theoretical Framework Impact
Applying the Triadic Model (Harteveld & Kortmann, 2009) and procedural rhetoric (Bogost, 2007) wasn’t just academic exercise — these frameworks provided concrete design guidance. When making decisions, I could ask: “Does this serve Reality, Meaning, or Play? Does this mechanic argue through its rules?”
What I’m Most Proud Of
1. Creating Something That Works
Building a functional game from scratch, with no prior game development experience, while simultaneously maintaining an academic development log, is an achievement I’m genuinely proud of.
2. The Pixel Art
Every character, every tile, every animation came from my own hand (and countless hours in Aseprite). The visual identity of Bird Corp is entirely original.
This development log itself is a significant achievement — a custom-built Astro site with proper routing, content collections, and responsive design. The project demonstrates full-stack capabilities beyond game development.
4. Intellectual Honesty
I could have hidden the prototype’s flaws. Instead, I documented them transparently, showing both successes and failures. This honesty makes the development log more valuable as a learning artifact.
What I Would Do Differently
Start User Testing Earlier
I should have gotten playtesting feedback after building the basic movement system, not after completing the first minigame. Earlier feedback would have caught the control confusion sooner.
Prototype the Minigame First
Rather than building the entire office environment before creating any minigames, I should have prototyped the core task mechanics first to ensure they aligned with the environmental themes.
Document Problems in Real-Time
Some entries were written retrospectively. Writing during struggles (not just after solving them) would have captured the emotional reality of the development process more authentically.
Plan for Scaling from Day One
Thinking about difficulty progression and replayability from the beginning would have made implementing these features easier.
What’s Next: Future Development Plans
While this prototype represents the scope for this academic project, Bird Corp has potential for further development:
Short-Term Improvements
- Implement the tutorial system (Entry 10)
- Add the wind farm assessment minigame (Entry 11)
- Implement difficulty scaling (Entry 12)
- Fix documented bugs (Entry 9)
Long-Term Vision
- Multiple endings based on player choices
- Expanded NPC relationship system
- Full basement revelation sequence
- Additional office tasks beyond meeting notes
- Mobile-friendly version
Reflections on Practice as Research
This project validates practice-as-research methodology. By making the game, I learned things no amount of reading could teach:
- How game engines structure logic differently than web frameworks
- Why pixel art animation feels fluid at certain frame rates
- How players interpret ambiguous UI elements
- The difference between designing for myself versus for others
"The artefact is the research" — Through building Bird Corp, I've not only created a playable game but generated knowledge about serious game design, environmental education, and the challenges of embodying abstract concepts in interactive systems.
Final Thoughts
Bird Corp isn’t perfect. It’s a prototype with rough edges, incomplete features, and areas needing improvement. But it represents genuine learning, creative growth, and the messy reality of making something from nothing.
I set out to create an educational game that teaches through play rather than preaching. While there’s room for improvement in executing that vision, the foundation is solid. The core mechanic works. The art style succeeds. The theoretical framework provides genuine design guidance.
Most importantly: I’ve learned that making games is hard, rewarding, frustrating, and deeply satisfying — often all at once.
If even one player leaves Bird Corp slightly more aware of AI’s environmental costs, if even one person thinks twice before automatically choosing the “AI Assistant” button, then this project has succeeded in its goal.
Acknowledgments
This project wouldn’t exist without:
- My professor for pushing me to strengthen the environmental connection and providing thoughtful critique
- My playtesters for their honest confusion and valuable feedback
- The Godot community for countless tutorials and forum answers
- YouTube creators whose tutorials I watched dozens of times
- Coffee for keeping me functional during 5-hour sleep nights
And to anyone reading this development log: thank you for following along on this journey.
