Blog

Xcyte

Sun, 09 Nov 2025 00:00:00 GMT

This Project is designed to be for all types of players. From players who never played the game to players who developed a deep knowledge for the game. The primary goal is to enjoy the gameplay and to experience the joy of playing the game, trade Pokémon and to battle with other players! Since the newest game (Pokémon Legends Z-A) is playing in the same region as generation 6, we're playing the original: X/Y.

How does all of this go?

Registrations

Registrations close on 23.01.2026 - 23:59

Participants

Participants will be announced on 26.01.2026

Start

The project will officially begin on the evening of 30.01.2026

Tournament

The tournament will take place on the weekends between 27.02.2026 - 29.03.2026. This gives everyone 4 weeks to prepare.

What if I don't stream?

Every streamer who gets selected will receive their own team that viewers can register for to play along. These teams will also compete in a league table at the end to earn points.

Where do I register?

Over this form: https://docs.google.com/forms/d/1rReyeOqfujPxCIsqXibnHvK54hdVzhMUfMV4rQIcLoo/edit?pli=1

Additionally, you can join onto this Discord Server if you're interested: https://discord.gg/SncBqdkQ2V

Choose your roles and you’re good to go!

What do I need to be able to participate?

Emulator

We're using the Azahar Emulator, as it is required for tools like Pokélink.

Pokélink

If you are a streamer, we need Pokélink so we can keep track of your team and progress.

The Game & Setup

After registrations close, we will provide help on the Discord server.

Rules when playing

Emulator Speed

Anything between 100-200% is allowed.

Cheats

All forms of cheats are strictly forbidden.

Pokémon

In your solo gameplay, you may use any Pokémon you feel fits your playstyle or asthetic.

Please use common sense when choosing names, avoid anything inappropriate.

Trading

Trading is fully allowed and encouraged between all players!

Battles

Test battles are allowed for training and to familiarize yourself with the battle rules.

Rules for Battle

Qualification

You qualify to participate by becoming the Champion of the Pokémon region.

Format

Single Battle (1v1) with 6 Pokémon, all automatically set to Level 50. Pokémon must be unique. No duplicates of the same Pokémon species.

Mega Evolution

Mega Evolution is only allowed if both players are able to use Mega Evolution on a Pokémon.

Legendaries

Legenderies are not allowed

Pseudo-Legendaries (like Garchomp or Dragonite) are allowed.

Items

While Items are allowed to be held by Pokémon, using anything in active battle (like Potions) are not allowed.

Cheat Sheets

You are allowed to keep an open type chart to check effectiveness if needed.

Rules for Streaming

Gameplay

I don’t expect you to stream your entire playthrough. It’s perfectly fine to play privately if you want to, just please stream most of your gameplay.

Only at the start do all present participants and have the stream turned on.

Title

You have a lot of freedom when it comes to stream titles. I simply ask that you include "Project Xcyting" somewhere so viewers understand what it’s about.

Content

I understand that frustrating moments happen. I’m sure there will be times when you can be upset with me, too. You are absolutely welcome to express criticism as long as it stays respectful.

Rule Violations

In the end, I make the final decision on rule violations. Every case is different, but generally a rule violation will result in disqualification. If you believe someone is not following the rules, please let me know.

Xcyte (English)

Sun, 09 Nov 2025 00:00:00 GMT

How does all of this go?

Registrations

Registrations close on 23.01.2026 - 23:59

Participants

Participants will be announced on 26.01.2026

Start

The project will officially begin on the evening of 30.01.2026

Tournament

The tournament will take place on the weekends between 27.02.2026 - 29.03.2026. This gives everyone 4 weeks to prepare.

What if I don't stream?

Every streamer who gets selected will receive their own team that viewers can register for to play along. These teams will also compete in a league table at the end to earn points.

Where do I register?

Over this form: https://docs.google.com/forms/d/1rReyeOqfujPxCIsqXibnHvK54hdVzhMUfMV4rQIcLoo/edit?pli=1

Additionally, you can join onto this Discord Server if you're interested: https://discord.gg/SncBqdkQ2V

Choose your roles and you’re good to go!

What do I need to be able to participate?

Emulator

We're using the Azahar Emulator, as it is required for tools like Pokélink.

