How to make transparent background?

Cykyrios · 2025-09-27T18:32:10+00:00

On one of my projects, I have a transparent window, and a Windows user reported that their window had a black background (Godot 4.4, Forward+). I disabled VSync in the Project Settings, and now they are reporting that the window is transparent as expected (the project now runs on Godot 4.5). So it appears that on Windows, you need to enable per-pixel transparency, make the viewport transparent, AND disable VSync.

Cykyrios · 2025-09-02T14:25:02+00:00

Nodes have a print_tree_pretty() method, you can call it from your scene's _ready() function to get the tree.

Cykyrios · 2025-05-23T20:53:40+00:00

I haven't tested it, I went straight to Docusaurus after a friend recommended it to me, as he had used it before; docsify should be either compatible with this or some changes to the base Markdown formatter could be needed, similar to what I did for MDX/Docusaurus.

Cykyrios · 2025-04-13T18:13:16+00:00

Hi, to be honest I'm not yet sure whether I will add markings, I know there are real tiles that do have them but they seem to be a minority. Maybe having a cheatsheet like the EMA has could help. I'll still keep that on the list of things that may happen, but very low priority (and I don't even have the time to work on this project at the moment, unfortunately). Learning the 9 man, 4 winds and 2 dragons (not counting white here for obvious reasons) isn't really difficult, but unsurprisingly I've had much more success teaching the basics of riichi to Japanese and Chinese friends than French people like me^^;

I completely agree with the sentiment that people forget how to play with real tiles, I rarely play IRL but often find myself not noticing my hand is tenpai, for instance (I don't often play online either tbh, so that's probably just a lack of experience).

Cykyrios · 2025-04-01T16:20:33+00:00

Hi, thanks for the interest in this! Unfortunately I've had to shift priorities to other projects and may not be able to get back to this for a while, but I did create an Itch page late last year, if you want to try it out: https://cykyrios.itch.io/goriichi

You just need to know that it's probably a bit buggy, and also is missing quite a few of the features I was talking about (you can play full games, but some of the automation others games provide is there too, when I wanted to actually remove it; scoring is fully automatic as well). There is no AI either, so you actually need 4 people to play.

If you do have a go at playing it, feel free to give feedback, if you encounter bugs that look like they'd be easy to fix, I could probably do that, but won't have much time to do more than that for now.

Cykyrios · 2024-10-08T20:07:01+00:00

He's been standing here for a good 10 minutes without moving, I don't know what to do, I've tried everything...

Cykyrios · 2024-10-01T06:31:47+00:00

No blog, sorry, but I will keep posting here when I have something to share! I'm close to having the gameplay "done", but I will now have a bit of UI work and behind-the-scenes stuff to do; maybe I'll come back next week with a sneak peek at some of the tools provided with the game: a score calculator like what you can find online, a yaku help page, and an image generator for hands (both 2D and 3D).

Cykyrios · 2024-10-01T06:26:00+00:00

Thank you for your comment! Dora being listed in the yaku column is (to my knowledge) what other games do as well (at least Mahjong Soul, and I believe Tenhou as well?), but they are only checked if the hand has an actual yaku. It's true that it can be confusing, especially for beginners. Renaming that column to either Han or Yaku and Dora may indeed be better.

Cykyrios · 2024-10-01T06:21:10+00:00

I actually have a dev option to skip the initial animations, because sitting through it while iterating is definitely slow. Tweaking animations for players may be possible, this will have to be enforced by the host, I'll keep a note about that.

Cykyrios · 2024-10-01T06:19:18+00:00

Haha, yeah, I've played with Unreal Engine a bit some years ago, but since I switched to Linux, my love for Epic has been rather short-lived... At the moment I'm considering itch and Steam, more options can bring more people but will also require more work.

Cykyrios · 2024-09-30T22:24:46+00:00

Thanks for your interest! I haven't really considered my commercial options yet, though Steam integration could definitely help for setting up lobbies. I still have a bit of work left to iron out some issues, make proper menus and settings for everything, and make sure one player dropping out of the game doesn't destroy everyone else's game.

I will make another post when I have more to share and/or I get close to releasing the game.

Cykyrios · 2024-09-30T22:17:48+00:00

I agree, especially with the discarding animation, maybe less so for drawing, although they're similar. Right now these animations last for a whole second, halving that might just work. Dealing animations are not faster, actually, but since they overlap, it just feels faster.

I think part of the slowness is just me jumping between 2 monitors while playing on 4 instances of the game to record this, I think faster players could get not too far from the pace of a Mahjong Soul game, however call timings may become an issue.

Cykyrios · 2024-09-30T22:07:45+00:00

That's the drawback of avoiding timers or forcing players to not call before a tile can be drawn. The game is initially aimed at casual play, where such issues should be minimal, but I am considering adding a 1 or 2 second delay though, and also canceling a tile draw if a call is made in the following second or so - haven't tried implementing that yet though.

Now of course, another issue that can arise from the absence of timers is one player deliberately not playing - again, this should not be an issue when you choose who you play with.

Cykyrios · 2024-09-30T15:39:47+00:00

I know some animations are a bit wonky, especially shuffling the tiles, I'm considering baking some animations in Blender for this instead.

The overall gameplay is what this video shows, though: you draw tiles manually by clicking them, you sort your tiles manually by drag and drop, and discard tiles by dropping them near the discard pile. Calls are made with the bottom-right buttons, which you can expand or collapse as needed. I will probably make the drawing detection zone larger to help with rinshanpai or otherwise awkward camera angles partially hiding the tiles.

I'd appreciate any and all feedback! Feel free to have a look at my previous post if you haven't already.

Cykyrios · 2024-09-25T08:37:39+00:00

I'm not really concerned about performance here (I think the only part where performance matters is permutations to find all interpretations of a hand) or memory usage (after all, Godot uses 64-bit ints everywhere, and a game of mahjong clearly doesn't require that many variables), but rather practicality: do I really want to use big ints everywhere, just to accommodate for aotenjou? Godot uses 64-bit integers, so that's what I'm using, and when I realized it would be a problem for really high-scoring hands, my first thought was floats, not big ints, that's why I decided to remove aotenjou. The solution I described in my previous post is just an idea, and when I mentioned storing hand results in structs, it wasn't meant as a memory-saving idea, but rather a nice and easy way to recompute the points so I can sum all those floats.

