sshOuroboros multiplayer game in goLang with ssh, and the story.

GIMME THE MEAT

sshOurboros -- multiplayer game where snake eats itself and grows

To play go here ssh web2u.org -p6996

The Rules:

1. The goal is to claim the most space

2. Secondary goal is to kill as many other Ourboroses as you can
   The how:

3. To claim space you need to either eat your own tail or reach tiles you've already claimed,
   tiles that are enclosed when you do so become yours!

4. To kill other snakes you hit their tails
   To watch out:

5. Other players can kill you by hitting your exposed tail

6. Other players can take your tiles.

The source: https://github.com/MShel/sshOuroboros/tree/main

Walk through on how it works and why

When you Sign Up to the game you are presented with 254 Ansi colorsor maybe less if there are active players in the game right now.
Why 254? glad you asked! Thats what we have in terminal - (void color + wall color).

But now that you've signed up there are players there! What the heck? all the colors were available. Well that's bots -- we try to keep all 254 colors busy at all times sshOuroboroses never sleep as cool kids say.

You joining the world of sshOuroboros actually already caused drama and we had to kick the bot with your color out

Alright we are in and passing commands back and fro through your players channel
And that's fantastic but now we are getting to the meat of the game which is - how do we claim the territory? Well one AI would say its been solved bazzillion times you do flood fill by defining boundaries and calculating out of boundary tiles and swapping color for others....One would say that and it would not work? why-- because we have 254 bots that potentially need to scan 350_000 tiles or cells on every 100ms move. That's going to be too slow.

So here comes my concurrent simplistic implementation:
Imagine your ouroboros it can hit a tail or base from only 4 different sides and most of the time from one side it would be the area to claim and from other- the area you don't need to touch, so we need to explore only those 2(its not exactly this logic but ~90% of it). Now we throw 2 goroutines if one of them exited before finding the wall we kill another and we are done! link to code

The bots, oh those pesky bots in my first implementation I had a separate ticker for the bot master and it would be responsible for moving them around, that worked great till I started testing with 250 of them now it did not work at all =D the amount of kills of players that were killed and claims for tiles by bots who were killed was astonishing so I've scrapped that and now we assign strategy directly to player and run bots strategies right in the main loop. link

Talking about bots when I started I had this plan of multiple strategies and random selection of strategy based on bot situation........but ain't got time for that so I have this little Default strategy file that is Actual If conditions all around with some ridiculous logic
Now the nice part it is an implementation of interface that is used in *Player which theoretically unblocks me from saying later -- yeahyeah its bad but I can throw it away and rewrite. Also that is one of the areas I see as future major change in this project(see whats next? section below)

We have this 350_000 tile thing going on with 254 players on it how the heck do do we show it on the terminal you ask? well we cant -- not on most terminals, we need viewport of limited width and height and hopefully bother bubbletea(the rendering lib) update only with small portion of it. [here] we ask for chunk of map (https://github.com/MShel/sshOuroboros/blob/db5cd9fdc0d1e674d6fc56a9b3fc3ad0a863a8ef/internal/game/GameManager.go#L304-L331) And here we render it.
This whole view function is kinda nasty and was a huge pain to write but it works most time anyway.

So here you go that's the key parts of the game, there are a lot more areas to cover but those are the most interesting ones IMHO(ask me about anything else and answer I will)

Whats In the Future

Well here I need your dear Reader advice, I've got following ideas that I'm planning to think about next, but if something completely different comes to your mind(hopefully about the game) do let me know. Anyway, help me pick!

• New game play as Bots strategy (add lua VM and allow strategy to be small executable lua script to be submitted by user)
• Variable ouroboros speed press x to go real Fast type of situation
• More games -- we have one with 256 players we can easily provision many with 256, though my server will have to be improved(its 10$ on linode and its meh)

Why did I write it?

Well Ai and terminal.shop... Ai is to blame for it, I was am slightly depressed by on slot of claims that AI will take over everything I like and make me write documentation and that is my 2'd least favorite thing in this career(1't are useless meetings that only end up in more useless meetings).

So hearing all that and watching Prime on youtube talking about how awesome ssh coffee stuff is I was like "lets try to write an ssh game cause its fun and be open minded about AI".

Now the good -- I had an absolute blast working on it and will try to invest more time in random projects like that in the future to keep the sadness of news at bay

-- Ai wont take my job for now and that's not only because I tend to be very openly opinionated about things but also because:

1. Flood fill -- it could not figure it out, it did provide classical algorithms that did not scale but it was of no help at the end
2. Concurrency issues -- It can not figure those out like at all, the game had a lot of those in my original iterations, ai could not suggest any sort of fix that would address performance bottlenecks

Also good'ish? -- Ai was good at helping me with code I did not want to write like view files, I just dont care about them enough
Or the HighScore sqlite crud thingy, that also was pretty much all AI

Now the bad -- I can write 250 more articles about how AI cant really replace anyone but it wont help the narrative been pushed by those weird AI CEO's :-(