Doom, yes.

Crysis?

maybe

That is a neat story, thanks for sharing!

Best I’ve got doesn’t have to do with Godot, but I think its neat.

The year is 2003 or 4, and I am beta testing the 0.5 release of Project Reality, which later more or less evolved into Squad.

I know nothing about coding at this point being still in middle school.

What I do possess is apparently pattern recognition.

We are in a last minute waaay overextended beta testing session trying to iron out a mystifying bug:

The whole new feature of implementing squad specific kit bags that are only obtainable at certain in game locations is working.

But… sometimes it is not. At all. Sometimes you can grab an unlimited number of kits without restriction, sometimes you cant and have to follow the newly coded rules that limit kits by being in a squad, and having a total pool of requestable kits per squad and per your whole team.

We get in vehicles, we get out of vehicles.

We go to different parts of the map.

We die then respawn via suiciding.

We die then respawn via being shot, killed as infantry with different weapons, killed inside different vehicles.

We join and leave amd create and disband squads.

We die on the water, we die on the land.

We die on islands, we die on beaches.

We shall never surrender!

Er, well the goof off testers wont, the devs are getting frustrated.

Absolutely none of this has any discernable effect on the problem.

After what must have been about 3 hours… we are basically just fucking about as testers as the actual devs including the one who actually coded the new system is in despair, we are gonna have to push back the massively advertised release date of about 8 hours from now.

Fucking about a bit and watching random zany attempts at most impressive suicides with those who we are at this point joking are just the chosen ones able to spawn unlimited specialist kits with c4 and anti tank weapons…

Something clicks.

I hold down the tab button to bring up the scoreboard with player names.

I start telling a few of the testers who have not already left to try spawning kits at various locations.

Everyone goes sure man why not.

After doing this with myself and 5 other people… I have a theory.

Everyone who has non alphanumeric characters in their name is able to break the kit limitation rules, everyone else is bound by them.

The lead dev is skeptical, but checks the code again anyway.

About a minute later he screams over the mic on teamspeak.

About 10 minutes later, he has fixed what was probably a really simple but easily overlooked bug in how early python parses string values and passes them to other functions or data types.

The server is back up, everything works correctly now, and Project Reality 0.5 is released only a few hours behind schedule, instead of the next week or two when the team would be able to organize another large scale testing bout.

Lol and thats the story of how i saved a mod release date wooo!

Ding ding ding, winner winner chicken dinner.

Sure if you are a bigger entity and have more money to throw around, there are other engines that’ll probably be a much better fit.

If youre a broke ass indie dev, I am not really seeing a better choice than Godot right now, as youre not gonna be able to afford a more expensive engine without /usually/ pulling some kind of asset flip scam type thing.

Sure there are some very good more niche 2D only development engines, but even with a lot of them youve still got some kind of liscensing to deal with.

That basically leaves Unity and … OGRE, as far as I am aware for possibly good choices for a 3D game.

Unity is currently self destructing, and OGRE, at least as far as I have tried, is pretty hard to get a native dev environment working on linux. Maybe I missed something or got confused, but I kept running into error after error trying to set up its more advanced features, which seem to require windows specific dependencies.

I guess you could run it in a VM but that seems basically insane, and even if I was to set up a dedicated Windows machine just to develop on OGRE, it is far more clumsy to work with than Godot.

Whew, wont lie, I am getting tired and I had to reread that a few times till it clicked.

SystemD… and Linux gaming.

I am far from an expert on systemd and its alternatives, but so far all what I at least think I know is:

SystemD is not as efficient as other paradigms could be,

It could potentially be a massive security vulnerability, or maybe not, or maybe so, or no one seems to agree on this and then everyone starts yelling,

I am reasonably confident that at least currently there are not any existing alternatives to SystemD that allow one to play much less develop basically somewhere between any to most games that involve 3d graphics.

Again, I could be completely wrong about all of this, absolutely beyond my experience and skill set to comment much more than:

A systemd alternative that would allow for modern kinds of multiplayer 3d online games would be really neat, but it seems like it would take a massive amount of effort that is at least nearly certainly beyond my ability to contribute to in any meaningful way.

You conveniently left out the qualifier of my statement.

That I have ever known.

Probably unlike the field of electrical engineering, every /single/ person I have known in my life has relied on me to provide free expertise in software related issues of all possible kinds, and also simultaneously mocked my expertise and ability any time I suggest they do something or use something that will actually work, but they do not think it will because -insert utterly nonsensical concern about issue they do not even know how to use basic vocabulary to describe-.

This is apparently a rather unique phenomenon that happens to those who are programmers and know software.