Pokélink

If you are a streamer, we need Pokélink so we can keep track of your team and progress.

The Game & Setup

After registrations close, we will provide help on the Discord server.

Rules when playing

Emulator Speed

Anything between 100-200% is allowed.

Cheats

All forms of cheats are strictly forbidden.

Pokémon

In your solo gameplay, you may use any Pokémon you feel fits your playstyle or asthetic.

Please use common sense when choosing names, avoid anything inappropriate.

Trading

Trading is fully allowed and encouraged between all players!

Battles

Test battles are allowed for training and to familiarize yourself with the battle rules.

Rules for Battle

Qualification

You qualify to participate by becoming the Champion of the Pokémon region.

Format

Single Battle (1v1) with 6 Pokémon, all automatically set to Level 50. Pokémon must be unique. No duplicates of the same Pokémon species.

Mega Evolution

Mega Evolution is only allowed if both players are able to use Mega Evolution on a Pokémon.

Legendaries

Legenderies are not allowed

Pseudo-Legendaries (like Garchomp or Dragonite) are allowed.

Items

While Items are allowed to be held by Pokémon, using anything in active battle (like Potions) are not allowed.

Cheat Sheets

You are allowed to keep an open type chart to check effectiveness if needed.

Rules for Streaming

Gameplay

I don’t expect you to stream your entire playthrough. It’s perfectly fine to play privately if you want to, just please stream most of your gameplay.

Only at the start do all present participants and have the stream turned on.

Title

You have a lot of freedom when it comes to stream titles. I simply ask that you include "Project Xcyting" somewhere so viewers understand what it’s about.

Content

I understand that frustrating moments happen. I’m sure there will be times when you can be upset with me, too. You are absolutely welcome to express criticism as long as it stays respectful.

Rule Violations

Cutesy

Fri, 19 Sep 2025 00:00:00 GMT

Trigger warning: American spelling

Do you know this feeling? You have added a bunch of logging and want to make things prettier? Pretty fast you find yourself looking add simple coloring and start seeing that it looks a little more complicated, starting to write your own little logger and keep copy pasting the same thing into your hundreds of projects thinking

I wish i could just use this everywhere?

Now if you only code in one programming language that seems like something that isn't a problem because you can just make a package for it and use it, like i did at first.

Now if you were to switch from JavaScript to something like Python you'd pretty quickly see that you have to rewrite your entire logic into python because the likelyhood of having the exact same logger in two languages is quite unlikely. You might find similarities but at the end you'll end up with something that works differently in one language than the other.

I decided to put an end because more than often i don't need complicated loggers but instead just a logger that is capabable of basic things.

Features

Uncomplicated coloring with the same default color pallette
Padding when using multiple loggers
Write to a file when promted to do so
Timestamps
Naming
Tracing

The goal? A small, simple, zero dependancy logger, that is both compatible with ANSI-8 and ANSI-256/Truecolor maintaining the same usage and functionality in every single language that the package exists for.

Behold the invention made back in 2022. The original concept: Cutesy ::github{repo="Calemy/cutesy"} :::note Cutesy's original package is now outdated by my new standards, but will be overhauled by the changes introduced in other languages. :::

Now i had a package that made logging easy for me!

JavaScript (cutesy)

import Logger from "cutesy.js" //version 1.2.3
const logger = new Logger() //currently uses ANSI-256 by default

logger.blue("This part is colored blue ").red("while this is red!").send()
logger.addTimestamp("hh:mm:ss").send("This text has a timestamp")
// => 04:31:05 - This text has a timestamp
logger.changeTag("Debug").send("This is a debug")
// => Debug | This text is a debug
logger.sendTraced("Where am I?")
//Where am I? -> /home/nanoo/cutesy/blog.js:9:7
logger.send("This should be saved inside a file.").save()
//Everything attatched to the message will be saved inside the file (Name, Timestamp, Trace)
logger.blurple()
//Now all messages are Blurple?!?!
logger.send("This message is Blurple")
logger.send("This one too!")
logger.green().send("Now it's green")
logger.send("Still green. surprising isn't it?")

Quickly i got a reality check when i switched to Go. There is no package that does the thing i want to do in a simple manner like i'm used to. So i got quickly to thinking and came up with the go-varient of cutesy. Currently called Goatsy. It's also my first Go code that i've published to GitHub!

