Current design decisions for my game engine:
Uncategorized
85
Posts
1
Posters
0
Views
-
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 #Godot 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.
-
undefined Oblomov shared this topic on
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Certo, resta da capire perchĂŠ, con questi sponsor
https://www.python.org/psf/sponsors/
abbia un budget annuale di 5 milioni di USD, perchĂŠ 750 k facciano quindi tanta differenza, e perchĂŠ questi li sponsorizzino malgrado non abbiano un sistema di protezione della supply-chain e dei pacchetti del repo principale.
Però è vero che se riuscirei a fare quei soldi con le donazioni dei singoli avrebbero gli stessi soldi e meno padroni.
Ricordo, quindi, che il FOSS è gratis ma molto costoso. Donate quanto potete
-
@Uilebheist ma nemmeno lo fa in allegria
-
A 19 anni ero convinto che di lĂŹ a poco sarei partito per un tour mondiale con la mia band hard rock.
A 24 rispondevo alle chiamate in un call centre.
Wat de fak is andato storto in quei fatidici 5 anni?
-
đ§ľđ
From: @ThePSF
https://fosstodon.org/@ThePSF/115446659188615376
-
Viaggiatori, è quasi tutto pronto per il mio viaggio a La Gomera (isole Canarie).
Durante il viaggio cercherò di postare foto e pensieri, si Pixelfed, e sul neonato gruppo "Viaggi e Foto" su #Feddit (https://www.feddit.it/c/viaggi).
Ogni giorno scriverò qualcosa, Nun mini blog del giorno, anche sulla sezione dedicata del mio sito:
https://simoneviaggiatore.wordpress.com/la-gomera/
Restiamo in contatto! đ
-
La targa per Giuseppe Pinelli è stata vandalizzata per la sesta volta
à stata vandalizzata per la sesta volta la targa in ricordo di Giuseppe Pinelli, ferroviere e attivista anarchico morto il 15 dicembre 1969 nei locali della questura di Milano. La targa è posizionata in piazzale Segesta, a San Siro, non lontano dalla sua abitazione.
da https://www.milanotoday.it/politica/vandalizzata-targa-pinelli-ottobre-2025.html
Aggiungo un'altra foto, che nell'articolo non compare, di un cartello apparso questa estate "tra una vandalizzazione e l'altra" che riporto testualmente:
"Giuseppe Pinelli: assassinato e vilipeso. Il Cippo in Piazzale Segesta, in memoria di Giuseppe Pinelli, partigiano-ferroviere-anarchico, ancora una volta è stato vandalizzato per mano della topaia fascista, avvalendosi delle coperture del governo di destra.
Un governo che vuole riscrivere la storia e che utilizza il Decreto "Insicurezza" per reprimere le lotte rivendicative di lavoratori, studenti e movimenti vari.
Una legge bocciata anche dalla Corte di Cassazione, ma l'attuale governo, come giĂ nel ventennio fascista, risponde: "Ce ne freghiamo".
-
I made a couple of points where #Linux excels over #Windows
https://youtu.be/pkvTIrKRLas
-
The Supercon 2025 Badge is Built to be Customized
For anyone whoâs joined us for previous years, youâll know that badge hacking and modification are core to the Hackaday Supercon experience. While youâre of course free to leave the badge completely stock, we encourage attendees to tear it apart, learn how it works, and (hopefully) rebuild it into something unique. There are even prizes for the best hacks.
As such, every decision about the badgeâs hardware and software is made with hackability in mind. Itâs why we always try to add an expansion port to the badge and, in recent years, have leaned into MicroPython to make it easier for attendees to modify the code.
But one thing thatâs been largely missing in previous badges is aesthetic customization. Sure, you could strip out the firmware and write something entirely new, or hang some oddball peripheral off the side of the thing, but ultimately it still looked like the badge we gave you at the door. Thatâs because, at the end of the day, the badges are just PCBs. Short of designing your own enclosure (which has certainly been done), every badge looks the same. That is, until now.
This yearâs badge is unique among Supercon badges because it isnât just a PCB. Itâs actually a stack-up of two PCBs! That might not sound like much of a distinction, but in this case, the front board has no electrical function â its only purpose is to hold the keyboard membrane against the dome switches on the rear PCB. The only reason we made it out of a PCB in the first place is that it was convenient and cheap at the scale we needed. But if those werenât concerns, it could just as easily have been 3D-printed or cut out with a laser or a CNC router.
While the necessities of running two hacker cons on opposite sides of the planet within a couple of months of each other meant we needed to think at scale, attendees are free to do whatever they want between now and when they get their badges on Friday. Want to carve a front panel out of aluminum on your CNC? Awesome. Perhaps laser-cut some thin plywood and give it a nice stain for that old-school look? We love it. Want to see what that fancy multi-material 3D printer youâve got is capable of? So do we.
Some Assembly Required
Hailing frequencies open, Captain.
Spacing between the rear and front boards should be approximately 2 mm.The area around the keyboard should be roughly PCB thickness (~1.7 mm) for optimal typing.Youâll need to provide hardware (M3 nuts/bolts work well) to attach the front panel to the badge.
Want to make the 2025 Hackaday Supercon badge your own? Just head over to the âhardware/mechanicals_and_modelsâ directory in the badgeâs GitHub repository and youâll find STEP, DXF, and SVG versions of the front panel. Weâre eager to see some wild and wonderful front panels, but there are a few things to keep in mind:If youâve got other questions or need some assistance, leave a comment below or check in on the #badge-hacking channel in the Hackaday Discord server. See you at Supercon!