Software and programming is in every modern computerized device, but an astounding amount of people who use such devices both realize they are not experts and will seek the help of a software expert for assistance, but will also feel as if they are better able to solve a problem when -literally any random thing they do not like for any random reason is different in any other way-.

If you attempt to explain anything to these people at this point it does not matter if you are correct, they will be angry and abuse you quite often.

I do not hate the tech illiterate people I have known because they are ignorant.

I hate them because they are abusive.

Finally, when it comes to the kind of game I want to make?

I want to make something I would enjoy playing.

And I have found that I enjoy games that offer a mix of skill based challenge in the sense of being able to quickly execute exact commands to the controller rapidly and with precision, but also with a larger sense of strategy, and also with multiple possible ways to solve a problem, some that are obvious, and some that are non obvious and encourage thinking outside the box.

And I have also found that every technically incompetent person I have known is utterly incapable of enjoying this kind of gameplay.

And that is fine. As I said, I want to make a game for myself and people with similar game preferences, and mental capacities.

I have been surrounded by abusive morons my whole life and I have no interest in making a game that appeals to such people.

Yep, I started my own game dev journey a year ago after a decade in the tech industry.

My gamer friends: Use Unity Bro its so easy to learn!

Hrm but uh what about cost structure, licensing, all that kind of stuff?

Doesnt matter bro, you can just port it all if it doesnt work!

Well uh, porting is actually a lot of work and burnout is a serious concern so wouldnt it make more sense to-

Youre making this too complicated, what you need to do first is-

…

And that conversation was obviously useless.

Anyway yeah, I picked Godot after doing, you know actual research on all the benefits and limitations of various engines.

See, Godot, being open source, and myself, not having a huge amount of money to throw at this, and also not just knowing any reasonable or reliable people that could contribute… I can afford to work with Godot at a comfortable pace and not be driven insane by budgetary concerns and a timetable, and Godot is likely to only improve, and I can improve with it, expand the scope or add new features as they become better supported by engine updates or freely usable nifty tools and techniques proliferate.

Also at this point I am planning on really only supporting linux users, as I am again looking to do this as a hobbyist that isnt really concerned about making a ton of money, and also at this point I just literally despise every technically incompetent person non FOSS user I have ever known, so Godot suits that well.

Oh and linux gaming marketshare is growing rather rapidly.

Yep, but the best part is because their core demographic is moronic, know-nothing-about-how-any-technology actually works, start-up indie game devs with basically only a dream and prayers combined with ‘i have played some video games, it cant be /that hard/ to make one!’ kinds of people…

…you can expect discussion around everything going on with Unity to be filled with irrelevant and infuriating opinions/beliefs/concerns that will eat up most discussions in most communities while also mocking and downplaying actually correct and actually relevant things.

It never fails to amaze and infuriate me how confidently completely wrong nearly all video game players are about literally everything about /creating/ video games.

God damnit.

The way the scale and lighting work in the latter images before you get to those sort of resembling medieval paintings… they are giant, kaiju women who are apparently thousands to tens of thousands of feet tall.

Very very strange.

This is because most anti cheats for windows are kernel level rootkits that have full access to your entire system, and gamers just trust that known to be ineffective, scammy and profiteering, anti cheat companies software companies would /never/ do anything nefarious.

How can you trust them?

You can’t! Black boxed code, babyyyyyy.

Anyway yeah on linux systems basically the designs of all common anti cheat systems would be laughed at as hilariously insecure code that no sane person would allow on their computer because you would have to give it root level access.

This is basically insane as in the linux paradigm, root level access is reserved only for a bare minimum of system processes, whereas on Windows, well with the new Pluton tech in the latest lines of major CPUs, Windows has the ability to DRM literally anything you install on it and just get rid of your ability to run or install it, as they see fit, with a network enabled sub layer of the CPU that you as a user cannot override from within Windows.

The only hurdle for linux gaming is for more gamers and game developers to realize the truth of what I just said.

Its possible to do anti cheat in less invasive ways. But that requires more work from game development studios, and is costly.

Anyone else remember when servers had like actual human admins that would respond to player complaints, and would work on the backend of a server to come up with their own ways to detect cheating server side?

I don’t know what you say, but as a debian omnivore most people don’t notice either.

You know, because the computer just works, looks a little different, kinda like a mac on top, but free, and powerful and stable under the hood.

See I value practicality and reliability, and also ease of use.

This applies to meals as well.

Sure I’ll go vegan if I can, get free range stuff when I can afford it, but I’m not made of money and infinite free time, as one would have to be to be a morally consistent vegan.