::github{repo="Calemy/goatsy"}

Get it? It's funny because it's Go? Goatsy?

Oh it just isn't funny. Right..

Oh well now we try the same things we did in JavaScript.

Go (goatsy)

import "github.com/calemy/goatsy" //version 0.0.1

var logger = goatsy.New(&goatsy.Options{
	Truecolor:  true, //Enables truecolor, currently uses ANSI-256 by default which has to be changed.
	TimeFormat: time.DateTime,
})

logger.Blue("This part is colored blue ").Red("while this is red!").Send()
logger.Rename("Debug").Send("This is a debug")
logger.Trace("Where am I?")
//Where am I? -> /home/nanoo/goatsy/blog.go:10

//Saving to a file is currently a WIP

logger.Blurple()
//Now all messages are Blurple?!?!
logger.Send("This message is Blurple")
logger.Send("This one too!")
logger.Green().Send("Now it's green")
logger.Send("Still green. surprising isn't it?")
logger.Color("#ff0000", 9).Send("I now used a custom color, with a fallback in case truecolor is disabled.")

As you can see. It's quite similar to each other therefore i'll still do changes to cutesy to align it with goatsy.

I'm now working on a Python version which i would have called qtcpy which follows a similar concept to JavaScript.

My C version i would have called cuteC.

Now thinking about it, i should just stick with cutesy-ext.

Language Support List

Fully supported

JavaScript (cutesy) - The OG 🗣🗣🗣

Partily supported

Go (goatsy) (soon cutesy-go)

Work in Progress

Python

Planned

C/C++
Zig
Rust
Odin

If you have any wishes, let me know!

Amigo

Wed, 17 Sep 2025 00:00:00 GMT

During the time that I wrote Mino, I've been told a lot (specially during the early days before i knew what i know now) that i should consider switching from JavaScript, due to it's limitations and non-existent typing system. I shall now quote my favourite things that have been said to me:

"JavaScript is not very performant, and it's so unsafe!"
"If you want real performance, you should use C# or Rust"
"JavaScript is shit, you should use Python"
"At least use TypeScript for type-safety"

The TypeScript debate was always a heated one because i had a very clear standpoint on TypeScript that i have to this day.

You don't really need TypeScript if you know how to write good JavaScript.

The Issue i personally had with TypeScript is that it added unnecessary boilerplate to my codebase that i didn't need. I didn't work with others and had a clear structure of what my code did. Also, using TypeScript back in 2022 with node was just annoying (honestly it still is) and i didn't see any reason for myself to go through all of the pain just to add type-safety. I was confident enough to be able to say that i didn't need TypeScript since i've written good JavaScript code.

Someday in 2024 i started to use TypeScript more frequently in my projects but the earliest thing i've built was Tyro by the end of 2022. An osu!api emulator fully written in TypeScript to experiment around.

::github{repo="Calemy/tyro"}

By the end of 2024 i've fully migrated a JavaScript Project into TypeScript, Advance. The source code has not been updated by the time of writing this entry. The reason why is because it became a lot easier using TypeScript with a runtime like Bun, that supports TypeScript out of the box.

::github{repo="osuAdvance/Advance"}

Back in june of this year i've also rewritten Mino in TypeScript, making a few improvements but it has never been released as a stable version. This feeling of using TypeScript more commonly in my projects gave me the idea why not take it a step further and learn a new language?

Because in the end, some had a point. JavaScript does reach it's limitations when it comes to scaling, and Mino has been gathering over 1.5 million requests each month that have been handled.

How did we get here?

I've put my hands on a few programming langauges before including Python, C# and C++. I even had my hands on Go and Rust for a little and made the most rough sketch for imitating the download route and i've had to say, i didn't really enjoy it that much. It felt overly complex and kind of hard to get into, so i dropped the idea and left it for a while before deciding to try it again in July with the most promising looking language, Go.

I decided to take another proper look into the language and did a lot of trial and error. A solid week later i had the first version that i started to understand how things work in Go and started to experiment even more and got down the basics like structs, error handling and modules.

Over the entire month of July, i've started to actually enjoy re-coding this project into Go but of course i faced some challenges because things obviously work different than in JavaScript.

