Any interesting insights about using Godot with C#? I love C# and I'm happy using it in Godot even though it's not as seamless as in Unity: in Godot 4 we still can't export to Web if the project is C#, and there's the whole conversion between C# types and Godot types that adds inefficiencies and extra allocations, etc.; it feels like it's a second-class language in Godot.
I'm always interested in seeing what people find when developing larger projects in C#.
The founding developers were all software engineers with .NET experience, so it was the natural choice even though at the time it was Godot 3.x with Mono. I had used Unity before but not Godot. The project is structured as mostly plain C# DLLs with a relatively thin Godot UI layer controlling it, so the Godot type system is fairly encapsulated. We haven't really seen any issues with those decisions beyond just working out the communication between Godot and DLL. But again we were just working from what we knew so I can't really say if this was the best way to go about it.
We were building on C# Godot and I think it is a second class citizen in the sense that 1) you can't export to wasm and 2) they are moving the interface to be handled by gdextension.
That said, I think once you get the gist of it and understand the landmines, it is really nice to use vanilla dotnet rather than unity's fork.
I have this principle of "5% scripting". If the high level scripting on top of C++ consumes about 5% of frame time, then the language of the script does not matter.
I'm assuming this is the same (or evolved) Lazy Tetris that you posted some weeks ago, with the name changed because of their trademark, right? I was wondering why it had disappeared for me a while ago and I found this again now :)
I think you could place a link from the old website to the new one, or a redirect, especially since the old HN post was relatively big. I had a bookmark and checked every now and then in case it would come back, and only now found it again by going through your HN account posts. Pleasant surprise!
I've played it on desktop (firefox) and android (firefox). The drop animation is super nice!
On android it works great, i love the controls, just dragging to place horizontally and then pressing drop, super satisfying!
On desktop, I would have one suggestion: right now I have to drag the cursor to place the piece horizontally, click to rotate, but then i have to move the cursor to the drop button to drop. Pressing space works, but sometimes I'd want to play with just the mouse, no keyboard. I think middle click could be a good way to drop the piece with just the mouse (double click too, but then you run into timing issues with the left click, so I think middle click is better).
Also, maybe an option to follow the cursor instead of having to drag/drop? So the play flow would be just moving the cursor, click to rotate, middle click to drop.
Also also, a link somewhere to be able to contact, in case of suggestions, questions, etc. :)
In Unity3D Game Engine, "Yellow" as a named color is not #ffff00 but #ffeb04, the documentation says "RGBA is (1, 0.92, 0.016, 1), but the color is nice to look at!". I bet this bit the ass of thousands of developers that used it assuming it would be #ffff00 and then wondering why the output color somewhere was wrong.
It's not about the time it takes to say "hello" back. It's about synchronization steps. What if I don't see the first message right away (i might not see the notification, or I was busy with something else, or I was AFK, etc etc)? Then I reply 20 minutes after with just a "hello" because I don't know what they wanted at all, so I can't reply with any information. Then they might take 20 minutes to respond because they aren't going to sit for an answer, etc etc.
It's a waste of interruptions. And for some types of work, like programming (we're in HN after all), interruptions can be more costly than just the "4 seconds" it takes to reply. Them saying "hello" and then without waiting for a reply explaining what they want in a short way, is more efficient and respectful of your time (and theirs, to be honest).
Given that you just care about 4 digit codes (so you don't actually care about a generic algorithm that's not super slow in asymptotic time), can't you just solve it with an easy to code bruteforce algorithm? Or is the combinatorial explosion so big that it's actually intractable that way?
Think about this. You need to calculate the number of permutation for 4 digit codes. Then you need to arrange them in every order possible to brute force. So that’s 4!!. That’s a lot: roughly 620000000000000000000000 combos.
That's the number of possible codes. Not the number of possible ways you could arrange all 10000 codes to see which ordering contains the most shortcuts.
i have a python script running through that right now to find "the shortest" and it's been burning a single core for at least 6 hours. So it looks like you are right and i am wrong ;-)
i assume my pc on a single core can do ~1billion permutations per second, this will take 19,647 millennia. AFK.
what do you think the chances are, if i let this run, that it would find a shorter solution than 625 keypresses? the naive De Bruijn algorithm popped that out in like 2 seconds.
I suspect it's because they don't want you to focus on the past, only the present. Or maybe it's because it would either highlight how irrelevant the change is, or how annoying the new one is.
I have an extra suggestion: Maybe some keyboard key mapping, like up/down for switching the channel. I'm imagining having this perma-running in a small PC connected to a TV and the small wireless remotes have mappings for the arrow keys and up/down for channel would be perfect for that. (maybe other mappings as well)
I'm always interested in seeing what people find when developing larger projects in C#.