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.
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:
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.
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.
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.
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.
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.
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:
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:
On the highest level, games are experiences. Here my general design objectives for The Gnomebrew Experience:
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
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.
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.
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:
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...