我原定在 2027 年製作遊戲，現在進展如何

Back in July, I wrote a post about making games in 2027. Unity was picked. Blender was picked. The actual game was considerably less picked.

At the time, that felt like a reasonable commitment. I had other software to build, plenty to learn, and a long history of being interested in game development without getting very far into it. Putting a year on it gave the idea somewhere to go.

It is now October 2026, and there are two Unity game projects in my studio.

Apparently, I started early.

That deserves an update, especially because the interesting part is what has happened between deciding to make a game and having something concrete enough to change my mind about.

The first project started as a magic shop.

You stand behind a counter. Someone brings you an item, and you have to work out what it is, what their story is worth, and what you are willing to pay. There are instruments to examine things, references to consult, and opportunities to make a bad judgment. Behind the counter, workshop stations let you make or improve items.

That gave the idea a place and a set of things to do. It also gave us something more useful than another page of possibilities: a project we could build, inspect, and revise.

As the design developed, the shop grew toward an adventurers’ guild hall. Adventurers return from the road with loot, worn equipment, and wounds. They need somewhere to sleep, food, supplies, and help getting ready to leave again.

Those activities connect. The person selling you something at the desk can also become your guest. Their damaged gear gives the workshop a purpose. Their next trip gives the supplies on your shelves a purpose. The building starts to feel like a place people depend on.

The project now has implementation around those ideas. There is still work to do on how it feels, how clearly it explains itself, and whether its growing collection of activities makes a good day of play.

I am being careful about that distinction. A feature existing in the project tells me we have something to evaluate. I still have to evaluate it.

The second project has already given me a fairly direct lesson in that.

It began as a different kind of tabletop game. We built the first version, added a guided introduction, and I played it. After that, I rejected the central tally mechanic and changed direction.

It is now a creature-and-spell card battler.

There are decks, elemental advantages, creatures with attack and health, spells, and an opponent to play against. The work has moved through changes to combat, a deck builder, class abilities, and stronger opponent decks.

But the most useful part of that history might be the discarded version.

We could implement its rules. We could check those rules. I could read the design and agree to build it. Playing it still changed the decision.

That is a much more concrete encounter with game design than anything I could have learned by continuing to plan for next year. I had to put time into a version before I could decide that I wanted a different game.

AI coding agents are a large part of how I have been able to start this work alongside everything else.

I use Codex and Claude extensively in my software projects, and that carries into the games. They handle substantial implementation work. I describe behavior, work through the design, inspect what comes back, and decide what to change.

I have not suddenly acquired years of Unity experience. There are still engine details, graphics concepts, and production skills I need to understand better.

What I have gained is a shorter path from an idea to a version I can examine. That makes starting more practical. It also gives me more decisions to make, because every working addition raises another question about what belongs in the game.

The guild hall is a good example. A kitchen makes sense. Lodging makes sense. Repairs make sense. Each addition can have a reasonable explanation, and I still need to consider the amount of work they create together.

In July, scope was one of the things I said I needed to learn. Now I have specific projects in which to learn it.

I also have a clearer picture of what my software background contributes. State, persistence, code organization, and tests are familiar territory. Those skills help me build something I can keep changing. The play sessions have already shown me how much more there is to judge once the rules work.

So 2027 is still relevant. There is plenty of learning and development ahead. I have no release date to announce here.

But the starting point has changed. I have projects with rules that have survived revision, rules I have thrown away, and builds that give me something specific to react to.

The next useful update should have more of that: something I played, what I thought of it, and what changed afterward.