# Machi: State="lost"

Okay, I’m very very lost at this point. Enough to make me nauseous when staring into the laptop.

> Machi project feels like learning Blender or Maya for the first time. There are so much knobs. So many options. Difficult to put a finger on it.

There are largely two dimensions:

* Semantic-first vs Visual-first
    
* Manual-first vs Generation-first
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1771349622627/6ea9ae67-0916-4f94-8ab8-258711686df3.png align="center")

I have no idea as too where to start the first stroke.

SpriteDX has started from “visuals.” It started from bunch of test generations in various sites including Scenario, BFL, ComfyUI, etc. Then, slowly we added **control** (e.g. template, fill-in-the-blank, pipeline, animation sheet) and **semantics** (e.g. entity spec, animation state identifiers, spritesheet, transparency).

Before SpriteDX started, Machi was:

* **Simulation**: cellular automata proposal for the land that ai agents sits on top of.
    
* **Editor**: we also had to first create some type of level editor to create seed environment.
    
* **Visual**: MidJourney generated pixel art scenes
    
* **Renderer**: Testing generative AI capabilities of turning semantic tiles into neural rendered visuals.
    

Each all tackle different dimensions.

I want to be able to pick a place to start from.

* Editor really feels like I’m making old school 2D platformer.
    
* Simulation is hard to get right and requires some sort of editor to properly experiment.
    
* Visual is stunning and continuously grabs my attention and feel like I should start from visuals itself and drill down as we did with the character pipelines in SpriteDX.
    
* Renderer is a novel portion of the engine that really changes the game, so feel like I need to start on this part first. However, even this needs some level of editor and simulation.
    

So TL;DR:

> We are asking too many questions at once. Considering too many variables at once.

What @[Pixel](@pix-el) suggests is to start with **Visual-first**. Not because it is the most foundational but because it gives you a anchor point.

Once we have the **visual-goal**, we can start turning that into **semantics** whether it be tiles or nav mesh. So similar to how SpriteDX started.

This means, we would not need to invest in cellular automata or editor at this point in time.

* First, we generate concept visuals that serve as anchor points.
    
* Make sure it is something borderline achievable.
    
* Next, we experiment with embedding semantics into it (or turning them into tiles).
    

> ❌ Editor  
> ❌ Cellular Automata  
> ❌ Simulation  
> ⭕️ Concept Art  
> ⭕️ Feasibility Study  
> ⭕️ NavMesh or Tile-ization

— Sprited Dev 🐛