How experience from an overlooked trade became the foundation for Concrete Polishing Simulator
I did not start with a polished plan or a studio full of specialists. I started with a trade I knew, a problem I wanted to solve, and the willingness to rebuild until the game finally felt true.
I did not begin Concrete Polishing Simulator because I had years of professional game development behind me. I began it because I knew concrete polishing. I knew the machines, the stages, the dust, the sound of a grinder under load, the frustration of missing an edge, and the satisfaction of watching a dull slab gradually become reflective. At some point, I looked at that work and realized it contained the bones of a game.
Concrete polishing is a process most people never think about, even when they are standing on the result. It is physical, technical, repetitive, and strangely satisfying. You prepare the slab, make aggressive cuts, move through finer tooling, work the edges, apply chemicals, and finish the surface. Each pass matters. A mistake early in the process can follow you all the way to the end. That combination of visible progress, specialized equipment, and hard-earned knowledge felt perfect for a simulator.
The idea became Concrete Polishing Simulator, or CPS: a hands-on first-person trade simulator about taking real jobs, choosing equipment and supplies, restoring floors, building a reputation, and growing a business. It is also my first commercial game, which meant I was learning how to build the plane while already trying to fly it.
Knowing the Work Was My Starting Advantage
My background is not the traditional route into the game industry. I have worked in concrete polishing and construction, studied IT, built computers, produced music, and spent a lot of time teaching myself how systems work. That made Unreal Engine feel unfamiliar, but not impossible. I was already used to diagnosing problems, learning tools, and figuring things out when there was no clean instruction manual.
The trade experience gave me something just as valuable as technical skill: a filter. When I designed a machine, a floor stage, or a job objective, I could ask whether it resembled the actual rhythm of the work. Does the player understand why this step exists? Does the floor change in a way that feels earned? Does the equipment behave like a tool with weight and purpose, rather than a vacuum cleaner moving over a progress bar?
Authenticity does not mean reproducing every inconvenience of a real job. A completely literal version would often be slow, exhausting, or confusing. My job as the designer is to decide what to preserve. I want the player to feel the sequence, decision-making, equipment progression, and payoff of the trade without requiring years of field experience. That balance—respecting reality while still making a game—has shaped almost every system in CPS.
Starting Over Was Progress
One of the most important decisions I made was to restart the demo from zero. The earlier work had taught me plenty, but the project needed a cleaner foundation and a much tighter target. On April 22, 2026, I began again with a deliberately narrow goal: one convincing restoration job, one understandable gameplay loop, and a strong before-and-after transformation. No giant world, no mountain of side systems, and no pretending that more features automatically meant a better demo.
That reset could have felt like failure. Instead, it became the point where the project started behaving like a real product. Within a few weeks, the new build had the essentials: menus and loading, a jobsite, tutorial guidance, the floor transformation system, the main machine and hand grinder, stage progression, audio, and a completion flow. It was not finished, but it was playable from beginning to end. For the first time, I could hand someone the game and watch the idea make sense without standing beside them to explain it.
My first development stream was titled “I Have No Idea What I’m Doing.” It was a joke, but it was also honest. I rarely knew the entire solution before I started. I learned to replace the question “How do I make this whole game?” with smaller questions: How should a slab register with the job system? How does the machine know what it is touching? How do I show progress without breaking immersion? How do I save this state safely? Each answer created the next workable piece.
Building Systems That Can Survive Real Content
A prototype can cheat. A commercial game eventually cannot. The first machine only needs to work once; an equipment system needs to support an entire catalog. One floor can be hard-coded; real jobs may contain several slabs that need to register themselves, track independent progress, and still report to the same job manager. One graphics setting can be wired manually; a release build needs a settings menu that applies, saves, resets, and behaves correctly across different hardware and keyboard layouts.
That is where much of solo development actually happens. The visible feature might be a new grinder, but underneath it are data tables, parent and child blueprints, equip positions, collision checks, camera behavior, audio, prices, unlock requirements, catalog images, and save data. When the parent system is sound, variants become faster and safer. When it is not, every new asset multiplies the problems.
I learned to value reusable structure without turning architecture into procrastination. I now build enough flexibility for the next real piece of content, not every imaginary possibility. Recently, that has meant adding new floor machines and hand grinders, creating reliable child classes for their variants, testing each tool in the player’s hands, and preparing the data that lets them appear correctly in the equipment catalog. It is not glamorous work, but it is the work that turns a collection of features into a game.
What a Publisher Milestone Taught Me
Working with a publisher changed the way I evaluated progress. Before that, it was easy to measure a day by how many nodes I connected or how many assets I imported. A milestone asks a harder question: what can another person play, understand, test, and approve?
That pressure was useful. It forced me to define what the demo was for, organize builds, capture clear footage, respond to feedback, and treat quality assurance as part of development rather than the last chore before release. When my first milestone was accepted, the biggest reward was not simply that someone liked the concept. It was proof that I could take a messy, self-taught process and deliver something concrete on a professional schedule.
Publisher feedback also taught me not to defend every decision automatically. Some notes expose a bug. Others expose confusion, which can be just as serious. The solution is not always the exact change someone suggests, but the underlying problem is usually worth understanding. That mindset has made the game clearer and made me less precious about work that needs to change.
The Part Nobody Sees
Solo development is often presented as a long creative sprint. In reality, it is constant context switching. In the same day I might adjust the roughness on a machine material, fix a camera position, test cursor confinement, balance a job reward, verify a fresh save, capture a catalog image, and then write a public update explaining what changed. There is no separate department waiting to catch the things I miss.
The final stretch of a milestone makes that especially obvious. The large systems may already work, but the remaining list is full of small decisions that players feel immediately: whether a flashlight behaves correctly, whether a tool collides cleanly at an edge, whether a tutorial gate can be bypassed, whether a machine sits naturally in the player’s hands, and whether the economy rewards the time a job actually takes. Polish is not decoration added after the game is complete. It is the accumulation of hundreds of corrections that allow the player to trust the experience.
I have also learned that motivation cannot be the only fuel. Some days the project feels incredible. Other days a render target turns blue for no obvious reason, an asset looks worse after export, or a problem that should take twenty minutes consumes the entire evening. The reliable response is not inspiration. It is documenting the state of the project, making a checkpoint, choosing the next small target, and returning.
Lessons I Would Give Another First Time Developer
• Build the smallest complete experience first. A short loop that starts, teaches, plays, and ends will tell you more than ten disconnected systems.
• Treat scope as a design tool. Cutting a feature is not automatically losing value. Often it protects the part of the game players will remember.
• Use your unfair advantage. Mine was trade knowledge. Yours may be a profession, place, community, or obsession that most developers have never experienced closely.
• Make boring work visible. Track bugs, write checkpoints, name commits clearly, and keep data organized. Future you is part of the team, even when the team is one person.
• Test like a stranger. A system working in your usual save with your usual habits is not proof. Start clean, make the wrong choice, press buttons in the wrong order, and see what survives.
• Let the project teach you. You do not need to know everything before beginning, but you do need to keep replacing guesses with evidence.
Where CPS Is Now
Concrete Polishing Simulator is now in the final push of its second publisher milestone. The core systems work. Multi-slab jobs are supported. The equipment and consumable-supply systems are operating, including the chemicals and stain that help sell the full restoration process. The remaining work is focused: finish the last jobs and their data, set rewards and progression, balance the experience, complete a final audio and visual pass, test from a clean save, and package the build for submission.
That list still contains real work, but it is very different from wondering whether the game can exist. It can. I have watched players take a damaged surface through the same broad rhythm I know from real jobs and reach the polished result at the end. I have watched machines that began as models become equipment with weight, sound, collision, progression, and purpose. The project has crossed from an idea about my trade into a game with an identity of its own.
I still have moments where I feel like the person from that first development stream—the one who has no idea what he is doing. The difference is that I no longer see that feeling as evidence that I should stop. It is usually evidence that I have reached the next thing I need to learn.
If you are building your first game, you do not need to begin as an authority on game development. Begin with something you understand deeply enough to notice what everyone else misses. Then build the smallest honest version of it, let people play it, and keep going.
About the author: Jacob Cates | |
 | I'm the solo developer and founder of Studio Vacant, currently creating Concrete Polishing Simulator. Drawing on real-world experience in concrete polishing, I am building a detailed simulation that combines authentic trade knowledge with approachable, rewarding gameplay. My work is driven by a love of games, creativity, and the determination to turn an ambitious personal project into a meaningful commercial release. |
Comments