@Southkraut's banner p

Southkraut

A tale Told by an idiot, full of sound and fury, Signifying nothing.

5 followers   follows 5 users  
joined 2022 September 04 19:07:27 UTC

All alliterations are accidental.


				

User ID: 83

Southkraut

A tale Told by an idiot, full of sound and fury, Signifying nothing.

5 followers   follows 5 users   joined 2022 September 04 19:07:27 UTC

					

All alliterations are accidental.


					

User ID: 83

Neutral questions: Then what is anyone's fault? What model of responsibility do you espouse?

Here where I live, in the same damn village I grew up in, kids get to play outside unsupervised just like they used to. But good luck convincing my wife that there isn't a ruthless violent pedophile lurking behind every bush - our daughter will never be allowed to go outside without a chaperone.

Social media and anxiety disorders fuck people up.

which shall remain nameless

Why?

having kids is inherently "unsafe"

Used to be the opposite. Not having kids was how to be unsafe. Kids were your safety net.

Do you have some idea on how to achieve this? I always loved the idea, but any time I took a stab at it, I ran face first into a wall. The minimalist approach is to have the entire game world happen off-engine, and than output the results as scene objects of any particular engine. That's simple enough, but then you inevitably run into stuff that the engine already has good to go out of the box (say, collision detection, including stuff like "is the mouse pointer over an object"), that would have to be rewritten in the backend from scratch, or the whole idea of separation would have to be abandoned because in the end, you're still using the engine internals.

I swear all these engines are deliberately designed to make "engine agnostic" projects impossible, so if you come up with some elegant way to do this, I'd love to see it.

No, I'm afraid my engine-agnostic is probably your strongly-coupled. There's just a few points that I try to consistently follow to make things easier for myself in the long run (but more difficult in the short one, and performance suffers, too).

  • Don't use engine-specific data types except for when directly communicating with the engine. (The casting here is a major source of performance loss, but that's a hit one must choose to take.) Example: Use your own Custom.Vector3 class or struct instead of UnityEngine.Vector3, and only cast to UnityEngine.Vector3 when assigning a value to a transform. Maybe even be cheeky and cast implicitly, but that opens up some black pits of anti-optimization.
  • Any call of an engine function should be wrapped by a non-engine-specific method, and those wrappers should be somewhat centralized (in as few files as sensibly possible) so as to limit the points of maintenance in case of engine switching. Example: Don't call UnityEngine.Physics.Raycast(...) everywhere in your code, but instead have your own Custom.Physics.Raycast(...) that in turns calls UnityEngine.Physics.Raycast(...). Now when you switch engines, you only need to adjust your Custom.Physics class to completely migrate your raycasting capabilities instead of making changes in every single class that ever used a raycast.
  • Use as few engine features as possible. This is fairly trivial for me because I hardly even do graphics, but your mileage will vary greatly if you want more out of the engine you use.

IMO, for someone who actually wants to leverage a great breadth of a given engine's potential, it makes no sense to aim for engine-agnostic design. It's a lot of hassle and performance cost for a type of damage control that doesn't even come into play unless something goes horribly wrong - and that really shouldn't happen in the first place for a well-designed, well-scoped project. The only reason why I drone on about it is because my projects are the vague, un-designed, tele-scoping, lifelong obsessions of a hobbyist with too little concentration but too much persistence for his own good.

1st person optionally violent interactor in a very large procedurally generated world with a side dish of "large numbers of people" simulation.

Look, I have no idea what I'm making. There are a bunch of themes I'd like to do and a bunch of mechanics I'd also like to do and a bunch of simulation aspects that I'm usually doing instead of either of the former because somehow I feel at home in technical rabbit holes.

But if I could just stay strictly on course and work towards results instead of in circles, I suppose we'd end up with something like a first-person Kenshi, if that means anything to you.

Still thinking about which engine to use. Are you tired of this topic yet? I am.

