Very mature

Yours is a flawed, extremist view.
How impressive something is has nothing to do with whether or not its source is available. What, if they release it to the public it suddenly becomes impressive?
You can disagree with the method of distribution, but it doesn’t affect the quality of the game.

Piracy being a thing isn’t a strong argument for open sourcing everything, since the barrier of entry is higher than you may expect for non technical people, a barrier that would definitely be lower if any game was freely available and compilable by anyone. Someone will make a free, one click installer, guaranteed.

Now, can you charge for open source software? Definitely.
Will it generate significant revenue in most circumstances? No.

Open source software relies on two methods for funding:

• People’s good will, through donations
• Paid enterprise licenses and training

The former isn’t something one can stably rely on, the latter just isn’t applicable to games.
Again, that model can work for some high profile projects, but in the vast majority of cases, it won’t. Especially not for games.

One can make works of passion and still want to be compensated, that’s what artists do and games are a form of art. You clearly never had to put food on the table with the art you make.

Your vision of everything being open source is a utopia. A noble idea, for sure, but reality is much more bleak.

Just open sourcing the actual engine wouldn’t do much. At best, you’d be able to make it work on newer hardware if problems arise, or port it to other OSs. Great stuff, but not enough when it comes to improving the game, preserving multiplayer, and so on.

There’s a great amount of scaffolding on top of the base engine that any moderately sized game implements, be it through scripting or native code. That’s what I meant by the line between the engine and the game being blurry. If you want to make meaningful changes to the game, you need access to that framework portion, but releasing it would allow for easy reverse engineering of everything else. It’s a difficult balance to achieve.

I could see that being a thing, but the line between the engine and the game itself is a bit blurry in this context. Copyrighting just the assets and content would often not be enough. There will always be a good chunk of game code which isn’t strictly part of the engine but under this model should remain closed source, otherwise people could just bring their own assets.

Frankly I’d be satisfied with companies open sourcing their games after they stop supporting and/or selling them, mostly for preservation and all that. I think that would be a great middle-ground.

Ah yes, closed source, such a dealbreaker, as if 99% of the other games weren’t.

Don’t get me wrong, I have nothing against open source games, it’s just not a viable monetization strategy for most projects, and people gotta eat. There’s reason why most open source games are either passion projects or old games that have been open sourced simply as an act of kindness towards the community since they generate pretty much no revenue.

I really wanna know where you get your language info and examples from because nearly every single one you wrote in your comments is just wrong.

Program state in Rust isn’t immutable. datastruct.nextState() is not only possible, but perfectly reasonable, it’s exactly how iterators are implemented.

At least it has something to complain about, unlike Karens.

The fact that it can be used as a scripting language doesn’t mean it’s a scripting language. You could use C++ as a scripting language as well, but it would suck.
C# even supports native compilation nowadays, not just JIT, so it’s definitely not a lowly scripting language.

Anyways you’ve got options. Go may also be one of them if you want GC, I forgot to mention it.

I’ve found working with Rust and Bevy to be quite pleasant. If you’re used to working with ECS, I suggest you at least give it a go.
Rust is as functional as C++ 20 with ranges and views is, which is to say it isn’t. Not sure where you got that impression from, but while it does borrow some ideas from functional languages, it’s still very much a procedural one.

Zig doesn’t have headers, nor inheritance. Again, not sure where you got that from, but Zig is basically a modern C, so there’s no OOP anywhere, let alone multiple inheritance.

As for what to use, I think they’re both viable alternatives. I lean more towards Rust, but that’s just due to familiarity. Odin also looks like a viable option, if you don’t mind a smaller ecosystem.
If you want a garbage collected language, then I’d go for C#. Despite its historic reputation as a Windows only language, it’s been cross platform and open source for roughly a decade at this point. I find it great to work with.

Those are not mutually exclusive. I’m so tired of this nihilistic view.
Community and activism can only go so far, and since human decency is not something you can rely on, if you want things to get better you need actual laws that will protect you. The only way to have those is to actually elect people who at least have a chance to do something about it. That holds true both at the state level and federal level.

So yeah, strengthen your community, but for crying out loud vote for the right people as well.