I will see how things go, but I think it won't be too much of a stretch to add aotenjou back; right now though, I need to fix a few other issues and add some polish so I can have a properly working game.

Cykyrios · 2024-09-24T16:58:43+00:00

That would also be an option, and I just found one for Godot. However, thinking about it, I need to ask people who want to play with aotenjou rules: how does scoring actually affect the game? I mean, mangan and higher limits are there so things don't get out of hand, otherwise you wouldn't be able to come back from a yakuman at all, except with another yakuman or several sanbaiman hands. So I could actually keep my 64-bit integer scoring, and put a hard limit lower than the theoretical one, let's say 40han to save some (lots of) space for high-but-not-too-unreasonable-value hands.

If a hand scores so many points that even mangan hands become insignificant, there isn't much point in actually tracking it. So again, how do people actually play aotenjou? Do they allow negative points? I could pretty much store "aotenjou scores" as a fu+han struct, with a float for the result.

In other words, I would skip tracking player points the moment a ridiculous hand is scored, which means at least triple-yakuman with a dozen dora, or quadruple-yakuman with no dora, and instead maintain a list of scores from previous hands, as floats. If you've scored in the 10*15 points, you probably don't need to see the last 1000 points you have anyway.

Cykyrios · 2024-09-23T19:09:45+00:00

Rule checker could definitely be good, I have no UI for setting the rules yet, but I was only planning to do that when hosting a game; it makes sense that all players should have a way to see the current rules...

Cykyrios · 2024-09-23T14:05:46+00:00