I had a bit of a thought.

  1. My main objection to Stride and Godot (and by extension Redot) is that they're buggy and poorly documented and support is often unhelpful. They're decent when they work, but too often they don't and it takes too much time and energy to figure out why.
  2. My main objection to Unity is that I'm not confident in its future development. Even with the recent issues concerning the pricing model having been laid to rest, Unity suffers from the company that manages it seemingly seeing it as a vehicle for advertisement, and its main target user base being mobile developers. Not exactly what I'm doing.
  3. All this switching engines has strongly reaffirmed my commitment to a maximally strict separation of my model from the engine, as explained last week.
  4. So there's nothing really stopping me from returning to Unity so long as I strongly separate the model from the engine so that if Unity does become unusable or intolerable in the future, a switch to another engine is as easy as possible.

All of this assumes C# scripting for easy migration, of course. So Unreal is right out.

From that thought onward, I considered my existing Unity codebase. There's a lot in there, ready to use, but it follows the old design doctrine of "everything is physical first, abstract second", which is of course the opposite of what I have discovered myself wanting. So even if I do return to Unity, it will take a lot of work to reshape the old code to conform to my new view, plus hanging into into the framework I build in Godot. I should think carefully about how to approach all this so as to achieve a good result without having to redo it several times over.

All that said, I'm strongly considering going for Unreal after all. It's been a pain so far, but for all the effort required to get anything done in Unreal, I am at least confident that the it will bear fruit at some point because the Engine is doubtless capable and not possibly-actually-broken like the others are in many respects. And unlike Unity, I needn't worry about its future nearly as much. That said, my two big pain points are of course C++, but maybe I just need to live with that language and its abominable two-files-per-class structure, and the fact that I won't be able to migrate over any of my old code.

So to recap: More thinking, still no coding.

And thanks for keeping this up. It prevents me from getting distracted entirely. Not like I'm getting much done either way, but this way I'm at least forcing myself to consider the issue regularly. There's hope yet. Please don't stop pinging me.

You're not wrong overall, but FWIW there absolutely are non-woke devs. Very few are explicitly anti-woke, though, that's a very small niche. And either way, they try to keep their politics out of the public as an issue of self-preservation. The userbase being anti-woke isn't entirely true - there are elements of it, but numerically I think the vast majority of players are actually just plain not interested in politics. There is a sizable group of vocal anti-woke players, but they're a drop in a bucket compared to the many more who just want to grill game.

One problem is that even anti-woke devs need to cooperate with woke publishers, influencers, reviewers, community managers, contributors, and of course a sizable woke customer base. Very few anti-woke people who work in game development for reasons you have pointed out. It's better for devs to try and be apolitical than to risk suffering sabotage, bad or no publicity, uncooperative business partners, negative reviews and alienating a large number of potential customers. It's a woke ecosystem; you can't thrive in it by swimming against the current. And given how ridiculously oversaturated the market is, it's hard enough to make a profit without making yourself a public enemy.

As a result, non-woke games made by non-woke devs do absolutely exist. Take any game without controversy about it, and chances are it's one of them.

But who can make an anti-woke game? It might have to be someone who doesn't care about an uncooperative environment and doesn't care about making a profit, i.e., an indie hobbyist. Those games exist, but they usually don't gain much traction, visibility or longevity, because this type of dev has very limited resources with which to make an actually good game. Alternatively, a serious game development company that managed to associate itself with politically indifferent influencers, publishers etc. might decide to market a game as explicitly anti-woke...but it would still have to be a good game, else they're just shooting their cause in the foot and ruining their own future prospects on top of it. But here's the rub, for a hobbyist or a company: if they can make a good game, then why not market it to everyone instead of just the small anti-woke minority? Ultimately even anti-woke gamers are gamers first and anti-woke second, that's why they play games at all, and will play a good game over a politically appealing game.

In conclusion, game development is a woke world with very little breathing room to spare, and trying to fight an uphill battle in there just has you run out of oxygen.

Shame about the character.

Have you seen the Three and Four Musketeers movies from the seventies? If so, how does this iteration compare? And if you can speak to it, then where does the 2011 version fit in?

