Gnomebrew's Game Vision

Gnomebrew's first devlog focused on a few general thoughts I had going into the project. With those out of the way it's well time I outline the big picture of the game.

Inspiration

As for every piece of art, other art came before it and influenced the creator and creation - willingly or unwillingly.

To minimize bias and to sort my own thoughts, I'm listing games that seem relevent to me going into Gnomebrew's development process:

Universal Paperclips

This is the most fun I had playing an idle game. It does a lot well, but to explain why is to spoil the game. It's completely free and I urge you to have a go and play it. Depending on how easily a game can take over your life, you might want to wait for the weekend.

Tabletop RPGs

Especially when it comes to Gnomebrew's setting, this genre gives a good frame. While Gnomebrew will not have traditional RPG mechanics (such as player level/skill/class), the game will contain elements of improvement through upgrades.

The sense of 'growth' that RPGs provide is welcome in Gnomebrew. Here, TTRPGs really shine with real orders of magnitude in (spell) effects: Leveling up doesn't just mean 'more damage' or 'larger AOE'; instead, leveling up can unlock effects (like spells) that can completely change how to approach challenges. Once you know how to fly, you don't need to climb anymore.

Dwarf Fortress

Truly an epic game and to say I understand it well would be an overstatement. Nonetheless I know what fascinates me about Dwarf Fortress: Depth over presentation. Dwar Fortress simulates a fictional reality to an extent that has not been met remotely by others (I think this video provides a good first-time introduction to understand the game concept rather than the complex gameplay; if nothing else, just watch the 3 minute video opening to get a feeling for the depth this game brings to the table).

While Gnomebrew is a fundamentally different game, I find the astonishing effort in simulation magic (that a 'casual' player would not notice for hundreds of play hours) inspiring. I want to have a few deep dives myself.

Stardew Valley

I have the fondest memories of Stardew Valley playing with my fiance.

The farm management game provides an extraordinarily stress-free gameplay experience, where every action you make brings slow progress and even repetitive tasks bring intrinsic joy. Among hundreds of other activities, brewing and selling beer is also possible here.

The fact that Stardew Valley has been developed by one person is certainly a boost of motivation for me to tackle Gnomebrew by myself.

Factorio

This game has taken hundreds of hours of my lifetime and I don't regret a single one.

Factorio sees you produce an ever growing arsenal of materials and products from a very limited amount of base resources (in vanilla the grand total of base resources is seven if I'm not mistaken). The complexity this creates is quite magnificent for a first-time player. It brings with it a solid learning curve that facilitates practicing and engineering mindset.

I want Gnomebrew to be enjoyed easily without consulting a wiki. Hence, I don't want to take much from Factorio's fundamental experience. However, the material crafting chain sounds fun to me. I'd love to see if I can get this into an idle game experience.

Gnomebrew's Fundamental Gameplay

Listing an inventory of games is a reasonable starting point: It gives me some bias awareness (my previous game experiences influence my perception) and also provides comparison and contrast for my understanding of what kind of game Gnomebrew will be.

Before I started writing devlogs, I already had a general sense of what I want the game to be like:

• Sell Beer to Patrons in your bar. This way you generate gold (the game's main currency).
• Set the price of your products to change beer demand of your patrons.
• Produce Beer by executing the necessary crafting recipe. This requires waiting out the crafting time and the necessary crafting ingredients
• Upgrade various bottlenecks of this gameplay loop (e.g. patron capacity, crafting time, patron beer demand) to increase profitability. Upgrades are also implemented as crafting recipes (e.g. improve your tables for 500 wood, 6000 gold, and 6 hours; this increases demand by 5%).
• Unlock new mechanics through recipes (e.g. build a divination table) that gradually enable you to do .

This is - generally speaking - the game I want to implement. This description of course is not enough to implement a game. Before defining details of Gnomebrew, I want to take two steps back and look at the game from the most abstract perspective:

High-Level Gameplay Experience

On the highest level, games are experiences. Here my general design objectives for The Gnomebrew Experience:

Surprise

Prior to playing Universal Paperclips, I would not have expected the richness of mechanics that unfold during playtime. Experiencing game mechanics shift and expand was a big factor in why this game stayed in my memory.

Gnomebrew should surprise the player by successively introducing new mechanics throughout different stages of the game, much like (Table Top) RPGs do with their concepts of 'growth' beyond higher numbers and fictional worlds that become larger and more complex as playtime progresses.

This poses the challenge of not overwhelming the player throughout different stages of the game, especially when considering longer playtime breaks and re-learning becomes necessary. This challenge can be addressed through pacing and automation options that ease player burden on old mechanics, thus making space for new mechanics

No Hassle

Gnomebrew will have some mechanical richness. Playing the game should however cause no stress (necessarily). I envision Gnomebrew to be something any player can enjoy at their own pace. Penalties (e.g. for not performing an action 'in time') should therefore be minimal.

Especially at the early-game, I can see a few such elements adding value, for example not serving patrons in time could cause them to leave. Such a mechanic loses its appeal fast (as players should not stay glued to the game indefinitely), so automation should remove such penalties early, for example hiring someone to automatically serve patrons.

Fucking up = Impossible

Gnomebrew allows players to make decisions (e.g. by prioritizing upgrades to purchase). Typically, 'unwise' decisions in games backfire (e.g. deciding to send a plant type to battle a fire type will most probably cause you pain).

In Gnomebrew, player decisions will not cause negative impact on the game. Instead, the worst that can happen is 0% benefit (e.g. when upgrading the patron capacity of a tavern nobody visits). With that, every upgrade is a (small or big) step towards increasing productivity and completing Gnomebrew.

Ideation: Game Mechanics Overview

In addition to the big picture, I can also approach the game from a more hands-on perspective and think about what kind of mechanics I would like to see in the game. The result of my first mechanics ideation is:

• An in-game Economy regulates supply and demand of items
• Patrons have available budget and personality defining what (and how much) they intend to purchase from the player
• A Market allows the player to acquire basic resources (like barley for beer). A limited market supply could create interesting dynamics.
• Get water from a Well. Just a regular well, nothing suspicious about it (or is there...?).
• To safe time, the player can hire Staff that take over (i.e. automate) tasks for the player. Don't want to manually get water from the well? Hire someone to do it for you!
• A Quest Blackboard allows the player to ask for specific items and name their reward.
• A Divination Table allows to gain intel and receive insights.
• The Workshop allows upgrading.
• Set the price for your various beery beverages and influence demand.
• Crafting Recipes codify most player actions (brewing beer, upgrades, etc.) and each consist of:
  • the station on which the recipe will occupy a slot (e.g. the brewery or the workshop)
  • material components the recipe consumes (e.g. 500 wood, 400 gold)
  • a crafting time, after which the recipe is completed (e.g. 2 hours)
  • the result, which is unlocked or added to the inventory after recipe completion

Where to go from here: Iteration

Is this the right design direction? I don't know. More importantly, this outline is a good starting point to create something entertaining.

I can only know how fun the game will actually be as I'm experiencing the gameplay myself (or have playtesters do this with me). For this, my aim is to create the game in small, playable iterates. This allows for solid testing and QA during development.

However, before I run through this cycle an indeterminate amount of times, I want to make sure that this system has a solid foundation. I think now is the time to get started creating something...