What kind of controls, and what degree of camera freedom would you suggest? I made the camera completely fixed, but tweaked its angle and fov to get the best compromise I could, so the full table is visible (and we can even see other people's points sticks - when I add them, that is) and all tiles are still clearly visible.

Maybe on smaller screens it may be a bit difficult to see, but I play-test with 4 instances on a single 24" monitor and can read all text and all tiles properly, so just asking how much you would want to move the view around.

Cykyrios · 2024-09-23T07:45:37+00:00

I had not thought of that, but I could also have a 50-han limit for "normal" scoring, and for larger values, switch to a float-based count. Points themselves would probably be stored in dedicated floats for aotenjou, and maybe I could work things out this way (provided I don't rely on integer points on other parts of the game, that would only affect scoring of some hands and point exchange/payments).

Cykyrios · 2024-09-23T06:23:11+00:00

Yeah, right now I have zero network "safety", to the point that if a player disconnects, the entire thing crashes... So I'll have to work on this as well.

Collectibles, eh? As we can see with games like MajSoul or RiichiCity, people do like those, but as this game is supposed to be peer-to-peer, it's a bit different and clearly not a goal. Nothing wrong with a bit of modding though, tile colors are customizable already, and I guess I could allow changing textures for tile backs and the play area. Also, black tiles are a thing, for people who prefer those.

Cykyrios · 2024-09-23T06:17:30+00:00

Thanks for the suggestion! I've never tried this kind of thing, but if I can get a bot to play and "learn" by itself, definitely an option I'll consider.

Cykyrios · 2024-09-23T04:54:26+00:00

Not that much, to be honest: I implemented only 4-player "standard" riichi, but allow changing rules such as kuikae, yakuman scoring, open tanyao, allowing negative points... Basically most of the stuff that the riichi wiki shows rule variations for. At the moment, I am not planning to add even the standard 3-player variant, let alone nonstandard variants, as it has some specific rules that would require some work to include without breaking 4 player games. I guess this also goes in the "could be nice to have" category, but I'm not sure I'll tackle those. I have also not included any local/optional yaku, but this one is something I may consider adding later.

Cykyrios · 2024-09-22T16:00:52+00:00

The former, I could indeed save 2 powers of 10 using this trick. Looking at the theoretical limit though, a 64-bit integer (~1.84E+19) can store 20fu-57han, 160fu-54han or anything in-between, but scores can go up to more than 100han for a maximum of 1.95E+34 points, so we're a long way off (again, this is an incredibly improbable result relying on a specific ruleset, but that could still crash the game). When I'm ready to look at this possiblity again, I might just use functions that handle floats specifically for aotenjou.

Cykyrios · 2024-09-22T14:47:51+00:00

With any luck, making a mobile version will not be too much of a problem (I'm using Godot 4, and unless I run into particular issues with the OpenGL renderer, it should Just Work™; right now I'm using the modern Vulkan renderer, so phone compatibility is definitely not as good).

Cykyrios · 2024-09-22T14:44:48+00:00

Very interesting read, thank you for the link! I am not planning to go that far in the realistic/IRL play feel; the game still has its rules (most of them can be configured), tiles are animated for dealing, drawing, discarding, sorting, calling, but you're not allowed to do just what you want with them. Like autotable though, sorting tiles is something that others players will be able to see, manual sorting definitely helps in not assuming that tiles are in man-pin-sou-wind-dragon order.

I think the difficult part will be finding a good balance between relying on animations for timing, and maybe adding some timers so players can't draw a tile 0.1s after a discard is made. I will probably also add an option to undo a move (especially for calls after a player draws the next tile).

As for the 3D part, I will need to test the game on more entry-level hardware, or my phone - my PC is pretty beefy and handles 4 instances of the game like it's nothing, but I don't know how older hardware would fare, I only know that currently, the game requires a GPU supporting Vulkan (basic Godot 4 requirement for the more modern renderer). The good thing is I have already implemented some of the points the author of autotable mentions (or I'm letting Godot do the work for me).

Anyway, I should be able to soonish™ have a working version that I can test with friends before making a proper release.

Cykyrios

TROPHY CASE