Yes, there were some hallucinations, e.g: in breakout hitting a corner would destroy more blocks than expected, in doom-lite it could shoot from miles away and get a kill. The fixed was add some noise to the input frame and keep the target clean.
Not the poster you responded to... Your Singleton hack was clever. In some ways it brings game design back into the equation, in that it mirrors the special cases that most game code has to deal with. You alluded to something in the docs that I was curious about, which is state. From reading it, I gathered that both agents interpret the direction of the Pac Man based on the position of its mouth in the previous frame. And one of your graphics seems to imply that the Doom state of where you are and which direction you're facing is magically grokked by the agent reading the map in the corner. Is that so? In that case, I wanted to ask, in pong or breakout, what is it using to figure out the direction and velocity of the ball? Faded prior shadows in other cells, maybe?
No, not shadows. I use the heading as a token, in Doom the minimap has a player token and the facing (the current 3D view), I tried using only the frame but it was harder to learn only from the wall patterns. So the agent isn't magically grokking position, its using the map. As for the Pac Man, it's based on mouth and has tokens for "keep going" or N/E/S/W direction. For breakout it uses 4 ball tokens, one per diagonal and it moves one cell per step in that diagonal, and for pong the ball has 6 tokens (combiantion between [up, level, down] with [left, right], e.g up right, level down)
Very cool. I didn't know NNs were capable of such determinism, that's very interesting. Is this a similar effect to overfitting? Also, it's the same model for all the games, right?
> Also, it's the same model for all the games, right
It's a bit unclear but it looks like different models, since they all have different parameter and MAC counts. It would be much more impressive with a single world model that could maybe dream up new games inbetween the games in the training set.
It's a self contained net for each game but the data used for training doesn't overlap with the validation. I think it would be easy to merge them into a single model
The core of it uses rust with no_std and on the pico we use embassy-rs with no os. At the same time, the core can be build for webassembly but it doesn't use webgpu.
Honestly fascinating. I almost feel like you'd be better off avoiding any discussion of the fact that this runs on a Raspberry Pi Pico 2 W because it takes away from the crazy world model capabilities (of course, the fact that this does run on a Pico 2 makes the whole thing much more impressive).
There's gotta be a good way to incorporate this logic into a larger, more "traditional" game in a meaningful way. Seems like an approach for procedural generation that could solve some of the issues usually found with actual procedural generation.
I might have missed it in the readme, but what hardware did the training take place on? This is really neat.
For the world model training I've used an RTX 4060, but for the agent playing the game that was directly on the pico using stream-ac
This is incredibly cool! Fascinating to see looped transformers be necessary for mini-Doom, but not for simpler games.
I honestly believe that these neat projects (smallest possible, locally run LLMs) are the real future of AI on the long run.
Is the actor trained on world model's mistakes as well? If so, it should learn to force hallucinations that force it into an easier state.
Yes, there were some hallucinations, e.g: in breakout hitting a corner would destroy more blocks than expected, in doom-lite it could shoot from miles away and get a kill. The fixed was add some noise to the input frame and keep the target clean.
Not the poster you responded to... Your Singleton hack was clever. In some ways it brings game design back into the equation, in that it mirrors the special cases that most game code has to deal with. You alluded to something in the docs that I was curious about, which is state. From reading it, I gathered that both agents interpret the direction of the Pac Man based on the position of its mouth in the previous frame. And one of your graphics seems to imply that the Doom state of where you are and which direction you're facing is magically grokked by the agent reading the map in the corner. Is that so? In that case, I wanted to ask, in pong or breakout, what is it using to figure out the direction and velocity of the ball? Faded prior shadows in other cells, maybe?
No, not shadows. I use the heading as a token, in Doom the minimap has a player token and the facing (the current 3D view), I tried using only the frame but it was harder to learn only from the wall patterns. So the agent isn't magically grokking position, its using the map. As for the Pac Man, it's based on mouth and has tokens for "keep going" or N/E/S/W direction. For breakout it uses 4 ball tokens, one per diagonal and it moves one cell per step in that diagonal, and for pong the ball has 6 tokens (combiantion between [up, level, down] with [left, right], e.g up right, level down)
Very cool. I didn't know NNs were capable of such determinism, that's very interesting. Is this a similar effect to overfitting? Also, it's the same model for all the games, right?
> Also, it's the same model for all the games, right
It's a bit unclear but it looks like different models, since they all have different parameter and MAC counts. It would be much more impressive with a single world model that could maybe dream up new games inbetween the games in the training set.
It's a self contained net for each game but the data used for training doesn't overlap with the validation. I think it would be easy to merge them into a single model
If this runs on a PI... can it run on webgpu ?
The core of it uses rust with no_std and on the pico we use embassy-rs with no os. At the same time, the core can be build for webassembly but it doesn't use webgpu.
Unlikely, Raspberry Pi Pico 2 W is a microcontroller, not a computer. It runs either bare metal or an RTOS.
Honestly fascinating. I almost feel like you'd be better off avoiding any discussion of the fact that this runs on a Raspberry Pi Pico 2 W because it takes away from the crazy world model capabilities (of course, the fact that this does run on a Pico 2 makes the whole thing much more impressive).
There's gotta be a good way to incorporate this logic into a larger, more "traditional" game in a meaningful way. Seems like an approach for procedural generation that could solve some of the issues usually found with actual procedural generation.