sgolem

Not sure why is that. Can you provide more details or try again?

I've added a "How To Play" button now before you start the game, and have polished up those error paths. Now they should be much less common and displayed more nicely.

Well, the purpose of this initial post was to just let people know it exists. I agree that those topics could be interesting and I might write them up in a blog.

The game doesn't really force any blockchain usage on you, but it will be optional in the future to play matches where you can win money.

Also, those terms were more or less vibed into existence so bear with me as I refine them into something solid in the near future.

Thank you for the feedback.

It should work on every browser that supports WebGL and SharedArrayBuffer. That should include Edge on Linux, but I'm not sure.

Hey, thank you for all these details, I really appreciate it!

I also use a 144Hz monitor and the framerate is often rock solid at the top. The problem is with browsers and battery powered devices. Chrome often locks up the game at 30, 60, or 120 FPS randomly, on battery or AC. I still haven't figured that one out.

I'm fixing some of those errors up right now. The problem is that I don't have a regular play testing base and for some players that do play it they're based relatively close to the server. I assume many issues reported here are from the US based folks, and I'm in Europe.

Thanks once again, I'll use this to improve it!

Sorry, that can definitely be improved. And is probably best to remove it until the game attracts some regular players for the queue to make sense. Will do.

Yes it's Bevy, with a custom backend game loop/simulation.

The idea definitely came from openfront and territorial, I've played both. But this codebase has nothing to do with them, it was built from scratch.

Yeah it's heavily inspired by openfront and territorial, I've played both. My goal for this was to see how far I can push it in terms of player count and map sizes.

This is a WIP version, and custom game seems to work for many players. I would've really appreciated if you told me how it didn't work so I can fix it.

Bots are run on a separate thread from the main game loop and I can configure them to have a particular amount of actions per tick or second - to simulate real player action frequency.

In my tests core game loop handles 1024 bots without issues, often running 5-20x of realtime.

One of the main challenges has been making the map simulation work for hundreds of simultaneous players without the server becoming a bottleneck.

Most interactions are event-driven and the map state updates incrementally, which keeps things manageable even when many borders are shifting at once.

I've successfully tested this with 4096^2 maps and 1024 players and in those tests framerates were stable at 144 FPS, with the server ticking steadily at the standard 10 TPS.

It is built on Rust and Bevy. I'm happy to answer any questions.

This is the first thing I “vibecoded” a couple of days ago. I really like the game in general and now find myself playing a few times per day. I might try to add some non-classical modes to the game in the future, or I might just leave it as it is, not sure.

I've written a NEAT implementation in Rust a few years back. It was able to train XOR and pole balancing.

https://sgolem.com/blog/neat-simple-neuroevolution-framework...

Can this be run with llama.cpp?

As long as users need to think about homeservers we can't expect a substantial migration.

As far as I'm aware there is work being done on the fully p2p version of Matrix where every device is a server. If that allows abstracting away homeservers, and if they solve multi device identities in a clean way, only then Matrix might be able to compete with an "ordinary" chat app for the majority of users.