The machineers development blog is best read by theme first and by date second: pick the topic that matches your question, then read the posts on it from oldest to newest. This page sorts the blog into those themes.
For the project itself, the machineers game overview explains what the blog is documenting. The sections below then show which kind of post answers which kind of question.
How to choose a theme
No theme here outranks another. The right starting point depends on what you want to know, so the themes are presented as an ordered selection that moves from design detail to the studio’s current status. Three criteria decide where to begin.
- Type of question. A question about how a puzzle works belongs with the design posts. A question about timing belongs with the planning posts. A question about whether the game can be obtained today belongs with the status material.
- Appetite for the whole story. Readers who want the project’s arc get more from reading one theme in date order than from sampling single posts. Readers with a narrow question are better served by going straight to the matching theme and stopping once it is answered.
- Tolerance for dated information. A devlog records what the team believed on the day it was written. Design reasoning ages well. Schedules and plans age badly, so treat them as a snapshot.
A single index of this kind is useful because there is rarely a ready-made one elsewhere. In November 2017, the Simple Programmer list of software developer blogs noted that, as far as its author knew, no master list of the best software developer blogs existed. Readers therefore usually have to build their own route through a developer’s writing, which is what the themes below do.
The themes in the archive
Level design and mechanisms
This theme covers posts about how individual puzzles and mechanical contraptions are conceived, sketched and refined. It suits players who want to understand why a level behaves as it does, and designers looking for a worked example of puzzle thinking.
Its limit is that design posts describe intent. A sketch or a description in a devlog is not a guarantee that a mechanism shipped in exactly that form, so read these posts as reasoning rather than as a final specification.
Planning and schedules
Planning posts record what the team intended to build and in what order. They suit readers interested in how a small game project is organised, and anyone trying to understand why a feature appeared when it did.
The limit is staleness. A plan written during development describes expectations at that time, not outcomes. Pair any schedule post with a later post on the same subject before drawing a conclusion.
Events and showcases
Posts about events show the game in front of an audience, and they usually carry the most concrete context about where and when the project was presented. The machineers nordic game page gathers that material for one event, so it is the quickest route for readers whose question is about conference appearances.
These posts suit readers tracing the project’s public milestones. They are a weaker choice for design questions, because event writing tends to focus on the occasion rather than on how mechanisms work.
Milestone and anniversary posts
Where a post marks a milestone, such as a blog anniversary, it tends to look back over the whole run of entries. That makes it a good orientation point for newcomers, who can use it to decide which theme deserves a longer read.
Retrospectives compress the story, though, so details get smoothed over. Use them to find your bearings, then follow through to the original dated posts for specifics.
Availability and project status
Readers who arrive with a practical question, such as whether the game can still be played or obtained, should not rely on old blog entries to answer it. Entries written during development cannot reflect later changes. The is machineers still available page is the place to check current status.
Team and studio
Posts about the people and working habits behind the game suit readers curious about how a small team reviews its work and makes decisions together. They add context to the design and planning posts and are best read after one of those themes rather than before.
Themes compared
| Theme | Question it answers | Suits | Planning use |
|---|---|---|---|
| Level design and mechanisms | How does a puzzle work, and why? | Players and designers | Read in date order to follow ideas as they changed. |
| Planning and schedules | What was the team aiming for, and when? | Readers studying project organisation | Treat as a snapshot and check later posts. |
| Events and showcases | Where was the game shown? | Readers tracing public milestones | Go to the dedicated event page first. |
| Milestone and anniversary posts | What has the blog covered so far? | Newcomers | Use for orientation, then open the originals. |
| Availability and status | Can the game be obtained now? | Anyone wanting to play | Check the status page, not old devlogs. |
| Team and studio | Who is behind the game? | Readers wanting context | Read after a design or planning theme. |
The grouping reflects the gap Simple Programmer described in its developer blog roundup, where no single master list of developer blogs was known to exist, so a theme-based route has to be assembled from the blog’s own posts.
Reading the posts in date order
Within any theme, read posts from oldest to newest. A devlog is a running record, and later entries frequently revise, narrow or replace earlier ideas. Starting with the newest post on a topic can hide the reasoning that led there.
Readers short on time can use a two-pass method. Skim the titles and dates within a theme to locate the post nearest the question, then read that post and the one immediately after it. The following entry is where a team usually reports what happened to the idea.
Dates matter for judging weight. A design explanation stays useful long after publication, whereas statements about release timing or availability should be treated as true only on the day they were written.
Which route suits which reader
- Curious players. Start with design posts, then jump to the status page if you want to play.
- Aspiring puzzle designers. Read design and planning posts together, because the combination shows both the idea and the constraints around it.
- Event or press researchers. Go straight to the event material and use the milestone posts to place it in the project’s timeline.
- Completionists. Read everything in date order, using the themes only as a map of what to expect.
Frequently asked questions
What is the Machineers development blog?
It is the running devlog for the Machineers puzzle game, written as dated entries that follow the project as it developed. This page groups those entries by theme so a reader can find the relevant one quickly.
Where should a specific question start?
Match the question to a theme in the comparison table. Design questions go to the level design theme, timing questions to planning, and questions about presentations at conferences to the event material.
Is there a master list of developer blogs to browse instead?
Not as of November 2017, when Simple Programmer stated that, as far as its author knew, a master list of the best software developer blogs did not exist. A themed guide to a single blog is therefore the practical alternative.
Do old devlog entries show the game’s current state?
No. Each entry reflects the day it was written, so later posts and the status page are the better guide to anything that may have changed.