He/Him | Hu/En/some Jp | ASD | Bi | C/C++/D/C#/Java

  • 6 Posts
  • 114 Comments
Joined 6 months ago
cake
Cake day: March 16th, 2024

help-circle




  • XML has its strengths as a markdown format. My own formatted text format ETML is based on XML, as I could recycle old HTML conventions (still has stylesheet as an option), and I can store multiple text blocks in an XML file. It’s not something my main choice of human readable format SDL excels at, which itself has its own issues (I’m writing my own extensions/refinements for it by the name XDL, with hexadecimal numbers, ISO dates, etc.).







  • I’d agree, but here’s one issue with that: we live in reality, not in a post-capitalist dreamworld.

    Creativity takes up a lot of time from the individual, while a lot of us are already working two or even three jobs, all on top of art. A lot of us have to heavily compromise on a lot of things, or even give up our dreams because we don’t have the time for that. Sure, you get the occasional “legendary metal guitarist practiced so much he even went to the toilet with a guitar”, but many are so tired from their main job, they instead just give up.

    Developing game while having a full-time job feels like crunching 24/7, while only around 4 is going towards that goal, which includes work done on my smartphone at my job. Others just outright give up. This shouldn’t be the normal for up and coming artists.







  • I have talked to people about Rust gamedev (including those who left Rust for D due to gamedev), and it’s not a very good one, due to the functional aspects. Outsiders often joke about how Rust has more game engines than games.

    Zig has the header file problem. Header files were originally created to get around memory limitations of old workstations, that no longer exist. They also complicate coding, since you now often have to implement things at two places at once. However, Zig not only copied C++'s multi-inheritance, but also its header files, without understanding the actual reason why it existed in the first place.


  • Classes can be useful for abstraction. Just because they often overused doesn’t mean they’re bad.

    Without an explicit class, I would either:

    • had to reimplement them in a language without them (which looks extremely ugly and can be unsafe),
    • create an “omnistruct” that keeps track of all posssible field (only looks a bit ugly),
    • use uglier virtual functions for cases when I would need local states (doStuff(cast(void*)&localstate, values) vs localstate.doStuff(values)).

    While structured programming was a godsend to the chaos preceding it, newer programming paradigms should have been instead seen as tools rather than the next dogma. OOP got its bad name from languages that disallowed its users to develop without classes, and enterprise settings making its devs to implement things that could have been simple functions as classes, sometimes complete with factories.

    Same is with functional programming. There’s clearly a usecase for it, but isn’t a Swiss-army knife solution for all problems of programming.



  • I only had a bug once from unintended data mutation. In a GUI setting nonetheless, where state mutability is a must. The fix and tracking down the bug took 2-3 hours at max. No thanks, I’ll be staying with datastruct.nextState() rather than const nextState = prevState.nextState() (which is even harder to from the inside), or even worse, passing around global states in a function argument at an attempt of having a program state, which is essential for gaming. You know, games are famous for having interactibility, and not just about walking around in a static world (which is allegedly a thing for the few Rust games).