Please let me know if you find out something useful about this topic.

FWIW, I also eat like a combine harvester, pace a lot, don't gain weight, and my skin ages poorly.

Not sure if there is anything to it all; maybe we're just reading too much into a bunch of coincidences.

Fair enough. I don't quite agree but that's more reasonable than it sounded.

K&R, accept no substitutes.

It's logically consistent, space-efficient, orderly and readable. The others don't even come close.

As for people being naked in locker rooms, I'd be happy to see the practice die out.

Then how the fuck are you supposed to change out of your wet/sweaty/dirty clothes?

This. Discord is their domain.

I thought that was the general consensus.

It is. I posted late at night and was tired and got dumb and messed up my Englisch to the point of stating the opposite of what I intended. Contend, contest, contradict...Nach Müd kommt Blöd.

Lots of time wasted on engine switching and reconsideration. Better focus more on disassociation from engine even at cost to performance. Said this before, but optimization always draws me towards tighter integration - need to not do that. A cleaner separation with minimal engine specificity (is that a word?). Don't let the siren song of premature optimization lure me from the good path.

Is there a way to do C++ without header files? I realize it's incredibly petty, but having two files per class just keeps turning me off of Unreal.

Other than that, I keep comparing engines.

Unity:

  • C# as a scripting language.
  • Single-precision coordinate system only.
  • Messy development, priorities of the Unity company are unclear, future is uncertain.
  • Documentation is pretty decent.
  • Has a live scene editor.
  • Many features are semi-maintained only and better not used.

Unreal:

  • C++ as scripting language. Big meh. I just don't find it fun to work with.
  • Overengineered editor and blueprint system keeps getting in the way.
  • Huge file size and memory footprint.
  • Amazing features; would anyone contend that this is the most powerful engine?
  • Double-precision coordinates out of the box.
  • Documentation is OK, but surprisingly thin on many features. Seems to live mostly in youtube videos.

Godot:

  • Does support C# scripting AND double-precision coordinates...but good luck getting that to compile, nevermind getting support for it when it bugs out.
  • Engine
  • Documentation is OK.
  • Community is very actively woke.
  • Has a bunch of bugs.
  • Amazingly small file size and resource consumption.
  • No live editor.

Redot:

  • Like Godot, minus the politics but I'm not sure how long it'll live.

Stride:

  • Engine written in C#, open source, and scripting is in C#. C# versions are up to date. It's a dream come true.
  • No live editor.
  • No double-precision coordinates.
  • Very buggy.
  • The documentation is completely worthless.
  • The community is agreeable but doesn't have the manpower and/or time to bring the engine up to scratch.
  • Even if I don't use the engine itself I can cannibalize many utility classes of theirs and even learn a thing or two about efficient C#!

No idea where I'm going with this. Right now I'm trying to fiddle some dev time into my new routines. Not yet sure how to. Maybe I'll just get used to the job and end up being less weary by the end of the workday so I can get something done in the evenings, or maybe I'll follow a friend's recommendation and just get up even earlier to do some coding in the mornings. Or maybe I'll find a way to take a few short breaks (legitimate breaks, not slacking off.) during work to...I don't know, dictate code to my phone?

which I remember @Southkraut taking great offense at for reasons that still strike me as insufficiently thought through

They are. The thought terminates at "Rightful German clay must remain in German hands."

And then he was replaced by a lesbian, and many an article was written about it.

Surprised I never heard of this on the Motte.

Sorry for being unavailable, by the way. My excuses are kid's joining Kindergarten and I started at a new time-consuming job.

What even is the message?

Redot

I'm happy to hear it. If they can make it so that compiling for double-precision AND C# actually works, then they're winners in my book. I'll check it out once I've established a new weekly routine that makes some suitable time for sitting down and tinkering.

@Southkraut, you mentioned you probably wouldn't have time over the past week, but I'll traditionally ask how are you doing anyway.