Yes, though in this case it’s more like “go back in the closet so we don’t get deported.” I don’t like it, but I’ll forgive it if it’s necessary. Maybe it isn’t, but with so little wiggle room it’s better not to take chances…

I’m not happy about it, but it makes sense.
They’re trying to avoid polarizing issues so as to not alienate undecided voters. Either way a democratic presidency would be better for LGBTQ people than a MAGA presidency, so I’m not too upset about our issues being put on hold for a few days to achieve that. I imagine they’ll become a little more vocal about them once they’re actually in the White House, and if not we’ll still be better off regardless.

Transgender people are a minority amongst minorities, catering to them while potentially alienating so many more voters is not a wise strategy. Reasonable trans voters will already vote for Harris because they know what’s at stake.

I don’t like it, but if it means keeping fascists out of the office, I can live with it.

I get the mistake. Wouldn’t even call it one tbh, just an oversight. But when someone points it out normally one doesn’t reply with “don’t force your political views onto me” as if non male devs was some weird “woke” concept. A simple “whoops, missed that” would have been perfectly fine and everyone would’ve moved on. With that said, having followed the whole debacle I can say it could have been handled better by both sides.

The problem was more the fact that the devs viewed using anything other than ‘he’ as political, not the presence of gendered language itself. The devs themselves made a big deal about changing it. The way I see it, it’s not even about trans people. How about just women? Is including women in software developent considered political? One would hope not, but here we are…

It wasn’t just to accomodate trans people but just… anyone who isn’t male? Apparently women being software developers is a controversial concept for Andreas.

I find this to be true for every new language I try out. Since every language has a different way of doing things and gives me a new perspective, in the long run they all end up improving my programming style as a whole. I always end up integrating the best parts of each into my next project when possible.

Experience will always be more valuable than any set of rules these kind of books tout as “the way things are meant to be done”.

Oh for sure. I have nothing against getters and setters when they’re justified, but in the case of bare fields with no validation like that example it’s just annoying.
Also stuff like this just grinds my gears (oversimplified example again):

class IntegerAdder {
    private int a, b;
    public IntegerAdder(int a, int b) {
        this.a = a;
        this.b = b;
    }
    
    public int get_sum() {
        return a + b;
    }
}

Just make it a bloody function.
You may say it’s silly, but I’ve genuinely found code like this in the wild. Not that exact code snippet of course but that was the spirit.

It really depends on the context frankly. I did say it was a crappy example ;)
Try to read this snippet I stole from Clean Code and tell me if it’s readable without having to uselessly jump everywhere to understand what’s going on:

public class SetupTeardownIncluder {
  private PageData pageData;
  private boolean isSuite;
  private WikiPage testPage;
  private StringBuffer newPageContent;
  private PageCrawler pageCrawler;


  public static String render(PageData pageData) throws Exception {
    return render(pageData, false);
  }

  public static String render(PageData pageData, boolean isSuite) throws Exception {
    return new SetupTeardownIncluder(pageData).render(isSuite);
  }

  private SetupTeardownIncluder(PageData pageData) {
    this.pageData = pageData;
    testPage = pageData.getWikiPage();
    pageCrawler = testPage.getPageCrawler();
    newPageContent = new StringBuffer();
  }

  private String render(boolean isSuite) throws Exception {
     this.isSuite = isSuite;
    if (isTestPage())
      includeSetupAndTeardownPages();
    return pageData.getHtml();
  }

  private boolean isTestPage() throws Exception {
    return pageData.hasAttribute("Test");
  }

  private void includeSetupAndTeardownPages() throws Exception {
    includeSetupPages();
    includePageContent();
    includeTeardownPages();
    updatePageContent();
  }


  private void includeSetupPages() throws Exception {
    if (isSuite)
      includeSuiteSetupPage();
    includeSetupPage();
  }

  private void includeSuiteSetupPage() throws Exception {
    include(SuiteResponder.SUITE_SETUP_NAME, "-setup");
  }

  private void includeSetupPage() throws Exception {
    include("SetUp", "-setup");
  }

  private void includePageContent() throws Exception {
    newPageContent.append(pageData.getContent());
  }

