Thank you very much for you comment @kalmarr, I really appreciate it :D

For the looks of it my guess is that you wrote the comment while reading it, so the GDD itself might answered some of the questions, but i’ll elaborate on them anyway in case something comes up:

1. I’m aware that multiplayer is hard to do, and that’s actually something that I’m not only interested in, but actually want (and maybe need) to learn in order to do some of the future games that I actually want to make for the masses, not just to learn.

   The main reason why I picked up Ebitengine is because its made in Go, so I’ll be able to make all the multiplayer stuff on a “low level” (not sure if that’s what people call it), in a sense that I’ll be able to have create everything from scratch instead of relying on APIs and whatnot (even thought I’m sure they are really good, but my idea is to learn as much as possible from scratch instead of starting from something pre-made).

   Since you said is difficult to debug, I’ll make sure, before starting to develop multiplayer, to see if I can make some sort of debug-system (maybe timestamped logs of some sort) to help me debug when needed, and maybe search how other have made it before me.

2. I tried to make the game as simple as possible, but not boring for me when developing. My idea when “designing” the game was for me to have some kind of interesting stuff to make, not just to copy-paste already established “easy-to-dev” games like a platformer or something the like. I know and understand that, without prior game-dev-knowledge probably it will be a disaster, something that I’m okey with since that how we learn, my making mistakes and learn from them.

   In Da’ Plan section I talked about the way I’ll develop the game, and is by doing it incrementally, instead of everything at once.

3. Yeah you’re right, the UI controls are weird XD. At the time of writing it I was more focused on how it will look and feel when using it than the controls. My main idea is to use only the resting-position-keys of the keyboard (ASDF, JKLÑ (in a spanish keyboard)).

   I want to avoid using the arrow keys, since that forces the user to move his hand from the resting position to the arrow keys, maybe I’ll just stick the usual WASD default movement keys used in most games and called it a day.

4. Now, this comment actually make me laugh a bit XD. It sure does sound strange to start from something boring and not the prototype/the game itself. So I’ll share my view on this and why I want to start from there.

   I don’t know anything about how stuff renders and where its placed and whatnot. So, instead of jumping right on the game, first I want to see how simple things like font are rendered and placed on the screen. How it affects the size of the window (for example, when change on window mode instead of full-screen) of when the FPS/Hz of the monitors vary (I’m lucky enough to have a 60Hz monitor and 120Hz monitor side by side in order to see how it affects).

   My main goal is to see how to place things and resize then dynamically, so that when I go to do the “real deal” I’m aware of what to have in mind when developing it.

   In my short time developing stuff, I learned that the “boring stuff”/“minor details” are ignored/skipped by most of developers (the friend and colleges that I know over the years) and, later on, they get “screwed” by it. For example, lets say that I jump straight into the “transition stage” of the game and I develop it in its entirety. I see that it only work on a certain ratio, and it doesn’t adapt to other sizes, now I have to learn that, and potentially “fix” the issues. But when “fixing it”, I end up creating something that not as good as it could be (be it on performance or on code maintenance/readability point).

   So, whenever I develop something, I tend to plan out things, and try to implement first the most (not sure how do I put it) “impactful things”. That why, when later on I need to have something for anything, I already have it build onto it already on the go, and I just reuse it, or use that implementation from the start. (Not sure if I explained my self properly).

   Some example that comes to mind are the trees in Heartbound. On one of the occasions that I saw PirateSoftware stream about it, he was developing a scene with a bunch of trees. They where overlapping and didn’t make sense, then he went on to explain that he didn’t have to care how he placed them, since the programming it a way that they sort out by themselves. That kind of mindset on things is what I’m trying to apply with anything I’m doing: “Making myself easier to work on things form the start, rather than open my self work in the future.”

To be fair with everyone, including myself, I don’t intent to create a game that will be “the next hit” or by “the most interesting rhythm games”, all of the ones that you enlisted are good ones (and some of them are the inspirations). My main focus when designing the game was to have it apply the ideas, not just copy-paste them or applied them just as they are (what would be the point of making a copy of something that already exists? They know how to make it better or if a part 2 is needed). I’ll understand if its not something “new” of “game breaking” since that not my goal (and to be fair, I lack the imagination to do something like that).

About the buttons, actually its intended XD. I personally like the idea of using the hole keyboard to play a rhythm game, not just 2 buttons (Osu) or 4 (FNF). But that just my subjective opinion.

Anyway, thanks again for you comment, and I hope I’ve elaborate good enough the points you made. If there anything you want to further comment, I’m all for it. (And I’ve write down the points you make, thank you :D)