:::note For the future of this post i'll be just using TypeScript code in my examples. :::

The things i've noticed

Getting into Go was interesting because of the way how everything was handled.

Web Requests

You didn't have a native json function for web requests like you have in JavaScript.
You actually have to handle things like closing the web body in order to not leak memory, which also extends to other systems like files.
Making a simple web request usually ends up a little more boilerplate other than your typical fetch function in JavaScript.

try {
    const response = await fetch(`https://catboy.best/api`)
    const data = await response.json() as any
} catch (err) {
    throw err
}

quickly became

req, err := http.NewRequest("GET", "https://catboy.best/api", nil)
if err != nil {
	panic(err)
}

resp, err := (&http.Client{}).Do(req)
if err != nil {
	panic(err)
}

defer resp.Body.Close()

body, err := io.ReadAll(resp.Body)
if err != nil {
	panic(err)
}

var data map[string]interface{}

if err := json.Unmarshal(body, &data); err != nil {
    panic(err)
}

and the worst part is that parsing json in Go is another huge pain in the ass if you want to parse it into structs.

For those who are unaware structs are build like the following:

type User struct {
    ID int
    Username string
}

to parse json into a struct you have to define json fields on the struct.

type User struct {
    ID int `json:"id"`
    Username string `json:"username"`
}

if you were now to unmarshal json into the struct it would look like this

var user User

if err := json.Unmarshal(body, &user); err != nil {
    panic(err)
}

//Now you can access things like user.ID and user.Username

If you had any extra fields, you just wouldn't have them anywhere unlike in JavaScript. (Which honestly can be fine for most cases)

It does become a problem however, if you expect to have access to all dynamic fields at all times since you have to just know what payload you receive. With that in mind i made the basics and things seemed fine™ so i didn't care too much.

Multithreading

God i cannot describe how much i love goroutines. Just throw a "go" before a function and it runs on a seperate thread. How awesome is that? JavaScript could never be that smooth. Nodejs did introduce worker threads for a while but eh, it's just not the same and harder to manage. Speaking of harder to manage!

Promises (async)

JavaScript really spoiled me with promises, although Golang does not really need the same principle since goroutines make multithreading more available and if you want to wait for all the goroutines to finish, you just add a WaitGroup, call wg.Wait() and that's it.

async function networkTask(): Promise<number> {
    await Bun.sleep(1000)
    return 1
}

async function ioTask(): Promise<number> {
    await Bun.sleep(2000)
    return 1
}

//Instead of calling:

await networkTask() //takes 1 second
await ioTask() //takes 2 seconds
//Total wait time: 3 seconds

//you instead use:

await Promise.all([
    networkTask(),
    ioTask()
])
//for a total wait time of 2 seconds since we wait for the slowest to finish loading in parallel.

in Go the same principle looks like this:

var wg sync.WaitGroup

func main(){
    //instead of:
    networkTask()
    ioTask()

    //use:
    wg.Add(2)
    go func(){
        defer wg.Done()
        networkTask()
    }

    go func(){
        defer wg.Done()
        ioTask()
    }

    wg.Wait()
}

func networkTask() int {
    time.Sleep(time.Second)
    return 1
}

func ioTask() int {
    time.Sleep(time.Second * 2)
    return 1
}

Works perfectly fine and isn't much different from javascript while doing "true" multithreading.

Yes i know there are channels for promises, but eh i don't want to get into that here.

I was very fascinated by the way how ratelimiting worked on multithreading, that i even made a JavaScript module to make it easier there too. ::github{repo="Calemy/ticking"}

The works

Anyways, i worked on this Go version a lot and even worked on it during Cavoe's osu! Event 2025 in August with feedback of a few friends of mine. Shoutout to Marti (you absolute 👑) for letting me use his laptop to actively code on it since i left mine at home.

I managed to cut loading times during routes like audio preview or novideo files, improving them up to a whopping 50x performance increase.

To put some perspective; serving the .osz of the Unforgiving without video took:

about 5 seconds on Mino Version 4
2.5 seconds with multithreading on the unreleased Mino Version 5
while it got reduced to only 150ms in Go.

you can see similar improvements for audio preview and raw audio serving, which makes it a huge success.

