Project: Starfield began with a simple idea: make a game that feels good to play mainly with a mouse. Rather than memorizing a long list of shortcuts or relying on rapid inputs, players would find the fun in combat and exploration through aiming, movement, equipment choices, and timing.
Around that idea, a combat vehicle, an unfamiliar planet, and a world of gathering, crafting, repairs, and adventure gradually took shape. Project: Starfield officially began on August 14, 2026, turning these ideas, step by step, into a game people could play for themselves.
CHAPTER / 01
Building the Gameplay Around Mouse Controls
From the first designs, I wanted the controls to be easy to learn while leaving players something worth thinking about.
Firing needed a clear direction: shells would travel wherever the mouse was pointing, and whether they hit would be decided by what happened in combat. Movement needed to matter, too. Players would have to read the terrain, keep their distance, and choose the right position to attack from. Simple inputs could still leave room for judgment and skill.
The vehicle's equipment would share a single energy system. Movement, firing, mining, and repairs would each consume energy, while the vehicle's power output and energy recovery would determine what it could keep doing. Choosing equipment would therefore involve more than comparing bigger numbers. Players would also need to consider whether the whole vehicle could support the way they wanted to act.
I also set two design principles at the start: keep the numbers restrained, and make changing equipment a meaningful choice. The early prototype required the vehicle to remain still for about five seconds when switching tools in the field. Players had to decide whether to prepare for mining or stay ready for combat before acting. These principles formed the starting point for the gameplay, and later adjustments would also need to be tested through actual play.
CHAPTER / 02
One Combat Vehicle and a Training Camp
The first combat vehicle was named the Pioneer N-01. It carried the project's earliest questions: how should the vehicle move, how should the energy cannon fire, how should the mining and repair arms work, and how could players understand what they were seeing?
Development soon grew from individual features into a training camp. The terrain gained changes in elevation. Rocks and buildings needed to block vehicles and shells; mineral deposits needed to be mineable; enemies needed to pursue, attack, and take damage when hit. Health, energy, a minimap, inventory, and equipment information were gradually added to the interface to help players understand their situation.
On August 16, 2026, the project migrated to Unity 6, establishing the engine foundation for further development. By August 17, an early demo had completed a round of gameplay integration and runtime testing, bringing combat, sound effects, terrain collisions, the interface, and the tutorial together in one playable build.
The tutorial linked several systems into a complete task: mine ore, refine alloy, craft repair patches, equip the repair arm, and activate and repair the training camp beacon. Checks also covered resuming after quitting partway through, returning after completion, and migrating older save files.
This early progress gave the project a foundation that could be playtested repeatedly. Each new addition would need to be checked to make sure it worked with the systems already in place.
CHAPTER / 03
Giving Environments and Characters a Shared World
As the gameplay began to come together, visual design took on more responsibilities. I wanted the environments to have believable materials, structures, and scale, while keeping their silhouettes clear enough for players to quickly read roads, facilities, mineral deposits, and enemies from a top-down view.
Equipment, environments, buildings, character clothing, and creatures gradually became distinct areas of design work. Combat vehicles needed recognizable mechanical structures. Repair facilities needed to make their vehicle entrances clear. Rocks needed to shape the landscape while leaving routes that vehicles could travel through. Mineral deposits needed clear uses in the game as well as distinct appearances.
The first mineral and rock assets went through reference design, 3D generation, inspection and repair in Blender, and then in-engine testing. Generating a model was only one step. Normals, textures, scale, collisions, and contact with the ground all affected the result. A model that looked good also needed to hold up when players drove around it, mined it, or fired at it.
The story also began to connect with these mechanics. An early story draft saved on August 19 explored linking the training camp's beacon repair task to a distress signal from a squad that had lost contact. It gave the tutorial a narrative reason to exist and left a clue pointing toward a larger world. This was an exploration at the story-design stage; the full presentation still needed to be produced later.
Continued work on characters, clothing, alien creatures, and buildings gradually gave Project: Starfield its own visual and narrative direction. Ultimately, all of them would need to serve the adventure players would experience.
CHAPTER / 04
Learning How to Work with AI During Development
Project: Starfield is also an ongoing practice in human–AI collaboration.
I set the gameplay and visual goals, review candidate approaches, find problems through playtesting, and decide what to keep and what to rework. AI tools contribute to discussing ideas, implementing code, exploring reference images and models, running checks, and organizing materials. Moving the project forward depends on these pieces of work actually fitting together.
At first, several specialist work sessions allowed different areas to progress at the same time. As the number of tasks grew, ownership of files, tool availability, and the quality of handoffs became more important. A multi-task development session and review on August 19 prompted a more centralized way of coordinating the work: specialist tasks retained responsibility for design and review, while dedicated production tasks took over 3D generation, model repair, and engine integration in turn.
The project then gradually established approval, version tracking, and acceptance processes. Where a piece of work had reached, which issues remained unresolved, and what the next stage needed all had to be recorded so they could be traced. This way of collaborating also went through rework and adjustment. Problems with tools or processes could slow development down, too.
AI can help explore more possibilities. Turning those experiments into a stable, enjoyable game still requires ongoing judgment, checking, and actual play.
CHAPTER / 05
Taking Problems Back into the Game
The real iteration often happens after playtesting.
A packaged-build check on August 17 exposed a very specific problem: the spawn point for a new save was sitting on one of the updated rocks. The terrain and collisions were already there, but the spawn position had not been checked again after the scene was assembled. The fix added a check for traversable ground, and the relevant tests were run again. An easily overlooked placement issue like this could directly affect a player's first minute in the game.
As the visual goals became more demanding, the problems became more detailed. Swamp water needed to meet the shore naturally, and the response to a vehicle passing through it needed to convey the feel of mud and water. When a combat vehicle entered a building, the lighting needed to keep its shape readable while fitting the interior. A September review of the swamp test scene identified obvious boundaries between areas of color and water that looked too flat, providing concrete reasons for further adjustments.
Vehicle movement also needed repeated observation. The sense of weight, steering, camera follow, and image stability all contributed to how comfortable driving felt. The effect of a parameter change needed to be checked along a real driving route. A still screenshot could show how something looked, but it could not tell us whether the image jittered during continuous movement.
This work gradually took development beyond having the features in place and into how each player action felt. Make changes, verify them, and carry the remaining problems into the next round of changes: that rhythm kept returning throughout the process.
CHAPTER / 06
More Work Still Ahead
Through September, work continued on environments, building interiors, characters, and the driving experience. The project also began organizing its Steamworks application and store materials in preparation for future public presentations.
As of October 2, 2026, Project: Starfield is still in development and refinement. Work on vehicle movement stability, interior and vehicle lighting, and repairs and subsequent rigging for the new driver model still needs to complete verification. The early demo's runtime records document a stage the project has already passed through; recent fixes still need their own playtest results.
Next, I hope to bring these elements together into a more coherent experience: driving into the training camp, understanding your equipment and energy, completing gathering and repair tasks, and gradually encountering clues through the characters, environments, and story.
Development continues. I will keep recording verified progress, actual game images, and directions still being explored, so players following Project: Starfield can see how this world, which began with one combat vehicle, takes shape step by step.