  private void includeTeardownPages() throws Exception {
    includeTeardownPage();
    if (isSuite)
      includeSuiteTeardownPage();
  }

  private void includeTeardownPage() throws Exception {
    include("TearDown", "-teardown");
  }

  private void includeSuiteTeardownPage() throws Exception {
    include(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown");
  }

  private void updatePageContent() throws Exception {
    pageData.setContent(newPageContent.toString());
  }

  private void include(String pageName, String arg) throws Exception {
    WikiPage inheritedPage = findInheritedPage(pageName);
    if (inheritedPage != null) {
      String pagePathName = getPathNameForPage(inheritedPage);
      buildIncludeDirective(pagePathName, arg);
    }
  }

  private WikiPage findInheritedPage(String pageName) throws Exception {
    return PageCrawlerImpl.getInheritedPage(pageName, testPage);
  }

  private String getPathNameForPage(WikiPage page) throws Exception {
    WikiPagePath pagePath = pageCrawler.getFullPath(page);
    return PathParser.render(pagePath);
  }

  private void buildIncludeDirective(String pagePathName, String arg) {
    newPageContent
      .append("\n!include ")
      .append(arg)
      .append(" .")
      .append(pagePathName)
      .append("\n");
  }
}

That’s what I was talking about.

Yeah that was essentially what I was referring to (referring to your edit).

I generally dislike stuff like (crappy example incoming):

void do_stuff(int count, bool cond) {
	function1(count);
	function2(b);
	function3();
}

void function1(int count) {
	for (var i = 0; i < count; i++) {
		...
	}
}

void function2(bool cond) {
	if (cond) { ... }
	else { ... }
}

void function3() {
	...
}

I’m not a fan of this kind of code fragmentation.
If all those actions were related and it could have been just one thing, retaining a lot more context, then it should be one function imo.
If by not splitting it it became massive with various disconnected code blocks, sure, but otherwise I’d much prefer being able to read everything together.

If splitting the functions required producing side effects to maintain the same functionality, then that’s even worse.

Also (taking go as an inspiration), I (personally) find this very hard to read

Agreed. Go’s implementation of errors as values is extremely noisy and error prone. I’m not a fan of it either.

You can always ignore an error return value and pretend that the “actual” value you got is correct.

Then that’s a language design / api design issue. You should make it so you cannot get the value unless you handle the error.
I’m of the opinion that errors should be handled “as soon as possible”. That doesn’t necessarily mean immediately below the function call the error originates from, it may very well be further up the call chain. The issue with exceptions is that they make it difficult to know whether or not a function can fail without knowing its implementation, and encourage writing code that spontaneously fails because someone somewhere forgot that something should be handled.

The best implementation of errors as values I’ve seen is Rust’s Result type, which paired with the ? operator can achieve a similar flow to exceptions (when you don’t particularly care where exactly an error as occurred and just want to model the happy path) while clearly signposting all fallible function calls. So taking your example:

try {
  res = try_something()
  res2 = try_something_else(res)
  res3 = try_yet_something_else(res2)
  return res3
} catch (e) {
  // check which error it is and handle it appropriately
  throw_own_exception()
}

It would become:

fn do_the_thing() -> Result<TheValue, TheError> {
	res = try_something()?;
	res2 = try_something_else(res);
	res3 = try_yet_something_else(res2)?;
}

match do_the_thing() {
	Ok(value) => { /*Do whatever*/ }
	Err(error) => { /*handle the error*/ }
}

The difference is that you know that try_something and try_yet_something_else may fail, while try_something_else cannot, and you’re able to handle those errors further up if you wish.
You could do so with exceptions as well, but it wasn’t clear.

The same clarity argument can be made for null as well. An Option type is much more preferable because it forces you to handle the case in which you are handed nothing. If a function can operate with nothing, then you can clearly signpost it with an Option<T>, as opposed to just T if a value is mandatory.

Exceptions are also a lot more computationally expensive. The compiler needs to generate landing pads and a bunch of other stuff, which not only bloat your binaries but also prevent several optimizations. C# notoriously cannot inline functions containing throws for example, and utility methods must be created to mitigate the performance impact.