Why Frontworks

Welcome all, I am happy to have you here! As you probably know, this game is about building a factory, expanding it, defending it and commanding troops.

The idea came when I was working on my bachelor thesis. I started creating a city sim, inspired by Dwarf Fortress and my interest in building an ant sim. I then thought maybe the ants should be robots. Maybe robot ants should do automation stuff. I then spent a year creating this strange hybrid, where you manage the needs of the ants who build a factory — for no particular reason, only that they get money selling the stuff they produce. I got bored pretty fast, so I decided to add enemies who spawn and attack your base, and turrets. Now the best thing to do in that game was defending your base, but it was still lacking something, so I added soldier ants. The most fun I had with the game then was moving these soldiers around and sending them to fight mindless enemies.

The most annoying thing was that the logistics were managed by logistic ants, which moved items around the base. Also, being hexagonal didn’t help — there are good hexagonal tile games out there, but for my game it just didn’t click. Instead of refactoring the existing codebase into what I wanted, I decided to start another project — and this is how Frontworks started.

I am building this game because I believe this is the next step of the automation games. It makes too much sense to build and expand the factory serving a military purpose: now there is a real reason why you are here, why you are researching this tech and why you must have a gazillion machines producing bullets.

Game technical foundation

This being a devlog (without a real focus — I won’t start writing all the small things I’ve done for the past year in the development of the game), I want to share some technical stuff.

I used Unity because that is what I am most familiar with. After some months, I decided I want to go big — tens to hundreds of thousands of items moving on the belts, a few thousand buildings working and my real goal: 20,000 troops at once on the screen.

With these numbers, I had to get creative and approach every architectural decision with optimisation in mind. I started learning Unity DOTS, which gives you an ECS and lets you write parallel jobs properly. Animation was the next big problem: classical animation runs on the CPU, and with my numbers it simply wouldn’t work. There are many ways to do this, but I went with integrating a custom VAT pipeline into DOTS. This let me have 10,000 animated meshes on the screen at the same time with minimal overhead. From there on, I started adding content: working machines, belts, inserters, and troops. Here I am now.

What is next

I plan to post devlogs every 2-4 weeks. I am working Agile, so a devlog will be published at the end of every sprint — at least, that is the plan.

Features I want to implement next sprint:

• Add bug bases that spawn randomly and start attacking your base.
• Base upgrades. A new building must be added, and to apply an upgrade you must feed that building the required materials.
• Bug fixing. When you select a building on the map, it gets highlighted. For some reason, some highlights stay active even when the mouse is no longer hovering over that building.

The roadmap contains more features that will be added in the future.

If you want to know when the demo is playable, you can join the Discord or subscribe to the newsletter.