After a lot of testing around with the database, i've now decided to take a hybrid approach; Filling meilisearch with only necessary data that is relevant for searching, while storing the full data now in sqlite. Yes, you've heard this correctly. I'm using sqlite for a high scale application because Mino actually reads most of the time when it's not actively crawling from 0, which makes sqlite a perfect fit since it's lightweight, doesn't not need to be installed as an extra dependency and is also blazing fast, having a very low response time.

This also made me rethink my approach on my structs because if you ever looked at osu's api v2, it gets messy really quick. Instead of treating every field in a column i just dynamically store the json as it's own data field. This way it stays dynamically updated at all times so i always stay compliant with the newest api v2 spec. It also means i don't need to parse the entire json anymore for each entry, which also saves a little time.

Now if you've read the first post of mine, you might ask me: But Nanoo, what about Cheesegull?

Yes, i thought about that, but since i don't even need most of the fields. Using go's native unmarshal would be wasteful, because it goes through the entire json. Instead i use gjson and only select the fields i need. (which in my case is about 10 fields out of like 25 or so) and save myself a lot of memory, since i hold less bytes and cpu time.

So far that has been my Journey with Amigo, and i'll keep you updated.

Beemo

Mon, 01 Aug 2022 00:00:00 GMT

This is where it all began

::github{repo="Calemy/beemo"}

Mino

Sat, 12 Mar 2022 00:00:00 GMT

My biggest project to this day is Mino. A from scratch written JavaScript Beatmap Mirror that has everything someone could ask for. It even became the name for a company i'm a part of!

But how did i even get the idea?

Well, simply said: i was tired that everyone else sucked.

You had mirrors like Chimu, Beatconnect or Kitsu that all came with major drawbacks.

Chimu was in maintenance
Beatconnect was horrendously slow and had no public api
Kitsu was new and unreliable to stay running

One day i was annoyed and thought: what the hell, why not just make my own? How hard can it be?

So i made some sketching for what i'd need to do.

Step 1 - The database

I was lucky to be so far involved with Kitsu, that i had access to the structure they used. I followed the structure and therefore landed on using mysql as my database to store the metadata.

Step 2 - The API

Step 2.1 Metadata

Getting the metadata via crawling was the next step so i can populate the database. It was relatively easy back then using the osu! api v1 by using an api key. It did limit me to 60 requests/min though.

Step 2.2 Beatmaps (.osz files)

Now the tricky part was getting the actual .osz files to store and serve when requested. After a lot of digging, i found out that the osu! api v2 does in fact have an endpoint for downloads! check notes

oh wait it's locked behind a client scope... sigh great.

After some more digging i got the necessary resources to emulate the lazer client which i won't disclose exactly how and got the necessary scope to make the request.

Step 2.3 Beatmaps (.osu files)

This was fairly easy because .osu files are served via a different api that is public. Requesting https://osu.ppy.sh/osu/:id would give me the .osu file for the difficulty which is all i needed.

Step 3 - Implementation

Now i got everything i needed to have the most basic mirror that has metadata and files that are cached once requested. I did a very quick implementation and tested it out on my own osu! server Horizon since that was the initial trigger of why i got mad in the first place.

Things looked fine and things loaded slow at the beginning and when cached immediately loaded, which at the time, was a win in my book.

I then wanted to figure out how to do beatmap searching inside the client so that's what i worked on next.

After some request catching inside the server's console i made a quick mockup inside my own API doing your typical full text search shenanigans. Once finished, i did some testing and it worked great! I got the songs i was looking for and the filters were working fine.

I got so excited about how "fast" things were running, that i recorded a video and asked RealistikDash (a virtual collegue of mine) to check it out.

He got back to me soon after, and asked me if he could test it on his own server aswell. I told him that i don't have a public endpoint yet, since it was in development and not made for usage outside of my server but that i'll get on it. So i took a random domain i still had laying around; catboy.best and slapped my service onto it naming it Mino.

Of course having a quick laughter about it, he also informed me that the search did not work for him and we went investigating. And there it hit us, Cheesegull.

:::note[Cheesegull]

Ripple's formatting for beatmaps used in most osu! private server instances made back in 2016 :::

Step 4 - Cheesegull

