How to create a 3D horror prototype with Opus 5.5 and Blender in one evening

The 3D horror prototype with Opus 5.5 and Blender is a game demo assembled during a short experiment, not a finished commercial product. In the case described by the author, it was a zombie horror game set in a Soviet twelve-story apartment building: the neural network helped with the concept, assets, logic, and code, while Blender was used to work with 3D models.

The experiment’s main conclusion is simple: AI quickly brings an idea to a playable state, but it does not eliminate the need to manually check the scene, models, collisions, and game balance.

What was created in one evening

The author calls the project their first experience creating a game. During a short session, they produced a demo prototype featuring exploration of apartments and corridors, notes, keys, weapons, healing, several types of zombies, and a final escape from the building. The author assigned a substantial portion of the tasks to Opus 5.5, while doing the manual work in Blender and during the test playthrough.

The result has an important limitation. It demonstrates the speed of assembling the first gameplay loop, but it does not prove that every user will reliably produce a similar project in one evening. The time depends on experience with Blender, the game engine selected, the available tools, the number of iterations, and how strictly the author controls the project structure.

• Concept: a Soviet apartment block, dark corridors, and infected residents.
• Visual elements: corridors, apartments, characters, and atmospheric objects.
• Gameplay loop: searching for items, opening doors, encountering enemies, and trying to reach the exit.
• Story elements: notes, warnings, keys, and enemy placement.
• Testing: a playthrough from the starting room to the first floor with errors recorded.

Preparing concept art

The work began with generating concept art. The author created images of corridors, apartments, and potential game scenes to establish the visual direction before assembling the 3D level. This order is convenient for a beginner: first, the mood and spatial geometry are established, then models and game areas are assembled using references.

For a horror game, one beautiful image is not enough. A reference should answer practical questions: where the player appears, where they can go, which doors are locked, where the light source is, and from which location an enemy might emerge. If an image conveys only atmosphere, Opus will suggest a striking but inconvenient game scene with unclear scale and routes.

It is better to separate prompts by task. One set of references is needed for a corridor, another for a living room, a third for a stairwell, while separate images help define the appearance of the zombies and the main character. This preparation makes it easier to transfer ideas to Blender and reduces the risk of getting elements that are stylistically incompatible, especially when the environment, characters, and items are created in different iterations.

Creating the zombies and main character in Blender

For the zombies, the author asked Opus to create images in a T-pose. This type of reference is more convenient for making a 3D model: the body proportions, arm position, clothing silhouette, and the character’s main details are clearly visible. The models were then assembled in Blender using the finished images.

The models turned out to be one of the longest stages. According to the author, the zombie quality was average but sufficient for a prototype, where having an enemy, a readable silhouette, and working animation matters more than high detail. A full release would require retopology, a clean UV unwrap, materials, skeleton checks, and several animation cycles.

The author spent longer refining the main character than the zombies. They used several generations, selected a more suitable version, and then repeatedly edited the model in Blender until they achieved an acceptable result. This episode shows the limits of automation: the neural network speeds up the search for an initial form, but aligning the proportions, clothing, hands, face, and animation rig still requires manual control.

Assembling the game environment

The environment was transferred into the game using references of corridors, apartments, and potential game scenes. The author expected bugs in advance, and testing confirmed this assumption: visual objects sometimes blocked passages, gave doorways a strange appearance, or allowed passage where the route was supposed to remain closed.

For a quick prototype, it is sensible to start with a short route rather than trying to build the entire twelve-story building at once. First, check the starting room, one corridor, several doors, and a small section of stairs; once the player can move through the basic area without errors, add apartments, keys, enemies, and story events to the scene. Otherwise, a collision problem becomes mixed up with a door-logic error or incorrect object placement.

Most of the apartments remained closed in the prototype. Access to individual rooms opened after obtaining keys, while some doors and passages remained inaccessible. During the playthrough, the author found the key to apartment number 41, whereas the debtor, according to the author, was in apartment number 37. Such details create a sense of investigation only when the apartment numbers, notes, and items are consistent.

Which mechanics were implemented

The game featured a primary weapon, healing with pills and energy drinks, as well as movement, attack, and death animations for the zombies and the main character. At the beginning, the player can inspect the room, read notes, pick up a crowbar, and hide in a closet. For a first prototype, this is already a connected gameplay loop in which exploration gradually turns into risky movement through the building.