Thanks for asking, and please do keep it up, even though it's a bit of a drought right now. I did not get around to anything at all - I was always at work, or making up for my absence by going full hog on dad duty, or just plain tuckered out.

Can you elaborate on this. I think I know what you mean, but I don't know what consequences, if any, it would have on picking an Engine, for example.

It wouldn't. It's not related to the engine question. It's rather a change in how I approach my cluster of projects, and a change that snuck up on me and I only recognized it long after it happened. Let me illustrate the comparison a little.

Old: There are many Physical Entities. All these entities have complex physical properties and interactions. All these entities are always rendered and physically simulated. Some of those entities may contain so-called Functional Structures. Some of those Functional Structures might support Behaviors. Some of those might be Agents, who actually act upon the game world. All their actions and interactions go through the physical properties of their Physical Entities.

New: There are many agents. All these agents have goals and sets of possible actions. Some of those agents have physical bodies. But the actions and interactions of the agents only account for their physical bodies in the broadest sense, i.e., usually just location. Those physical bodies that are very close to the player's location are actually rendered and physically simulated, but the abstract behavior of the agents has priority over the physics simulation, and they can interact with non-rendered, non-physically-simulated agents just fine.

Also, congrats on the new job! I recall you posted about being burned out with the old one a while back. I've been in a similar position not long ago, so I'm glad to hear you took matters into your own hands, and hope the new job is a better fit.

I didn't really take the initiative on this until the last job really started falling apart, but it's still a sound improvement overall. Better salary, conditions, benefits, location, and most importantly I get along with my new colleagues very well, which was sadly not really the case in the old job. That last point is very important to me; I'm much more motivated when people I actually like depend on me. I'm also on premises all the time, which helps a lot with actually focusing on the job - no more distractions on the home front. The work itself is extremely dry and technically uninteresting, but I suppose you can't have it all. I'm honestly surprising myself with how easily I manage to adapt to the new working conditions after four years of practically pure home office, and how much energy I can muster for work after so much time spent just dragging myself along in a job I hated. It's nice. Exhausing, too, but I'm happier than I've been in a long time.

How did your similar situation turn out?

I'm strongly considering going back to Unity or Godot. Stride is a documentation disaster that obscures whatever technological disaster may be going on below. I suppose there's a reason why Distant Worlds 2 is the only halfway well-known game to have been made with Stride, and it's a strange example because it's both based on a unique fork of the Engine and, frankly, technologically the opposite of impressive. Stride is halfway between a community project kept alive by plucky contributors and straight-up abandonware. It's a post-apocalyptic vision of a Game Engine, where the original creators are no longer around and the people who maintain it now have only very limited insight into how it all works. It's a hard sell when there are alternatives that actually work out of the box.

That said, an open-source Engine that's built from the ground up to consist of and support the latest C# is a pretty great pitch to my ears. Amazing in concept. Sadly it increasingly looks like I can't live with the implementation.

I've drawn up a spreadsheet comparing the various engines. Their strengths, their weaknesses, my personal problems with them. Color-coded it, too. It didn't help. Everything is distinctly lacking in one way or another. Trade-offs will have to be made.

Looking back upon my Unity project and comparing it to my current Godot/Stride iterations, I am struck by one fundamental difference that wasn't even intentional. My old project is primarily a physics simulation, and whatever abstract logic or behavior happens is a consequence of physical entities interacting. In the new version, everything is abstract entities that possibly project into the physical realm. Huh. I'll need to do some more thinking about this.

Anyways, I just started on a new full-time day job this week and haven't gotten anything done since the weekend, and probably won't see much progress tomorrow either. Maybe on the weekend.

But if one of the issues is giving too much power to people who can't properly wield it--and it has a gender bias--what on earth do we do?

Punish people who scream at babies, regardless of their sex.

"Last enemy wasn't so bad now that we have current enemy" seems like a pattern on both sides.

Leaving, but turning around long before they get there. It will be an in-joke, and we get to make fun of the idiots who actually fly to Alaska.