> Godot is for people who want to make games but don't care for programming and would rather use a GUI for development.
You can write a lot of code when using Godot and mix that with capabilities provided by their editor.
You never have to use editor features, but can use them to avoid wasting time reinventing the wheel.
Your comment is like saying that game engines are used by people who don't care for programming and would rather make a call to handle physics interactions.
It's always funny to me that this metaphor is used to indicate a bad thing, but re-inventing the wheel is actually very valuable. Note that our vehicles do not run on stone wheels. Thank goodness we kept re-inventing wheels that were more suitable for our specific use cases! This metaphor is, therefore, exactly apt for describing off-the-shelf game engines. All of the big open game engines are heavy and make a ton of decisions for you that will not be optimal for your specific game, because they make generalized decisions necessary to support all kinds of games. This does save you time, and you can absolutely make games that are good enough with them, but it's ridiculous to me to describe making your own engine as wasting time. It's spending time to gain a benefit, which is a trade-off that is worth it for some and not necessary for others.
Are you going writing your own programming language as well? Can we call it Tolkien? Because you're making a game like J.R.R. Tolkien wrote books, and there's a reason nobody writes books the way he wrote his.
Writing your own engine is great if you want to learn how to write a game engine. Knowing how to make a game engine can be helpful when making a game, but it's not necessary to make a game. Further, if you want to learn how to make a game, it might be more worth your time to simply use an engine that already does all the things you need. That way your time and energy can be focused on making the game, which is what your goal is.
Being condescending or dismissive of tools that do everything your tools you're going out of your way to construct will have to do is... weird logic. Because the same argument goes all the way down. Why wouldn't you make your own text editor? Why wouldn't you make your own compiler? Why wouldn't you make your own kernel? Why wouldn't you make your own architecture? "If you wish to make a pie from scratch, you must first invent the universe."
The answer is: because we're human beings with limited lifespans. We must stand on the shoulders of giants to see further.
One person wrote books like JRR Tolkien. His name was JRR Tolkien, and those books are widely celebrated by millions of people as classics.
I don’t have any issue with people using an engine like Godot or Unity or RPG Maker or Unreal or anything else, but I do think that there can be value in “owning the entire stack” of a project, even if that means “reinventing the wheel”.
When I do a project involving HTTP, I could reach for Rails or something, it’s a valid enough and I certainly have done that plenty of times, but I often will work with a lower level protocol. Depending on the language I will use a more simple HTTP server thing like Axum with Rust, and other times I will go full epoll/Selector with a raw socket.
I do this for a variety of reasons, but the main one is that I can build my own framework that works in a way that I think and I don’t pull in a bunch of extra crap I don’t need. I can optimize the “hot paths” of my particular project without worrying about a one-size-fits-all you get for generic frameworks, I don’t have to worry as much about leaky abstractions, and I am intimately familiar with a much larger percentage of the codebase.
Tolkien was exceptional and dedicated his entire life to it. 99.99+% of all people do not possess such a combination of talent and focus and therefore end up having to use “shortcuts”.
> and there's a reason nobody writes books the way he wrote his
And there's a reason nobody came even close to his grandiose.
> Being condescending or dismissive of tools that do everything your tools you're going out of your way to construct will have to do is... weird logic.
They've merely pointed out that there's nothing wrong with reinventing tools, you're the one attacking them.
It sounds like you don't like programming. I am in the process of writing my own language/IDE/compiler on the side of making games, and have already written a dialect of C# with a compiler that transpiles it to legal C# for use in the meantime. I would, in fact, love to write my own OS if not for the fact that proprietary hardware vendors make it virtually impossible for anybody to create a new OS that runs on consumer hardware in the year 2026. If you gave me a trillion dollars with which to build a CPU factory, I'd jump at the chance to learn that too.
People who don't like programming, who wish to abstract it all away and "stand on the shoulders of giants"[1] without understanding anything about the giants, seem to view low-level code as a bogeyman. It doesn't take a lifetime to understand. To the contrary, I would argue that low-level code is easier to work with than working only with high-level code, because you can reason about it. The more you rely on abstractions you don't understand, the more impossible it becomes to effectively reason about anything, because your reasoning is glossing over the details that make things work. But reasoning about primitives, and the things built out of those primitives that you understand, is not actually nearly as hard as the people who just want to plop Javascript libraries together and stop thinking about it would believe.
In particular, when it comes to games, especially 2D games (which are what Godot and MonoGame are typically used for), it's really not that hard. Windows has an API for doing X, Y and Z with graphics. Linux has an API for doing X, Y, and Z for graphics. You write a wrapper that your game code calls that passes through calls to each of those APIs with an #if statement filtering for which OS you're running on. Rinse and repeat the other set of platforms, with a bit of extra finangling for API limitations on web and phone OSes. Rinse and repeat for audio, input, and font handling. It took less than a month of work for me to get a polished cross-platform system working on five platforms. Not because I'm a genius, but because it's seriously just not hard. There are a thousand tutorials and books you could pick from that will give you a rundown of exactly how to do it.
Then, for example, writing your own rudimentary 2D GUI map editor can literally be done in a day. Presumably you know how to code a main menu. Add an option to the main menu that changes the gamestate to State.MapEditor when selected. Set a keybind on this state where your arrow keys increment or decrement X/Y coordinates, a keybind to place tiles/objects, a keybind to cycle which object ID is selected, and a keybind that calls a function which serializes your map state to text and saves it to a file. A little bit more work for a moving camera viewport, but it's not that hard. Want more features, polish it more. When you fully understand the primitives your system is built with, adding new features can be done quickly and easily, because it's so easy to reason about compared to reasoning about code you've never read built with primitives you don't understand.
3D does up the difficulty level, but it's by no means unachievable, either. The content creator Tsoding is currently doing a semi-weekly challenge to build his own 3D game engine from scratch on video, and he's making great progress despite not spending that much time on it, a side project that gets a few hours a week.
The end result of all this is a codebase that is more performant, lightweight, easy to read, and very easy to extend. I think developing your own engine can actually save time in the long run (if you're willing to forego the instant gratification), because it's so easy to fix bugs and add new features when you have a complete mental map of your codebase and the primitives used to construct it. For example, I have a friend who used Godot to develop a game, and they've been plagued for months with a low percentage chance of fatal crashes on a boss that they are completely unable to identify and fix, and it's because they don't have a mental map of the engine code. It's simply not even possible for them to reason about what in the engine could be going wrong because they don't even know what the engine is actually doing.
[1] Another metaphor that is grossly mis-invoked, in my view. Do you think Isaac Newton did not understand the work of those that came before him? The great thing about giants is that by doing the hard work of exploring new concepts, they make it easier for everyone who comes after them to learn them. I think it's a bit intellectually lazy to put off the work of giants as something that should not, or even can not, be learned.
[2] "like J.R.R. Tolkien wrote books, and there's a reason nobody writes books the way he wrote his." It's a real shame more people don't, considering there has never been a fantasy work rivalling his in the nearly century since.
It sounds like you're talking about making an equivalent of Super Mario from the 80s, but modern games are in fact much more complex.
And no, just because people in the 80s enjoyed Super Mario doesn't mean it's the pinnacle of game design, and that there's no need to create anything more complex.
> It took less than a month of work for me to get a polished cross-platform system working on five platforms.
You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet. That is especially true regarding consoles with their custom hardware and mobile devices with their abundance of cheap, often not well engineered hardware and sketchy drivers.
"Modern games" span a wide range of things. I develop solely 2D games, because I prefer 2D games over 3D games. I think that even today 2D games are more enjoyable than 3D games. That doesn't mean Super Mario Bros. That can mean Europa Universalis IV, it can mean Stardew Valley, it can mean Magic the Gathering Online, it can mean Hollow Knight, it can mean Slay the Spire, it can mean a huge variety of interesting and engaging games, none of which require 3D graphics. 2D games can be as complex as you'd like them to be, far more complex in game logic than a 3D shooter even. The more complex you'd like them to be, the easier it gets to implement them if you understand the primitives you're implementing them with. Imagine trying to optimize your data structures when you don't even know what an int32 is? There are real game developers in the world who don't know even that much. It is a great thing that off-the-shelf game engines provide a level of accessibility to allow anyone to develop games, but they do not represent the pinnacle of what can be achieved in software engineering. They are the exact opposite of it, in fact.
> You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet.
What is your point? I profile my games and have detailed logging systems. If I or my users run into performance issues, I address them as I come across them. Understanding my codebase at a low level makes it significantly easier to dig into problems and investigate underlying root causes than anyone on Unity will ever be able to. If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level. If they haven't, and you run into that issue in your game, you are completely fucked. I love being solely responsible for the defects in my games. That means I can fix them myself. The worst thing in the world in software development is when somebody else's fuck-up becomes your problem, and you can't fix it, so you have to implement some hacky workaround, if you can even figure out why the closed-source engine code you didn't write and can't read is behaving incorrectly to work around it in the first place. Sometimes that still happens anyways -- our hardware-OS stacks are built with tens or hundreds of millions of line of dogshit code, and you can't get around it if you want to create software for platforms people use, but you can at least remove as many dependencies on bad code you have no understanding of as possible.
You're already too late at that point, and you probably lost some players, that wanted to try your game and maybe would've even liked it.
And I'm not talking about gameplay logic bugs - I'm talking about issues caused by bad drivers or by not having intimate knowledge about the hardware.
> If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level
Most major engines allow to bypass high-level abstractions either through scripts that access low-level systems (Unity) or by directly letting people modify the source code (Unreal Engine, Godot).
> I love being solely responsible for the defects in my games.
> by directly letting people modify the source code (Unreal Engine, Godot).
Unreal is not open source, and while Godot is, I would wager 90% of its users never even look at the source code. It very specifically attracts people who want an easy way to make games without prior expertise.
> Players do not care about that.
Users don't care about much when it comes to software quality, honestly. They accept 20 FPS, slow loading, bug-riddled games that consume +20gb ram and +100gb more disk space than necessary. They may complain about a game if it gets bad enough, but they still buy and play those games. My games are significantly more optimized than most. They aren't perfect, but they don't need to be. They don't even need to be as optimized as I have made them, it's mostly just a point of pride and making the kind of software I want to see in the world. I think the only way you lose a player on technical points is if they literally cannot boot your game, but those issues plague engine games too. I had driver issues myself crashing on boot with an UE5 game two weeks ago.
>Note that our vehicles do not run on stone wheels. Thank goodness we kept re-inventing wheels that were more suitable for our specific use cases!
Improving a wheel design does not require reinventing it. The people who designed the car wheel were able to look at previous designs of wheels instead of needing to invent the wheel themselves.
So too with game engine design, where you have dozens of designs and hundreds of tutorials to learn from in the building of your own. It is seriously funny that no matter how you try to contort the metaphor, it continues to fit perfectly in a way that indicates it is not actually a bad thing.
Romanizations are fashion trends rather than any kind of science or real standardized system. Other than those places with Roman-era Latin spellings like Syria, others have dozens of variants.
Identity is "infrastructure" government should provide via something like mDLS. A lot of work needs to go into make sure it is secure and it can be used in a way that protects privacy. Eg selective disclosure of attributes for verifying age. Pairwise pseudonyms for identity when your online identity doesn't need to be tied to you real identity, which is most of the time. Something like that would go far in dealing with sybil issues in decentralized systems, which is often the source of a lot of headaches for system designers.
They maintained census, but for government functions (like accounting and taxes), and actual identity communication almost never involved government.
Passports use for anything except international travel is a very modern thing as well.
For most of the history the source of identify was individual themselves (as it should be), that is, one told their name and origin and others accepted that, unless someone knew otherwise.
We've seen ~20 years of people trying to solve identity without the government. We've seen plenty of solutions that can provide stable identities over time, but we haven't really seen anything that provides meaningful sybil resistance. As computer systems become more and more "autonomous", sybil resistance is increasingly the most important feature of any identity system. Any identity system that doesn't solve that problem pushes to the application layer, where it usually has UX impacts that have serious tradeoffs with adoption.
I understand this. I also understand that if history teaches us anything it’s that any centralized governance (of any nature, not just traditional national and regional governments, but any centrally organized communities, like corporations) is to be constantly distrusted and kept in check, and even then it’s dangerous to let it take over social functions. That’s why I wrote “only as a last resort”, that is, unless and until someone thinks of something better. (And then switching over is another issue… that may need some pre-planning even better new solution exists.)
Or maybe someday we’ll have some interesting revelations about personal identity and sybil resistance won’t be necessary. But that’ll probably be only some centuries later.
To be clear, all we need from the government is to establish a person really exists and verify basic properties. We don't need more than that, so we can and should use all cryptography at our disposal (and invent more) to prevent any more information disclosure to both services and government.
I get that identity is a sort of last holdout for the tech libertarians of old. But after years working in KYC, what I saw was the accumulation of vast amounts of sensitive information held by private actors in a way that was completely democratically unaccountable and couldn't be corrected by the average citizen. It's time to bring identity out of the shadows and make it ours to control.
For establishing facts about person, the problem is, hostile governments are not unknown to revoke passports and cause all sorts of trouble. And if the government is benign that doesn’t mean it never turns hostile. We really don’t want to allow governments to disappear people, not physically, nor digitally.
I’m not a libertarian (was; realized why it doesn’t work in reality we have), but I still believe that no entity ever should be able to deny one’s identity, they can only refuse to attest it.
And the more serious problem is that nowadays we’re collectively so much into that flawed paradigm of “identity providers”[1] I’m afraid if a government-ran system happens it’ll would be still built in the same paradigm and engrave that into collective consciousness even further.
Private corporate-ran identities are IMHO better for the foreseeable interim, until we know for sure how to do things right. Because I suspect that whatever we pick as fundamental ideas is going to stick and bless or curse us for a long while. Nation states have longer lifespans than Internet companies popularity, so as weird as that may sound I’d prefer Gmail to, say, that Estonian X.509 scheme (no offense meant; and I’m only considering use outside of government services), despite latter being short-term better.
And - yes - I 100% agree that it’s past the time we should be using proper cryptography for attestation of all sorts, rather than sending passport photos and live selfies to increasingly more and more private companies. But that shouldn’t be general identity verification, it should be only for compliance, only when a law forces to obtain some information from some government-issued credentials. This part desperately needs moderation. But for the love of what’s still sane - unless we find ourselves with an unavoidable need and no other choice, let’s not use that for any other purposes, for now, please?
___
[1]: My view and understanding is that identity cannot be “provided” - those words simply don’t make sense together. Unless if we’re talking about impersonation and skip the “credentials” for brevity, and then it’s not our identity but someone else’s (even if created specially for us). Of course, I could be wrong.
The neat thing is that if government provides identity, you don't have to use it for any system you build. But I'm curious how you would deal with spam and Sybils?
That’s not generally true, even if it may sound true in some specific location and time. Governments trying to mandate national authentication services is a very real thing.
As for your question: sadly, I don’t have a solution for either. I wish I would. I think ML-based approaches seem to show good promise for spam detection, though? I haven’t looked under the hood any recently, but purely anecdotally, almost every time I upgrade my mail system and antispam has something new ML-based, I’m getting a lot less junk. As for the sybils… I don’t think it’s an issue per se - an ability to have alter egos is not a clear negative. And then it must depends on the exact context. Government elections is one thing, online content popularity measurement is entirely different. Not sure it’s meaningful to envision any universal solutions - they tend to have too many side effects, and usually of undesirable nature.
You can use a custom domain that you own with gmail. But of course domains aren't that great either as they are only somewhat decentralized and it's still pretty easy to lose your domain.
> And the safest way to do identity is to have it be destructable and remakable on the fly.
It might be the safest, but it defeats lot of the purpose of identity. There is a reason it is a hassle to change your email address... so many services are tied to that identity. You can change it, but you have to change every service that is relying on it as your identity, and you still have to own your old email so you can prove to the service that you are the same person.
I am not sure how you could ever avoid this problem? The purpose of an identity is to be able to tell that one request is made by the same person who made a previous request... persistence is a requirement.
The underlying problem to both protocols and non-protocols is identity. Gmail works because Google owns the identity and acts effectively as a proof of humanity.
To go on a tangent - I think that more people having personal public key pairs (via crypto) than ever is actually a positive direction. Atprotocol is another big player in identity at the moment, just as long as "can't be evil" mechanisms are kept alive and have good UX.
Atproto identity is going in the right direction but I hope they go in that direction harder. For example plc.directory (maps DID to public keys I think?) is heavily centralizing force.
My company would never let me expose my calendar data to Slack. That's why they like M365, all the integration is there with less risk of oversharing data.
Although I love most of her fantasy works, I found 'The Dispossessed' to be too difficult for me. However, that's probably because her interests were broader than mine.
Thanks, but watching an eighteen-hour seminar on a book so that I can enjoy that book doesn't seem worth it to me. (Note that "to me"; I'm quite open to being a literary lightweight. My experience of AP English in high school was that it inoculated me against the great works of literature.)
As a person actively organizing with anarchists and who has had a lot of long, fraught relationships leading to my late 40s, I found the Dispossessed to be relatable is ways I wouldn't have if I'd read it earlier in life.
I don't know if it's a difficult book, but I can see how it might land differently for me in different situations.
What percentage of the population would you like to see made up of immigrants? Would you make immigration harder if the immigrant populating was above 1%?
If it got too high, would you start deporting people or forcing native people to have more children?
You want the number to be small enough where the cultural and social impact of immigrants is controlled. We don't want America to become more like India or Bangladesh or places like that, so we need to keep immigration low enough where the native culture overwhelms that of the immigrants.
According to a 2021 Cato survey--which is a pro-immigration outfit--the median response to "how many immigrants should be allowed each year" was 500,000: https://www.cato.org/sites/cato.org/files/styles/aside_3x/pu.... If we enforced that number long term, we'd probably end up with a foreign-born population under 5%, as we had in 1970. That seems like an appropriate number to foster cultural homogeneity and a high level of social cohesion.
The repeating pattern has 2 digits, and is a multiple of 9. 9 times 11 is 99, so that multiplication gives a "repeating pattern of a multiple of 99" — equivalently, a multiple of a repeating pattern of 99. And I assume you're familiar with the concept of .99999... equaling 1.
> Payments are handled by Solana smart contracts, with a React frontend (TanStack Start).
This is disappointing.
Solana has a highly centralized validator set that will keep shrinking over time as the cost to run one out paces the rise in the SOL price.
This leads to it being very centralized.
Solana is also missing core cryptographic primitives like state receipts, meaning I can be easily tricked by a dishonest validator about whether my transaction happened.
Without a mempool, sending transactions is a nightmare during high network usage and my transaction can dissappear forever, or be executed multiple times.
Solana isn't even significantly cheaper than the alternatives anymore.
Yeah that's true and the plan is to expand to multiple chains once the platform has users and we are happy with the stability of the system.
Our current system will allow us to expand to Ethereum easily which will open up a much larger network. We just wanted to keep things simple for our initial product and you have to admit that Solana is a good chain to build on.
You can write a lot of code when using Godot and mix that with capabilities provided by their editor.
You never have to use editor features, but can use them to avoid wasting time reinventing the wheel.
Your comment is like saying that game engines are used by people who don't care for programming and would rather make a call to handle physics interactions.
reply