Announcing Gnomebrew

Hunting ancient artifacts, venturing through unknown lands, facing daring encounters, saving villagers in need...

This and more is what your patrons will discuss while you're serving them up in the fantasy tavern you manage in Gnomebrew, an idle game that has you on a mission to grow your small tavern into the hottest location in the multiverse!

I will develop Gnomebrew - at least to some level of completion - and document the game's development in devlogs.

My Motivation

Gnomebrew is a passion project. I'm personally driven to work on because I seek:

• Learning: This project requires applying a broad skill spectrum. From design to code, from back- to frontend; Gnomebrew is a an excellent vehicle for learning.
• Crafting a Fun Experience: I want to craft a game I would wholeheartedly enjoy playing myself.

Open Source

I will manage the entire project open-source. I feel personally indebted to the open source community for its amazing technologies; many of which are essential for me to develop the game in the first place. Additionally, I have no incentive (other than monetization) to keep the code secret.

I will manage the project's source files in a public GitHub-repository which are published under GNU GPL License.

Monetization

Monetization can greatly affect a game's design, especially if the product's revenue generation is intertwined with the mechanics.

I would like to keep Gnomebrew 'pure' to a maximum extent:

• No Ads: I don't like ads. This introduces elements into the game that compete for player attention and generally annoy users.
• No In-Game Transactions: Other than the technical challenges that come from microtransactions, these mechanics tend to create two player classes: those that pay - and enjoy advantages - and those that don't. I prefer providing any player with a fundamentally level gameplay experience. While cosmetic in-game purchases would be a fair compromise, my vision for the game leaves little space for varied visuals.

Additional Constraints

Constraints enable more focused design work by reducing the decision space. Here are contraints for Gnomebrew that I'm already clear on:

No behavioral player conditioning

Especially in mobile games, elements like daily rewards have become a staple. They facilitate habit forming of players and generally aim to increase 'engagement'. As an idle game, Gnomebrew implicitly asks players to 'come back to play' in between play sessions because idle progress happened in the meantime. This is the only incentive Gnomebrew provides for logging in.

Everything happens server-sided

Gnomebrew's logic and mechanics will run on the server. Players interact through atomic transactions with the server.

This enables Gnomebrew to keep 'working' for the player even when they are logged off (as game timers just keep running independently of the player's login-state).

Additionally, this minimizes my efforts to ensure integrity; the only way to interact with the game will be the atomic transactions, which are significantly easier to hack-proof compared to an entire game logic loop running on the user's machine.

Project Scope

Gnomebrew is a project that comes with a broad scope. I will probably write logs that touch on:

• Application Development for implementing Gnomebrews's heart and soul
• Game Design and Design Thinking for defining the concepts to be implemented
• Server Administration for setting up the infrastructure to run the game
• Webdesign for developing a web-based frontend
• Graphic Design for developing a general visual direction and game assets

Certainly, more topics might pop up during development (I have a feeling Economics will be one them. I'll try to keep future devlogs focused on individual topics as much as possible.

And with this, Gnomebrew's preamble is as complete as can be. Now it's time to get to the drawing board...