chuck.I first heard about Tripo in late September, through a post by Guo Yu. He described using AI, Tripo and Blender to turn photographs into a three-dimensional character with a skeleton.
I asked Codex what I could actually do with one. My next question was whether I could put my own character into Mario.
Then I thought about my child. I had spent years watching other people's characters run across a screen. I wanted to see a recognizable little version of her in a world with mushrooms, coins and places to jump.
Previously, a tool like this would probably have given me an idea for a small 3D-printed toy. Make the model, find a shop to print it, put it on a shelf. That would have been the whole project. I knew Blender existed, and that people used it to make animation. I had never expected to open it and make something myself. Its panels, bones and timelines belonged to somebody else's working day.
With AI helping, I felt I could try taking the idea further. The result is called Budding Adventure—《布丁丁历险记》in Chinese. It is now an independent Windows game, with a start menu, saved progress and a complete set of levels. Most of the work that mattered was invisible in that first promising picture of a character.
Getting a child I could recognize
Tripo can generate 3D models from images and provides tools for rigging and animation. When I first heard the description, I imagined handing it a photograph and soon having a character I could use.
The first difficulty was recognition.
I used photographs of my child as references, with an idea of borrowing a little from a mushroom character. The face needed to be familiar. The hat needed to sit naturally. A good front view also needed to make sense from behind. The generated images often managed only part of that. A hat looked stuck on. A revised face became a stranger. Later attempts sometimes looked worse than the first.
I kept asking to return to the image that was already close, and work from there. In my head, there was a particular child I was trying to recognize. The tool could not automatically know which details made her herself.
We prepared different angles for Tripo. Putting the front, side and back together exposed things a single picture could hide: a hat that made no sense in profile, hair that changed between views, clothing that failed to stay consistent. I was also working out membership and export options. While parts of that were still unresolved, I asked whether we could try the next steps anyway.
That produced this early Blender prototype: a red mushroom hat and a simple body, rather like a newly assembled toy.
It helped me see that a character could turn and take a pose. Meanwhile, I became more particular about who we were making. The Tripo character I eventually exported wore blue clothes, a little backpack and a grey bear-eared hat. Later in the project, I explicitly asked to continue from that version rather than give her another mushroom head.
She was beginning to have her own appearance. Now I wanted her to move.
The tempting shortcut into Mario
Using an existing game sounded sensible. It already had running, jumping and levels. Replacing a character seemed likely to save a great deal of work. We did try a route involving SM64 CoopDX.
Having a skeleton did not immediately give me a child who could run in that game. Bones had to match in name and orientation. Each part of the body needed to follow the appropriate bone. Clothing and materials had to come along too. A model that looked like a person while standing still could fall apart when another set of movements was applied.
This is one of the failed previews we kept. The body has tipped over, with parts in places they should never be. After seeing it, I became much less optimistic about the phrase “already rigged.”
We made models, conversions and motion previews during that attempt. We did not get the character running inside the game. Eventually, I said we should drop that route altogether and return to Blender to make an animation worth watching.
It was frustrating to stop after so much work. The scene I had imagined at the beginning still had not appeared. But continuing to stare at an integration we had not made work would leave the character's own problems untouched. We had a model. I wanted to improve it enough to run convincingly on screen.
Once we stopped, I could concentrate on the child in front of me. Did her face deform when she turned? Did her arms and legs move together? Did the hat or backpack pass through her body? Playing a movement made those questions visible.
Movement revealed everything we had hidden
A still model is easier to like. Pick an angle, let the character stand, and plenty of faults stay out of sight. Walking brings the fingers, shoulders, clothes and face into the discussion.
One version showed far too much nostril from the front. Odd lumps appeared around the collar. Fingers curled into shapes that looked like claws. Another had a badly distorted face and a hunched walk. In the development chat, I said she moved like an elderly woman. It was blunt, but it described my reaction to what was on screen.
Repairs could make it worse. Reworking the rig or refining the face could change an expression I had already accepted. Version numbers went up while the child I recognized drifted further away.
I asked to set the rejected versions aside and continue from the model I had approved. Fixing a movement should not mean replacing the face, hat and clothes all over again. We needed something stable to work from.
By V7.2, I said it was finally a pass. That was a modest verdict. I did not think we had reached the quality of a major game studio. The character was simply stable enough to keep working on, without every movement pulling me out of the scene.
Running still looked awkward. The body and legs did not cooperate properly, and a jump seemed to push off one leg. It lacked the lightness I wanted. Instead of another long demonstration full of problems, I asked Codex to study just five seconds of running.
This time, I could see the difference. My response was: “Yes, that's how running should look.”
Five seconds gave me something I could judge closely: the start, the forward lean, the weight as a foot came down, the arms keeping up. Once it looked right, I was happy to use it in other shots.
That was when I named the project Budding Adventure.
A trailer made me want to step inside
With that acceptable run, I asked for a thirty-second trailer, assembled from five-second shots.
A camp in morning light. A run through a coin garden. A wave at a mushroom station. A jump across a stream. A mechanism lighting up. A celebration at the end. The character had somewhere to go and things to do. Those scenes gave me a much better sense of her world than an endless walk across an empty floor.
This trailer was made and rendered in Blender. We arranged the paths, cameras and movements in advance. You could watch it; you could not control the character with a keyboard.
Watching it made me want to enter that world. The coins were right there. I wanted to choose to run towards them. I wanted to press the key that sent her across the stream.
So I asked Codex whether, working seriously with the local Qwen model on my computer, we could make a game like this. Could we start with a free engine and existing foundations, using the character we already had?
The earlier failure had changed my expectations. Finishing a model no longer made the rest seem easy. But I now had an animation I wanted to keep, and that gave me a reason to continue.
The first playable build—and another rejected face
This time we made an independent game in Godot, starting with Kenney's 3D platformer starter project and bringing in our own character, environments and activities. Later, Blender became the workshop for windmills, waterwheels, fences and many of the smaller props.
Codex handled integration, running the project and fixing problems. Local Qwen contributed bounded pieces of work, including coins and checkpoints, interface text and some prop scripts. Some responses were useful after review; others were cut off or used the wrong interface and had to be redone. Running the result in the engine remained essential.
The first garden had ground, coins and a goal. The character responded to keys. This was when it began to feel like making a game. Where the camera turned and when a jump landed now depended on an action from the player.
Then we took another wrong turn with the face. We tried changing the features to bring her closer to the original child, and added braids that moved with her. Viewed as a list of features, it sounded like progress: moving hair, more detail.
The new face looked older. The eyes and expression had changed. It was too far from the child I had wanted, and the time already spent making it did not persuade me to keep it.
We restored the previously approved face, paused that line of work and continued with jumping and the game itself. The new braids went back with the rejected character version. Looking at these pictures explains the decision better than a list of completed features. I wanted to recognize her. Whenever a revision pushed her towards a more generic face, I had to pull the project back.
Using ordinary software, I rarely had a chance to make decisions at this level. Once I could change things, I discovered how many opinions I had. Appearance, familiarity and a cheerful run were things I still needed to judge myself.
A tree you could walk straight through
The first playable build also brought problems an animation never had to solve.
Feet sank into the ground. The character walked through trees and mushrooms. Jumping lacked a small crouch before takeoff and any convincing feeling on landing. I asked for those movements, then a double jump and feedback around the feet.
Even after an action looked right in Blender, it needed more work in the game. If an animation lifted the body and the engine lifted it again, the character floated strangely. A camera following too closely could fill the screen with her face. Continuing a saved game exposed problems with the camera position and animation loops too.
I specifically asked for debugging all the way through. After building the scenery and importing the character, I wanted to travel through it and find out what stopped me—and what failed to stop me at all.
As the environments became prettier, that demand became clearer. Windmills, huts, fences and poles stood there, but the character could pass directly through them. Solid-looking things needed to feel solid when you reached them.
Some slopes faced the wrong way. Some decorations had no collision shape. A moving raft needed to carry the player with it. Those repairs did not always make a screenshot more attractive, but they made the world feel more like a place containing real objects.
This is an actual engine recording of collision checks, using arranged test positions. It shows blocking and movement repairs, rather than a continuous playthrough from the beginning.
Giving the player a reason to keep going
At one point I complained about too much text. The screen kept explaining what I should do. I have played games for years, and even I found the instructions confusing. A child arriving for the first time needed somewhere she could understand and want to explore.
The early levels were short and repetitive too. Run somewhere, collect something, run again, change the backdrop. I wanted more reasons to stay: things to find, activities to try, a small response to reaching a place.
We changed the guidance. A little bird could lead the way. A destination could light up. A short instruction could appear near something the player could use. Coins became optional things to gather along the route, without requiring repeated trips just to reach a total.
The environments grew with those changes. Morning Islands gained flowers and picnic spots. Windmill Cloud Path had windmills, clouds and chimes. Firefly Night Garden led towards a moon mirror. Stream Valley involved rafts, water gates and little ducks. Cloud Celebration brought balloons, candy gates and a stage.
I wanted to spend time on these places because the character finally had things worth walking towards. Where might a child pause? What was easy to miss? Would a prompt cover the thing she needed to see? Adding a prop could be quick. Giving it a useful place in the world brought a whole new set of questions.
I did not want a timer stretching out an empty level. Short levels needed routes, activities and corners to explore. After adding them, we still had to check whether a player could understand what was there.
There really is a game in the folder now
The delivered 2.0 version opens directly on Windows. Starting, continuing, settings, progression and the ending connect into a complete game. Budding can travel from the morning islands through the night garden and water village to the celebration.
The completion records include a continuous check through all five chapters, running the final program along a normal-input route. It took about twenty minutes. That was verification along a known route, not a measurement of a child's first play session. Collision, saves and the interface were checked separately.
This is what I can say today: there is a runnable game, and the earlier problems that trapped the player or let her walk through things received actual repairs and checks. Where my child will get lost, or which corner she will like, still depends on her playing it. I do not want to write her review in advance.
The question “What can I use this model for?” now feels a long way behind us. When I first heard about Tripo, I imagined giving a photograph a physical shape. Later I was opening Blender, choosing movements and changing shots. Eventually I could ask very specific things of a game: how jumping should feel, how progress should save, how a player should find the way.
My requests kept growing as I saw and used each result. Some only occurred to me after a new feature worked. A decent run led to a trailer. The trailer led to a playable world. Once it was playable, I cared about what happened when she reached a tree or stepped onto a raft.
AI helped me begin and made unfamiliar software accessible. I still knew when a face needed to be rolled back, when a screenful of instructions was irritating, and when a run deserved another attempt.
Those judgments came from what I wanted to make for my child, and from my own experience of games. Before this project, they had little chance to become changes in a piece of software. Now they could.
Budding Adventure will keep changing. It got its name when five seconds of running finally looked right. Opening the finished game brings back the awkward faces, the broken skeleton, and that small moment of saying, “Yes, that's how running should look.” They remain part of how this game came to exist.
