The Making of Machineers

These are general indie benchmarks from Algoryte’s game development timeline and Gravity Labs’ overview of indie timelines, not dates tied to one studio.

How was Machineers made? As an indie puzzle game on Android and iOS, it sits in a pipeline of prototyping, production, device testing and post-release patches, and multi-platform builds lengthen production.

The machineers game page gives the overview of the title. This article follows the production route behind a mobile puzzle game like it, starting with the decisions that shape the schedule.

What the production timeline means for a mobile puzzle game

A few decisions made early shape the rest of the schedule of an indie puzzle game. Each one affects how much time the team needs and when problems surface.

• Prototype before building content. Prototyping helps developers identify problems early, according to Algoryte’s production timeline, and Gravity Labs notes that experienced teams are much better at rapid prototyping. In a puzzle game a single mechanic carries the design, so a rough playable build is the sensible place to learn whether that mechanic holds up. A team with less prototyping experience should leave more room in the early stage.
• Match scope to the team. Gravity Labs says most indie games need at least 1–2 years of dedication, while Algoryte puts a mid-sized indie game at 6–18 months. The two benchmarks overlap, so plan around the longer end unless the scope is deliberately small.
• Budget for each extra platform. Algoryte states that developing for multiple platforms (PC, console, mobile) increases game production time. Targeting both Android and iOS falls under that principle, so the platform list belongs in the plan from the start rather than being added late.
• Plan for support after launch. Algoryte is plain that game development does not end after release, because patches follow. A schedule that stops at the launch date leaves no room for fixes.

These decisions are made on paper and in prototypes long before a build ships, which is where the design stage begins.

Design and prototyping

Pre-production

Pre-production has the shortest range of any stage in Algoryte’s model, at 1–3 months, and it is where planning happens before full production starts. For a puzzle game this is the stage to fix the rules, the structure of the puzzles and the technical requirements, because changing them later means reworking everything built on top.

Vertical slice

Gravity Labs says 3–6 months could be enough for a vertical slice of a small-scope game. A slice gives a small team something playable to put in front of testers, which is more useful than a pitch for judging whether the puzzle loop is satisfying. It also gives a natural checkpoint: if the slice is not working, that is the cheapest time to change course.

The slice stage is where an experienced team’s speed shows most clearly. A team that prototypes quickly can try several versions of a mechanic inside that window and keep the one that works.

Engine and platform choices

Engine choice is mostly a decision about time. Algoryte notes that modern game engines such as Unity and Unreal Engine can speed up development, and Gamespace observes that engine tools dropped the tinkering hurdles to making games. Gamespace also points to Braid, released in 2008, as an early digital indie success, and that history explains why small teams can now ship polished titles.

For a small team this means building on an established engine instead of writing core systems from scratch, which leaves more of the schedule for puzzle design. A puzzle game with physics-style interactions gains most when the engine already handles the basics and the team spends its effort on level design.

Android and iOS both belong to the mobile category in Algoryte’s list of platforms. Shipping on both means the build has to be adapted and verified for each, and that is where the added production time comes from. A studio that adds a platform late should expect the extra work to land in the testing stage.

Testing and post-release updates

Testing is a distinct stage, not a final polish. Algoryte gives testing and quality assurance a range of 2–6 months and lists compatibility testing across devices as part of it. For a game on Android and iOS, that means confirming the same puzzles behave correctly across phones and tablets, not only on the device the developers use daily.

Early prototyping and later QA do different jobs. Prototyping surfaces design problems while changes are still cheap, and QA then confirms that the finished build works on the devices players own. Relying on QA alone to catch design flaws leaves the team making large changes at the point where the schedule has least room.

Algoryte’s point that development continues after release through patches shapes how a launch should be read. A published version is a starting point for fixes and updates, and a studio that keeps patching a puzzle game is following normal practice rather than correcting a failed launch.

More on the game and its studio

One specific part of the game is covered in the machineers waterplant harvester article. The team behind the title is covered in the profile of lohika games.

Frequently asked questions