Michael Andonie


Gnomebrew Devlog 3: Groundwork

It is fun dreaming of a game that will be. The path to get there is - in my experience - significantly more demanding, but still as much fun; if you have a Dark Souls level of stress tolerance that is.

Implementing Gnomebrew will be a long and most probably not straightforward endeavor. There will certainly be changes and redesigns along the way. My objective for the first iteration is setting up a bare-bones functional tech stack with minimal functionality.

In this devlog, I'm documenting my project setup.

A quick disclaimer: This won't be perfect.

I'm documenting this project not as a best practice example. There will surely be better ways to solve some of the challenges I address. This is more of a development diary.

Gnomebrew's Tech Stack

I have many options to choose from and my decisions are not guided by efficiency as much as by what technologies I want to practice with this project:

Gnomebrew's Tech Stack

Setting up a project structure

I think I can't stall much longer; now's the time to get to code!

After setting up the GitHub-Repo with presets for license and .gitignore and am cloning into it on my dev computer, I'm starting by setting up a basic project structure:

After this basic setup, this is my (simplified) project structure:

├── assets [empty directory]
├── docker [empty directory]
├── .git
   └─ [...]
├── .gitignore
├── gonemebrew-server
   └── __init__.py [empty file]
├── .idea
   └─ [...]
└── README.md

Flask Application Skeleton

The Gnomebrew-Server Application will be the heart of the game. It manages the (server-sided) gameplay logic and provides players with an interface to receive game info and perform game actions. I'm starting the development by setting up a basic skeleton for this Flask application.

The flask documentation kindly provides me with a (hopefully) fool-proof explanation on how to set up the application package. Based on that, my steps are:

  1. Setting up a templates folder which will house my HTML-templates for the web-frontend.
  2. Renaming gnomebrew-server to gnomebrew_server because dashes are problematic in Python names (the more you know...).
  3. Following the instructions to set up a Hello-World-esque structure.

I now have this basic package setup:

├── index.py
├── __init__.py
├── login.py
└── templates [empty directory]


from flask import Flask
app = Flask(__name__)

# Import functions and with it the routes
import gnomebrewserver.login
import gnomebrewserver.index
# ...


from gnomebrewserver import app

def index():
    return 'Hello World, this is Gnomebrew!'

The tutorial also suggests creating a setup.py, but from my perspective that does not seem necessary (yet).

Running Flask Locally

To test the server locally, I'm following the tutorial's suggestion and use a shell script that's configured to run in my project root:

export FLASK_APP=gnomebrewserver && flask run

Hooray, it works so far:

First view of the game

App Configurations

Flask has a very convenient configuration handling feature.

I will manage configs as Python classes in a dedicated config directory. Since these configs will contain all the sensitive data, I'm adding the content of this folder to my .gitignore.

This slightly extends my not-so-elegant deploy-script:

export FLASK_APP=gnomebrewserver && export GNOMEBREW_CONFIG=/path/to/config.py && flask run

The config will be used to store configurations like the MongoDB-address to use.

The tutorial suggests using default configs and overwriting those with specific configs if available. For Gnomebrew, this has limited use since I don't want to implement a default database.

The skeleton exists now

With that, Gnomebrew has a Flask skeleton to fill with life. It's still a long way to have a running game, so let's continue the coding...