I suppose hardware folks could cook up some kind of RAID 5 style striped RAM layout and utilize a hedging strategy. Write out parity, drop a late parity read instead of using it for error correction. You get better results than double the RAM needed with a striping strategy.

I guess this would have been a nice way to reduce HDD latency as a new RAID mode... oh well.

Seems fine I guess. I'm not a fan of Perforce but it does have some features that git still struggles with and needs to address to break into new customers. This Gitbutler seems to address some of them but I can't say it really feels next gen.

I like the idea of parallel branches. I feel like you could probably get away with just creating multiple, named stages but having a full history is nice. P4 has multiple pending CLs and it works nicely enough. This sounds a bit better so that's cool.

As far as "social coding" git's design is really at odds with any sort of real time communication. I would love to see a first class support for file locking, and file status work flows. It's not big at all in code dev because code can be merged but for non-coders, source controlled assets are often not mergeable. To solve this, P4 is often used with heavily integrated tools that provide live file status (Locked, out of date, edited by others). This way merge conflicts are prevented at author time. Git is really lacking here. Is fetching constantly really the best we can do?

Then of course... can we get some large file and partial checkout workflows that don't feel good?

Could you explain parallel branches vs what git offers today?

If it's to enable multi-agent scenarios, don't worktrees (at least in the local sense) allow for this?

My understanding is parallel branches allow multiple changelists to be applied to a single workspace. eg you can have multiple WIP fix branches active in your feature branch workspace and not worry about polluting your feature branch with unrelated/duplicated commits.

Worktrees are multiple workspaces, each in their own directory, sharing a single git repo. This is helpful because you reduce the overhead and the CLI command juggling for fully separate clones.

I have no idea what approach is better for your multi-agent scenario.

What a strange take. Self publishing stores and cheap capable engines make things less accessible? I think you're saying this is because its hard to stand out with game design?

But then AI will help good game design stand out? Wouldn't it make such a problem much much worse?

This isn't complicated.

We're reading a post about engineering. Why? Why aren't we reading posts about game design? Why does engineering even matter for games?

The status quo is, if you are good at engineering, you can ship games, even if they're bad.

If you're good at game design and bad at engineering, before Claude code, you will not ship any games.

So engineering mattered back then.

Unity is very hard to use. If you want to make a game on Steam or iOS or whatever you need to know a lot of engineering.

Okay, now you don't. Claude code can engineer for you.

Now game designers can ship games. Do C# features matter to them? No. So does it matter for shipping games anymore? No.

Will this help them make money or get distribution? Time will tell. Very different questions. It is a CERTAINTY that you don't need the developers as much anymore.

If Steam had an easy way to turn photoshop files or board games into product SKUs, it would also be a different story. It doesn't. The App Store doesn't. The Switch doesn't. Are you getting it? They are still really complex to deploy for. Unity is hard to use. We put up with engineering stories because it was meaningful. Now it's not so much anymore. Now it's, what helps GAME DESIGNERS ship games? C# features? Not anymore.

There are hundreds of sites devoted to discussing game design and literally millions of posts.

This isn't a game design forum, it's a tech forum, so the focus is on the tech part of games.

Unity is very easy to use. If you want to make a game for Steam or iOS it is almost as simple as drag-and-drop, then selecting Publish from the main menu. The difficulty in getting a game on Steam or iOS is in the administrative roadblocks thrown up by the stores themselves, not the engines. You don't need to ever deal with C# in Unity. If you have difficulty using Steam, neither programming or game design is for you.

Claude and vibe programming don't lead to shipped games. They lead to crap that nobody wants to play because they aren't games. They're just poorly performing tech demos with bad art because they can't design games. They can just copy parts of other games without understanding why they work...but based on your comments about turning board games into software games it appears that is what you actually want.

I don't know... I feel like a lot of these features do increase developer intent without breaking muscle memory. Properties are got and set like fields. Record types feel like classes with restrictions so the linter can warn you about broken assumptions. etc etc.

Others increase readability. A LINQ statement is a lot easier to parse than a long block inside a foreach.

New doesn't mean good but a lot of these are new and good.

There is a huge amount of closed source, ecommerce shops that use C#. Its popular in game dev too but TIOBE is probably attributable to the ecommerce.

If you know Java, you should give C# a try. Its a slicker Java with some good decisions that actually make it viable for a lot of things Java struggles at, like better interop with pointers and things like native UI (Maybe Loom will eventually overtake async/await for UI dev but not quite yet).

It works very well on many more use cases than it used to. .NET has followed with the Linux servers in the cloud industry reality and is very stable.

Its just a good language. Try it out.

Why wouldn't a released game grow their portfolio?

KISS is also good practice.

Solo dev also just doesn't need a lot of abstraction. You're adding a lot of noise for what sounds like zero benefit to developer and especially not the player.

Game dev is also a lot more agile than other projects. Solidifying structure is just more to rip up later unless you really know what you want to ship.

The anemic open source projects are really from the lack of good cross platform support early on. That's changed now but it missed out on a time of rapid OSS expansion that Java and other took in.

It is what it is but I wouldn't say its actually the fault of the language, especially now.

Its a great language in a very good ecosystem. Try it. Its great.

It has a bad rep because Microsoft could Microsoft as they do.