To satisfy the standard for Cheesegull i did some rewriting of the API and let me tell you, Cheesegull definetly had it's deserved place! But now it's just a pain in the ass since api v2 exists and literally everyone still adopts Cheesegull as the standard in their server (what's up with that anyways?)

After doing those changes i got back to my RealistikDash and he gave me the green light that everything worked as expected. He also suggested to make it a public thing since it went really fast and people could use it considering the asfore above mentioned and i thought sure what's the worst that could happen?

Well, the "worst" that happened is that it actually gained attraction from other server owners and developers. And of course when something is booming in the backend the first question asked by a user is "when frontend?"

Step 5 - Frontend

I'm not a frontend genius, by any means. I used some bootstrap and wrote some silly little thing in like 2 days worth of time that featured:

Homepage

A landing page where you can see the crawler's progress and what data has been recently added.

Search

A search page to search for beatmaps! (wow)

About

A quick overview of what this project actually is, who contributed to it and a discord server to join.

Of course not forgetting about an E-Mail for DMCA complains. (still haven't received one now that i think about it)

Time flies and all of a sudden in the span of a month, most people have switched to my mirror. Well great now i'm stuck with the domain catboy.best for this because i didn't think this would actually take off.

In the meantime i made a switch from my database going from mysql to meilisearch. A search database designed for specifically that and have not switched off from since and also marked Version 2. (besides this weird mongo phase i had for a month but psscht we don't talk about it here)

Fixes & Optimizations

Of course, with the growing amount of users, there were bugs bound to be discovered and optimizations to be made for a more stable Mino. It's not some small 4 fun project anymore but instead developers decided to actually use it as a dependancy so i had to use the advantage. Another month passes by, Chimu gets out of maintenance. Once a giant lost 50% of it's users, Kitsu rebrands and rewrites their backend but lost 80% of their users due to prior complications. All of those users got to me, but now it's more intense because Mino has to perform well to stay on top. I also got some concerning amount of negativity back from a certain developer that shall not be named who wasn't happy with my mirror's existence.

Quick Rundown of what else happened

Since the project is 3 years old at the time of the writing (September 19th, 2025), i'll spare you the boring details (since i can't remember most of them anyways)

Webosu - May 2022

Mino became the main mirror for the web ported version of osu! webosu!

bancho.py - June 2022

Mino also became the standard in cmyui's bancho.py (formerly gulag) repository. Go check it out if you're interested in making an osu server for yourself.

::github{repo="osuAkatsuki/bancho.py"}

Team-Up with Philsty - July 2022

Since 2022 i've been working closely with Phil. He was so kind and provided a big part of Mino's infrastructure and taught me to think about things that i haven't paid much attention to before. He also works with me on Advance!

Geolocation - October 2022

We setup multiple server (one in the US and one in Europe) and gave it automatic geolocation so each user has the smoothest experience.

CI/CD - April 2023

With the work of Phil, pushing changes to servers (yes, at that point it was servers) was automated and worked like a charm.

Version 3 - September 2023

Mino officially rolled out Version 3 with the new versioning system (i've done a billion rewrites and called them by major versions before)
Therefore i landed from Version 7 to Version 3.3.6
Major bug fixes that affected stability and performance
Introduced the fastest latency making it the top contender since
Huge consistency upgrades

Version 4 - March 2024

Mino officially rolled out Version 4 making great changes to internal structure.
Database optimizations
Performance improvements on certain routes
Minor Bug fixes

Frontend Rewrite - July 2024

Refining my frontend skills, i decided to give it another go
No bootstrap, but tailwind
Cleaner and more modern UI
It's still bad, but at least it looks nicer and displays the pure backend performance.

Version 5 (The TypeScript update) - June 2025

Rewritten Mino in TypeScript using Bun
Increasing performance on bucket requests
Increasing general performance across all routes using Bun's http module
Pain and suffering figuring out Bun's http module and Zig

The Future - Pending

Since this is fairly recent, you'll be able to know about it on another blog post. Stay tuned!

Last Words

Thanks for listening to this yap fest of a blog post. This is my very first, so i hope you were able to not only endure but also enjoy it as much as i did writing this.

Special Thanks

RealistikDash
Philsty
cmyui
lenforiee
tsunyoku