Under the Mountain: An Indie Game Development Chronicle
December 20, 2025, 4:30 am
An indie development team navigated the intense Gaminator 28 game contest, creating the platformer "Under the Mountain." This article chronicles the programmer's perspective, detailing project initiation, team formation, and the challenging concept phase. Key hurdles emerged from an expansive vision, including scope creep, evolving team roles, and intricate communication over a "Monster-Table" design document. The project leveraged GameMaker, facing technical implementation issues like FMOD integration and the necessity of building generic systems due to delayed specific content. Developer burnout became a critical factor as features constantly expanded, pushing deadlines. Ultimately, despite a contest extension and individual exhaustion, the collaborative team delivered the game. This endeavor highlights both the complexities and rewarding outcomes inherent in hobbyist game development and team project management.
Indie game development presents unique challenges. This project, "Under the Mountain," emerged from the Gaminator 28 contest. It represents a significant team effort. The programmer, DarkDes, typically works alone. This time, a cooperative venture took shape. Past collaborations saw DarkDes primarily as a graphic artist. For "Under the Mountain," a new role emerged: lead programmer. This account offers one team member's unique view.
The journey began before Gaminator 28. It started with a small graphics asset contest. Kot211, a participant, found inspiration. He decided to create a full platformer game. Discussions began between DarkDes and Kot211. They exchanged ideas. News of Gaminator 28 then surfaced. User Anim86 announced the competition. The duo decided to build their game for this contest. Their roles were clear: DarkDes would program, Kot211 would handle graphics and levels.
The contest theme arrived. It did not immediately inspire. Soon after, Scorched joined the nascent team. He offered his skills for sound design. Kot211 then established a Telegram chat. The core team was now formed. Kot211 focused on graphics, levels, story, and project vision. DarkDes managed programming and all technical aspects. Scorched created sounds, selected music, and contributed original tracks.
Initial team communication proved intense. Messages flowed quickly. DarkDes noted a prior platformer, "Red Robot," as a potential foundation. That older project became a practical starting point. Game conception commenced. Kot211 largely drove the gameplay and narrative. Other team members provided input. Core ideas included a robot protagonist, ancient ruins, and a platformer genre. This established the project's foundational pillars.
Early discussions dominated. The team communicated extensively on game concepts. DarkDes pushed for a concise resource and task list. Such a list would clarify scope and complexity. This method proved successful in his solo projects. Kot211 instead developed an extensive "Monster-Table." This document spanned multiple sheets. It detailed game vision, resources, sounds, music, and graphics. The table aimed for comprehensive planning. Yet, navigating it proved difficult. It functioned as a beat-chart for levels and mechanics.
Discussions continued. Scorched expressed concerns about the project's scale. He feared they would miss the deadline. DarkDes shared this worry. He proposed finishing the game in two weeks. This would prioritize essential features. Polishing would follow. The ambitious two-week target was not met. The team indeed missed the original contest deadline.
Development proceeded. The core game idea and plot were in place. DarkDes started building the platformer base. GameMaker was the chosen engine. Both DarkDes and Kot211 were familiar with it. DarkDes leveraged prior work. His "Platforman 2" project became the new game's foundation. "Platforman 2" served as a hub. It contained reusable scripts and objects for future platformers. DarkDes envisioned a grander "Framework" project. This would globally track his GameMaker code base. It aimed to solve module and script tracking issues.
Specifics remained elusive. DarkDes created to-do lists for the base platformer. He expected concrete details to emerge. However, concepts, like enemy types, stayed vague. This made implementation challenging. Building systems for undefined elements proved frustrating.
Scorched initially suggested FMOD for audio. DarkDes explored this option. He downloaded the official GameMaker extension. He soon doubted its utility. FMOD's complexity seemed unnecessary for simple sound playback. Features like layered sounds were interesting. But integrating even one sound required significant code. DarkDes deemed it overkill. The team opted for standard GameMaker sounds. DarkDes built a custom sound script. It featured `ffx_` functions. These allowed Scorched flexibility. DarkDes integrated them into game logic. This system was designed for future expansion, beyond just sound effects.
Scorched possessed programming skills. He quickly adapted the sound functions. He requested a sound playback limiter. This prevented overlapping audio. For example, only four gunshots could play simultaneously. These programming skills proved valuable.
Roles were defined early. DarkDes handled technicals. Kot211 managed graphics, levels, and story. Scorched covered audio. DarkDes initially assumed Kot211 would implement cutscenes. He expected this via his code-based system. It required writing action sequences as functions. This proved not to be the case. DarkDes became responsible for cutscene implementation too. This added to his workload.
Content dependency became a major issue. DarkDes often developed generic systems. He worked on "playground" test levels. Specific game levels or detailed scenarios were absent. He could not create a cutscene for Level 1 if Level 1 did not exist. Much effort went into an "ephemeral" set of features. These elements often faced revision. This felt inefficient.
A turning point arrived. DarkDes experienced burnout. The feature list constantly grew. A finished game remained out of sight. Tasks closed, yet new demands surfaced. The "must-do" list expanded relentlessly. This experience clarified Scorched's reluctance to program in contests. Unclear initial definitions led to constant reworks. The iterative process became a burden. Significant development time went into discussions. Assumptions about clarity proved false. Coding continued from sheer willpower. DarkDes prioritized completion over perfection. The current approach, he felt, jeopardized finishing.
Team dynamics felt strained. DarkDes perceived a disproportionate workload. He felt he contributed everything. Others seemed to contribute less. He acknowledged not knowing their full efforts or real-life constraints. Kot211, for instance, worked intensely on graphics in the final days. Sleep became a luxury. The deadline loomed large. DarkDes's certainty of failure solidified.
The contest received an extension. One extra week was granted. DarkDes had expressed resistance to an extension. Yet, he found renewed strength. He created new task lists. Focus returned. This strategy helps manage large projects.
Hobbyist contests differ from commercial ventures. Expectations vary. The project's sheer volume posed the primary challenge. Would a strong project leader, reducing scope, have helped? It is uncertain. Perhaps a timely completion. Perhaps a hollow game. Solo development offers singular accountability. Team projects introduce complex dynamics. This collaboration, while challenging, yielded a complete game. It underscored the realities of indie game creation. The experience highlights the need for clear scope and flexible teamwork. It reveals the emotional toll on developers. Yet, the final product signifies a triumph of collaborative spirit.
Indie game development presents unique challenges. This project, "Under the Mountain," emerged from the Gaminator 28 contest. It represents a significant team effort. The programmer, DarkDes, typically works alone. This time, a cooperative venture took shape. Past collaborations saw DarkDes primarily as a graphic artist. For "Under the Mountain," a new role emerged: lead programmer. This account offers one team member's unique view.
The journey began before Gaminator 28. It started with a small graphics asset contest. Kot211, a participant, found inspiration. He decided to create a full platformer game. Discussions began between DarkDes and Kot211. They exchanged ideas. News of Gaminator 28 then surfaced. User Anim86 announced the competition. The duo decided to build their game for this contest. Their roles were clear: DarkDes would program, Kot211 would handle graphics and levels.
The contest theme arrived. It did not immediately inspire. Soon after, Scorched joined the nascent team. He offered his skills for sound design. Kot211 then established a Telegram chat. The core team was now formed. Kot211 focused on graphics, levels, story, and project vision. DarkDes managed programming and all technical aspects. Scorched created sounds, selected music, and contributed original tracks.
Initial team communication proved intense. Messages flowed quickly. DarkDes noted a prior platformer, "Red Robot," as a potential foundation. That older project became a practical starting point. Game conception commenced. Kot211 largely drove the gameplay and narrative. Other team members provided input. Core ideas included a robot protagonist, ancient ruins, and a platformer genre. This established the project's foundational pillars.
Early discussions dominated. The team communicated extensively on game concepts. DarkDes pushed for a concise resource and task list. Such a list would clarify scope and complexity. This method proved successful in his solo projects. Kot211 instead developed an extensive "Monster-Table." This document spanned multiple sheets. It detailed game vision, resources, sounds, music, and graphics. The table aimed for comprehensive planning. Yet, navigating it proved difficult. It functioned as a beat-chart for levels and mechanics.
Discussions continued. Scorched expressed concerns about the project's scale. He feared they would miss the deadline. DarkDes shared this worry. He proposed finishing the game in two weeks. This would prioritize essential features. Polishing would follow. The ambitious two-week target was not met. The team indeed missed the original contest deadline.
Development proceeded. The core game idea and plot were in place. DarkDes started building the platformer base. GameMaker was the chosen engine. Both DarkDes and Kot211 were familiar with it. DarkDes leveraged prior work. His "Platforman 2" project became the new game's foundation. "Platforman 2" served as a hub. It contained reusable scripts and objects for future platformers. DarkDes envisioned a grander "Framework" project. This would globally track his GameMaker code base. It aimed to solve module and script tracking issues.
Specifics remained elusive. DarkDes created to-do lists for the base platformer. He expected concrete details to emerge. However, concepts, like enemy types, stayed vague. This made implementation challenging. Building systems for undefined elements proved frustrating.
Scorched initially suggested FMOD for audio. DarkDes explored this option. He downloaded the official GameMaker extension. He soon doubted its utility. FMOD's complexity seemed unnecessary for simple sound playback. Features like layered sounds were interesting. But integrating even one sound required significant code. DarkDes deemed it overkill. The team opted for standard GameMaker sounds. DarkDes built a custom sound script. It featured `ffx_` functions. These allowed Scorched flexibility. DarkDes integrated them into game logic. This system was designed for future expansion, beyond just sound effects.
Scorched possessed programming skills. He quickly adapted the sound functions. He requested a sound playback limiter. This prevented overlapping audio. For example, only four gunshots could play simultaneously. These programming skills proved valuable.
Roles were defined early. DarkDes handled technicals. Kot211 managed graphics, levels, and story. Scorched covered audio. DarkDes initially assumed Kot211 would implement cutscenes. He expected this via his code-based system. It required writing action sequences as functions. This proved not to be the case. DarkDes became responsible for cutscene implementation too. This added to his workload.
Content dependency became a major issue. DarkDes often developed generic systems. He worked on "playground" test levels. Specific game levels or detailed scenarios were absent. He could not create a cutscene for Level 1 if Level 1 did not exist. Much effort went into an "ephemeral" set of features. These elements often faced revision. This felt inefficient.
A turning point arrived. DarkDes experienced burnout. The feature list constantly grew. A finished game remained out of sight. Tasks closed, yet new demands surfaced. The "must-do" list expanded relentlessly. This experience clarified Scorched's reluctance to program in contests. Unclear initial definitions led to constant reworks. The iterative process became a burden. Significant development time went into discussions. Assumptions about clarity proved false. Coding continued from sheer willpower. DarkDes prioritized completion over perfection. The current approach, he felt, jeopardized finishing.
Team dynamics felt strained. DarkDes perceived a disproportionate workload. He felt he contributed everything. Others seemed to contribute less. He acknowledged not knowing their full efforts or real-life constraints. Kot211, for instance, worked intensely on graphics in the final days. Sleep became a luxury. The deadline loomed large. DarkDes's certainty of failure solidified.
The contest received an extension. One extra week was granted. DarkDes had expressed resistance to an extension. Yet, he found renewed strength. He created new task lists. Focus returned. This strategy helps manage large projects.
Hobbyist contests differ from commercial ventures. Expectations vary. The project's sheer volume posed the primary challenge. Would a strong project leader, reducing scope, have helped? It is uncertain. Perhaps a timely completion. Perhaps a hollow game. Solo development offers singular accountability. Team projects introduce complex dynamics. This collaboration, while challenging, yielded a complete game. It underscored the realities of indie game creation. The experience highlights the need for clear scope and flexible teamwork. It reveals the emotional toll on developers. Yet, the final product signifies a triumph of collaborative spirit.