Ah, that makes much more sense.

There is no point to a small handheld device being in 4k.

2k /maybe/.

You would have to have literally super human vision to tell the difference between a 2k and 4k display the size of a phone unless you held it something like 2 or 3 inches from your face.

At which distance most people cannot focus their eyes anyway.

Sorry to double post, but … kind of a huge part of what PopOS! /is/ is making their own DE in Rust.

They originally started prototyping their idea of a DE by modifying GNOME, but … thats a bit of a story.

They still contribute to GNOME, patching compatibility issues, but they eventually realized that for their window manager and other ideas, they would not be able to convince the largely Ubuntu centric GNOME maintainers to make some critical changes and add needed support that they would need.

So they started two of their own repos to more or less install on top of mainline GNOME and patch in what they needed.

The end result is DE that I find more useful than GNOME in many ways, and PopOS! has since been seemingly largely satisfied with how this has turned out and is now just massively working on developing what will likely be the first ever DE written entirely in Rust.

Yep, thats true.

I miss the old days when someone was being annoying and you could take the rubber ball out of your mouse and bounce it off their head haha!

I forget what its called off the top of my head but there are decent debian screen recording softwares that can record a game in fullscreen that work on PopOS!

My god an actual trackball user!

Sorry I just hardly ever see any these days.

I have also found PopOS! to be a fantastic distro. Easy to setup, user friendly, has tons of software that works with it , great UI, and I have not had a main OS patch/update break anything since I think 3 years ago now.

And it also does not punish you too hard if you tinker under the hood a bit!

Only real room for improvement is the PopShop, but thats relatively easy to fix, so I do think it makes more sense for them to focus harder on general stability, compatibility, and the new Rust based DE.

You can always install synaptic or the debian software manager for deb based stuff, and a flatpak store if you get tired of the PopShop and want to stick with PopOS’s deb/flatpak paradigm.

#2 and #4

Disney VP gets back from a week at Vegas, upper lip oddly still slightly powdered:

“OK! Next big thing: Tron 3. Flynn’s son and Kora have lived an interesting life after Tron 2, but nobody cares, what matters is Kora’s code is degrading and they have to go back into Tron world to connect with the source and patch the code…”

“…but … in like sniff Tron world, because computer time is faster than real life time, all the programs have socially evolved sniff past the need for clothing, AND tens of thousands of generations of programs essentially interbreeding via code has led physical beauty standards to follow neoteny to the point they look like Elsa.”

“What? No its not action/suspense. It the worlds first romcom with ten million cycle old cyberbabes that appeal to 14 year olds AND are actually canonically old enough that we can have sex jokes!”

And then Mickey Mouse walks into the boardroom and shoots this man in the face.

I still prefer to run everything built directly from reliable deb sources.

As an end user… sure, flatpaks and appimages and snaps are I guess neat if you are constantly distro hopping or something, at least in theory.

But uh, I have already found the ability to play games, develop games and other software, use basic daily software for everyday needs, and have a stable and predictable OS that doesnt crash or have insane misconfigurations caused by some esoteric conflict by just basing everything directly off of deb sources.

Every once in a while I will have to compile my own build, but this is rare and usually only occurs when trying out something experimental, or, also rare, something that doesnt have an actively and well maintained deb source. In that case its just a matter of doing a build from github when a new version comes out.

And I can do builds from github because I have saved a lot of storage space from not using bundled installers for all my software, allowing me to store the sources. This is also neat because it allows me to quickly /use/ one of those sources in a project, after I have already seen that it is stable via the software I use that is built on it.

Finally there is the security angle. Using a myriad of different containerized installers for everything is convenient in that you don’t have to directly worry about source management… until you do, when a source lib is discovered to have a critical flaw.

When a serious flaw is found in a source library… what’s gonna get updated faster? A containerized installer that you have to wait for the devs, who are busy managing tons of cross platform dependency issues and have to do a new safe stable build everytime any of their many dependencies for their many supported platforms? Or an app specifically built from source libs that either doesnt focus on cross platform, or has different teams specific to maintaining its different supported flavors?

In my experience, literally all of the time, the ‘direct from source’ software gets updated more quickly than the cross platform bundled installer.

Further, this whole approach here gives you experience with software that is built on source packages that, as you become more familiar with, and tinker with yourself, gives you insight into what source libs are well coded in terms of cpu/gpu/ram optimization, and which are resource hogs and should be avoided if youre interested in promoting and using software built off of efficient code. I enjoy learning from the good coding techniques of stable, lean and fast programs, and avoiding code that is comparatively unstable, boated, or slow.