• Weapon. Zombies can be killed with strikes, as the author discovered during the first encounters.
• Healing. Pills restore health, and the author considered the consumption animation fairly successful.
• Energy drinks. They can be picked up and used as a resource for progressing.
• Keys. Items open individual apartments and advance the investigation.
• Notes. They convey story information and offer guidance on how to behave on the first floor.
• Hiding place. The closet in the starting room establishes a simple enemy-avoidance mechanic.

The enemies’ behavior was inconsistent. The game features ordinary and crawling zombies, as well as enemies that activate and stand up when the player approaches or enters a room. Some enemies fall after death, while others remain as motionless objects and do not transition into a full physical reaction.

Sounds, music, and story logic

The author generated some of the sounds and music with code generation and took some from the internet. For a horror game, this mixed approach is sensitive to consistency: the volume of footsteps, impacts, background hum, and sudden signals should support the scene rather than overpower it.

Opus independently created the story logic, notes, zombie placement, and additional atmospheric objects. In the experiment’s concept, the neural network served not only as a generator of individual fragments but also as an assistant connecting exploration, items, and events. The author performed the final check of these connections during the playthrough, since the text of a note alone does not guarantee that a door or enemy will behave correctly.

What the test playthrough showed

At the beginning, the game seemed fairly easy to the author, although after several encounters they had about 35% health remaining. The number itself is not what matters, but the balance it revealed: the player may spend health and healing resources faster than expected, and the feeling of ease changes when the resources run out.

One of the strongest moments was the sudden appearance of a zombie when a door opened. The author was playing the game for the first time and did not expect the event, so the scene frightened them more than enemies that were visible in advance. In their assessment, the unexpected trigger worked better than a predictable enemy placement at the end of a corridor.

One of the notes stated that the lower exit was blocked, that there were many enemies on the first floor, and that running could attract them from far away. The advice to move quietly created tension, but before reaching the first floor, the author still had three energy drinks, which later ran out. In the end, the tactic of making a quick exit through the first floor worked, and the author completed the game, although the stealthy approach suggested by the warning was not the only viable option.

Why the atmosphere worked despite the rough edges

In the author’s assessment, the atmosphere was conveyed fairly well overall. It was created by zombies, darkness, sounds, and flickering lights rather than by detailing every apartment. Even an empty room works for horror if the player understands that a threat may be behind the next door, while the space limits visibility and reaction speed.

There is also a downside. Many of the apartments that could be opened contained almost no content, so exploration sometimes became an inspection of an empty room. For the next iteration, it would have been worth assigning room functions in advance: a story note, a resource, a key, a false discovery, a short scene, or an enemy. Then opening a door would have a clear gameplay value.

What bugs were discovered

The rapid assembly produced a playable result but also revealed weak points. Objects could block passages or give them a strange appearance, although the player could still pass through some obstacles. Zombies sometimes appeared or moved abruptly. This heightened the surprise effect but also pointed to technical shortcomings.

• Check the collisions of all walls, doors, furniture, and decorative objects.
• Separate the visual passage model from the invisible game boundary.
• Check the enemy’s state after death and whether it falls correctly.
• Make sure zombie activation triggers once and in the correct area.
• Test enemy spawning when loading a room and opening a door.
• Link apartment numbers, keys, and the contents of the notes in a single verification table.
• Remove empty rooms or give them a clear function.

What happens if the level is expanded immediately without fixing the basic passages? The player will encounter the same errors dozens of times, and finding the cause will become more difficult. For a prototype, it is more useful to check small areas one after another, fix bugs, and only then add a new floor, apartment, or enemy type.

Overall assessment of the approach

The described experiment shows where Opus 5.5 is especially useful for a beginner: generating ideas, preparing references, writing story fragments, placing objects, creating basic logic, and rapidly iterating on code. Blender handles another part of the process related to models, proportions, materials, rigging, and fixing geometry.

The neural network did not replace manual work. The author spent more time on the main character, checked the playthrough, noticed problems with zombie behavior, assessed the rate at which resources were consumed, and selected a viable tactic on the first floor. It was testing that turned a set of generated elements into a demo that could be completed from the starting room to the exit.

For a beginner, a practical workflow looks like this: formulate a short concept, prepare references, assemble one game area, create a simple enemy model, add one item and one threat, and then check the route from beginning to end. After that, expand the map and add notes, keys, healing, hiding places, and atmospheric events. This approach does not guarantee a finished game in one evening, but it does help produce a testable prototype and reveal which tasks AI speeds up and which still require work in Blender and careful manual testing.