Forem: Misha Shelemetyev

sshOuroboros terminal multiplayer game written in goLang with ssh.

Misha Shelemetyev — Wed, 05 Nov 2025 21:44:56 +0000

GIMME THE MEAT

sshOurboros -- multiplayer game where snake eats itself and grows

To play go here ssh web2u.org -p6996

The Rules:

The goal is to claim the most space
Secondary goal is to kill as many other Ourboroses as you can
The how:
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!
To kill other snakes you hit their tails
To watch out:
Other players can kill you by hitting your exposed tail
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:

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
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 :-(

Bring Some colors to your terminal!

Misha Shelemetyev — Fri, 04 Oct 2019 16:32:36 +0000

Its all started when I was driving to an office today,
leaves changing color, sun shining down on different colored cars
on the road, long story short it was super colorful.

When I got my desk I was greeted by dark themed intellij with even darker terminal with lines and lines of super verbose Java. That made me want to escape somewhere... Perhaps Python would of been good, but to challenge myself I've decided something that remotely resembles of both of this languages(Java and Python3) and that is Rust(obviously resembles in terms of Syntax).

So the story below is about me wondering in the land of Rust and the project
that I came up with to bring some color to the dark life in terminal.

The idea is pretty simple: modern terminals support 256 font and background colors, so why won't we generate ascii image previews for images in terminal, this way when you ssh'd to some weird server with some
strange php(or any other language) code on it, you can at least find some joy looking at
ascii representation of images that have been uploaded there :-)

TLDR: you can get the util here(it's compiled for macOs or 64bit liunux, if you run something else you can get cargo installed and do cargo run to play with): https://github.com/MShel/termpic/tree/master/bin

feel free to create PR for compiled util for windows or in general if you see that something is horribly(or not horribly) wrong out there :-)

Then you can use it either by doing:
cargo run {imageFilePath} or
bin/termpic {imageFilePath}

My first experience with Rust was very pleasant for number of reasons:

Reason 1

It has quite a big collection of packages already, so most of the work was already done for me by crate image and terminal_size.

Reason 2

Rust syntax is simply awesome, just look at following code chunk, I think this one of the clearest way to define open file behaviour(sorta like Pythons with....). However it does take some time to adapt to the whole "taking care of burrowing and references situation". Don't think I'm quite there yet

 let image_result =  image::open(&params[1]);
    match image_result {
        Ok (unwrapped_image) => {
            let mut term_symbols_cache = HashMap::new();
            let aciid_image:String = turn_rgb_frame_to_ascii(unwrapped_image, &mut term_symbols_cache);
            print!("{}", aciid_image);
        }
        Err(message) => {
            println!("{:?}", message)
        }
    }

Reason 3

Its fast

How does it work?

Well it's super simple:

Try to open the image with the code above.
If succeed we go to ascii_frame::turn_rgb_frame_to_ascii::turn_rgb_frame_to_ascii - that returns us ascii string which we simply dump in the terminal

2.0 Before that^ we also initiate cache for ascii symbols with color there. Notice how we specify that hashmap is mutable so we allow ourself
to later put items there, also notice how we don't have to specify type for it, that's because later in turn_rgb_frame_to_ascii definition will do that and rust will manage to infer that(awesome right?)
```
     let mut term_symbols_cache = HashMap::new(); 

     pub fn turn_rgb_frame_to_ascii(frame:DynamicImage, term_symbols_cache: &mut std::collections::HashMap<image::Rgba<u8>, String>) -> String {
```
2.1 In turn_rgb_frame_to_ascii first thing we do we call terminal_size to get size of terminal so we won't try to output millions of symbols for super small terminal window(so the smaller terminal screen the worst kind of quality you get while running the util)

        let size = terminal_size();
        let resized_frame;
        if let Some((Width(w), Height(h))) = size {
            resized_frame = frame.resize(w as u32, h as u32, image::FilterType::Nearest);
        } else {
            resized_frame = frame.resize(240, 320, image::FilterType::Nearest);
        }

2.2 Then we go pixel by pixel in our resized image and get ascii value for each of them. Notice the match syntax for our hashMap(😍).

        let mut asciid_frame = String::new(); 

        for row in 0..resized_frame.height() {
            let mut ascii_row = String::new();
            for column in 0..resized_frame.width() {
                let mut _ascii_symb = String::new();
                let pixel = resized_frame.get_pixel(column,row);
                match term_symbols_cache.get(&pixel) {
                    Some(symb) => _ascii_symb = symb.to_string(),
                    None => _ascii_symb = get_ascii_symb_for_pixel(pixel, term_symbols_cache)
                }
                ascii_row += &_ascii_symb;
            }
            asciid_frame += &ascii_row;
            asciid_frame += "\n";
        }
        asciid_frame
    }

2.3 Everything but one thing should be clear from the code above. Here is this one unclear thing bellow. The magic here is that function get_ascii_for_rgb_arr. Magic of it is explained here. For the purpose of this article though we will avoid discussing details of it :-) And focus of how not hard it is to actually do all this thing in low level programming language

    fn get_ascii_symb_for_pixel(
            pixel:image::Rgba<u8>,
            term_symbols_cache: &mut std::collections::HashMap<image::Rgba<u8>,String>
            ) -> String {
        let rgb_arr = turn_pixel_to_arr(pixel);
        let mut ascii_symb = String::from("\x1B[48;2;");
        ascii_symb+= &String::from(format!("{};{};{}",pixel[0],pixel[1],pixel[2]));
        ascii_symb+= &String::from("m");
        ascii_symb+= &get_ascii_for_rgb_arr(rgb_arr).to_string();
        ascii_symb+= &String::from("\x1B[0m");
        term_symbols_cache.insert(pixel, ascii_symb.to_string());
        ascii_symb
    }

    fn turn_pixel_to_arr(rgb_pix:image::Rgba<u8>) -> [f64;3]{
        [rgb_pix[1] as f64, rgb_pix[2] as f64, rgb_pix[3] as f64]
    }

    pub fn  get_ascii_for_rgb_arr(rgb_color:[f64;3]) -> char {
        let char_vec:Vec<char> = "MNHQ$OC?7>!:-;. ".chars().collect();
        let luminosity:f64 = 0.21 * rgb_color[0]+ 0.72 * rgb_color[1] + 0.07 * rgb_color[2];
        return char_vec[( luminosity / 256.0 * char_vec.len() as f64) as usize];
    }

Have an awesome fall everyone!!!

https://github.com/MShel/termpic

How do you measure code quality / engineering team performance?

Misha Shelemetyev — Fri, 07 Jun 2019 14:56:59 +0000

I've been looking into this problem for a while now and here are the few things that I came up with(however NaN of them feel quite right):

Test code coverage
Amount of bugs / Amount of features (%)
AVG Page load time (assuming we talking about some sort of website)
Cyclomatic complexity (spaghettines of the code) should be small
Essential Complexity (unnecessary loops and ifs)-should be small

So the question is how do you guys do it? and at what point (every 2weeks/ on the time of release/ every 1/2 year /every day/ every commit/ once in a blue moon)