• 0 Posts
  • 345 Comments
Joined 3 years ago
cake
Cake day: July 14th, 2023

help-circle





  • I was once a fool like you :)

    Mike McShaffry’s book “Game Coding Complete” is a good guide to the practical side of using a game engine IRL to get things done.

    It’ll give you a good idea of how things should be shaped in order to be useful, and some things you can “skip ahead” to. Off-the-shelf engines have to be extremely general in order to be flexible enough to be useful to many customers, so game devs have to put in the effort to make them more specific. You’ll have to start off by being specific, if you have any chance of actually finishing something.

    Eberly’s book “3D Game Engine Architecture” deals with the nuts and bolts, the rigorous academic engineering stuff. It’s pretty solid, but it’s aimed at making a general-purpose engine, which is beyond the scope of a one-person project.

    Backing up though… You don’t have any language or library opinions? You might need 5-10 years of experience doing general programming (or game dev) before you can sustainably tackle this, or else you’re likely to paint yourself into a corner.

    Edit: Probably the biggest PITA with game engine dev is testing. If you’re not already an expert in setting up test harnesses at multiple levels of detail, you’re gonna find it impossible to keep moving after a few months.

    Good luck!




  • Not to be confused with SOLID, SolidJS, or Solidity.

    It’s a neat idea. Because of the need to operate on data close to web servers and backend services for potentially long timeframes, I think we’ll need a widely-adopted CRDT solution in order for something like Solid to really take off from a technical standpoint.

    And from a business standpoint, there’s really no upside. Sure, you delegate some cost for storage, but compute tends to be the more expensive aspect, and if you’re spending more time to interact with these external data stores, it may be more expensive in the end.




  • Mostly agree.

    But I think their advice falls prey to the “only a Sith deals in absolutes” problem, when they start contrasting “concrete advice” vs “generic advice”. They are offering “generic advice” with this post, aren’t they?

    They hedge against that hypocrisy by offering some special carve-outs where generic advice is still “allowable”, but Idk. I think this post could’ve stuck to the 60% of the topic that was a slam-dunk instead of trying to take on the entire topic of design principles.

    After all, I think you could argue that when experienced designers appear to contradict design principles, it’s because they understand the underlying logic of the principles and are recontextualizing them for this specific problem. That argument prioritizes concreteness but also doesn’t paint design principles as unimportant.

    As Picasso or someone once said: first you must learn the rules, and then you must break them.



  • Make computers do stuff for what purpose?

    I joke to my family that I just name things for a living. When you take away all the incidental stuff like files and pointers and ports, that’s really all it is. “This sequence of events with these properties is called <this>, and when you ask our system what to do about it, it does this other sequence of events with these properties which we call <this other name>.”

    It’s kinda like those ancient stone tablets that are the first example of writing, and they’re just like “Ramses owes Jeremiah 5 chickens” or whatever. It’s just how we manage abstract concepts moving around our civilization. Yeah there’s math involved, but every endpoint is a human being in one way or another.