Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

Current design decisions for my game engine:

Uncategorized
85 1 0
  • I'm wondering how to handle relations between classes / tables. E.g. Actors have an inventory of Items. I know how to represent this on the DB, but on the C++ side I need to replace the foreign keys and utility tables for many-to-many relations with arrays of handles / pointers etc. But how much do I want to load into memory? Loading an actor shouldn't always load all items in their inventory and everything those items have relations to, not until actually needed.

    So I guess I'll use getter methods which query the DB on the first time, and later just directly return the already loaded data. The database will not change during runtime of the game so it seems reasonable.

    But it WILL change when using the editor... hmm...

    Wondering if it'd be reasonable to skip the C++ class instances entirely and query the DB every time any data gets accessed using helper functions 🤔

  • So I guess I'll use getter methods which query the DB on the first time, and later just directly return the already loaded data. The database will not change during runtime of the game so it seems reasonable.

    But it WILL change when using the editor... hmm...

    Wondering if it'd be reasonable to skip the C++ class instances entirely and query the DB every time any data gets accessed using helper functions 🤔

    Whatever approach I end up using I think it's gonna involve a lot of magic code generation to make it palatable. Adding new resource types must be a breeze and not involve 15 different boilerplate steps

  • Whatever approach I end up using I think it's gonna involve a lot of magic code generation to make it palatable. Adding new resource types must be a breeze and not involve 15 different boilerplate steps

    Ok scratch that last idea about always querying the DB, it'd be way too slow.

    Now thinking about the almost opposite idea: When the app starts, load _everything_ into memory. Not assets of course, but all the plain data like stats and positions of nodes and such which is nothing in comparison to a few 4k textures. I think that's how Skyrim works actually.

  • Ok scratch that last idea about always querying the DB, it'd be way too slow.

    Now thinking about the almost opposite idea: When the app starts, load _everything_ into memory. Not assets of course, but all the plain data like stats and positions of nodes and such which is nothing in comparison to a few 4k textures. I think that's how Skyrim works actually.

    Ok this might actually be going somewhere :) Just had to overcome the mental hurdle of thinking the database schema needs to be generateable from source code / at compile time. Instead of annotations (which aren't as powerful as I hoped) I just explicitely register classes and properties during initialization, similar to how Godot does it, and from that I can generate the schema at startup. I guess I would have needed to do something like that anyway for editor and scripting language interop.

  • Ok this might actually be going somewhere :) Just had to overcome the mental hurdle of thinking the database schema needs to be generateable from source code / at compile time. Instead of annotations (which aren't as powerful as I hoped) I just explicitely register classes and properties during initialization, similar to how Godot does it, and from that I can generate the schema at startup. I guess I would have needed to do something like that anyway for editor and scripting language interop.

    I want to emphasize that is a wonderful gift to humanity. Not only is it a highly competent leightweight 2D and 3D engine, with it being open source you can inspect, learn from, and get inspired by its code. It's easier than ever to roll your own hobby engine since when in doubt you can just check how this production ready engine does things.

    Godot's architecture seems quite sound and well organized from what I can tell so it sets a good example.

  • Oblomovundefined Oblomov shared this topic on

Gli ultimi otto messaggi ricevuti dalla Federazione
Post suggeriti
  • 0 Votes
    1 Posts
    0 Views
    Tutti gli psicodrammi in Apple sull’AiL'articolo proviene da #StartMag e viene ricondiviso sulla comunità Lemmy @informaticaPresa in contropiede da Trump, che l'ha costretta a indirizzare 500 miliardi in piani di sviluppo negli Usa, Apple continua a essere in difficoltà sul fronte Ai. Siri, dopo tanti rinvii, non può certo più mancare il debutto del prossimo
  • 0 Votes
    1 Posts
    0 Views
    Europol has asked governments to work together on measures to prevent caller ID spoofing.International traceback mechanisms are needed to track down and identify the origin of spoofed calls.https://www.europol.europa.eu/media-press/newsroom/news/fake-number-real-damage-europol-urges-action-against-caller-id-spoofing
  • 0 Votes
    1 Posts
    0 Views
    Trump s’intesta la fine di un’altra guerra: la console warL'articolo proviene da #StartMag e viene ricondiviso sulla comunità Lemmy @informaticaPer molti osservatori Microsoft sarebbe pronta a ritirarsi dal mercato dei videogiochi come produttrice di piattaforme Xbox e la decisione di rendere la sua esclusiva di punta, Halo, disponibile anche sulla rivale di
  • 0 Votes
    1 Posts
    0 Views
    Building a Hydraulic Gear Pump Isn’t So EasyThe gear pump prototype in action. (Credit: Artisan Makes, YouTube)Hydraulic gear pumps are deceptively simple: just two gears rotating together, forcing the hydraulic oil from one side to the other where the teeth don’t meet, and thus providing the ability to pressurize said oil to make hydraulic cylinders, final drives, etc. do their thing. As with most machining projects like this, the devil is absolutely in the details, particularly in the tolerances. This is the crash course that the [Artisan Makes] channel on YouTube is currently going through.In this part one of a series on a DIY gear pump, scrap aluminium is used for the housing, along with 1045 medium carbon steel for the gears and W1A high carbon steel for bearings and other wear surfaces. Since at least one of the gears needs to be driven, a lip seal rated for 10 bar is used to provide a path for the shaft. As noted in the video, this is supposed to be a learning experience, ergo it’s a simplified design that merely targets being functional as a gear pump.With the basic design figured out, the parts were created on the lathe and mill, followed by assembly. Most of the controversy is about the tolerances within the housing, as any leakage will reduce the efficiency. This means the spacing between the gears and housing, space between the gears and bearings, as well as that provided by the gasket that seals the housing base and top. This is where the comment section somewhat explodes with criticism and advice.As can be seen in the demonstration with a better gasket, there is absolutely flow when driven at 1200 RPM, but also clearly severe leakage as evidenced by said flow not moving quite as fast as it should. We’re looking forward to the next part, in which addressing these tolerances is tackled, with hopefully a much more performant gear pump resulting.youtube.com/embed/SIeOhI7Qng8?…hackaday.com/2025/10/27/buildi…