Thinking of games as databases
ajmmertens.medium.com
Thinking of games as databases
1–10 of 70 posts
Re: Thinking of games as databases
#2This is the essence of MVC/MVP architecture!
Re: Thinking of games as databases
#3This is the essence of MVC/MVP architecture!
When I first tried to learn ECS (recently!), I couldn't wrap my mind around how arcane it seemed to be. What "components" should there be? What properties should each Component track? How do I organize it? What if I move things around? I have to write handlers that load and unload the damn things, and a System that somehow knows where to find certain properties on the various Components enough to operate on them? Examples were always pretty esoteric or contrived. Didn't help that they were all written in C++.
One day it clicked that this revolutionary idea sure looks a lot like a series of queries/views ("Systems") on a bunch of database tables ("Components") foreign-keyed to a single object ID ("Entities").
Some people can overcomplicate anything...
Re: Thinking of games as databases
#4The backend of Skyrim (and other Bethesda games) is largely a database. Bethesda calls them .esp files, but they're relational in a way. There has been a large open undertaking to produce tooling for this, such as xedit (Pascal) and z-edit (JS).
When you open a container in the game, and it doesn't have a specified set of contents, the contents get loaded by picking randomly from a category linked to in the database. If, in one of the db tools, you follow the link from the container you can see what objects could load in it and by what likelihood. You can then follow those links through the db over to the object itself, which is also made up of db entries.
From the scripting system you can access the db for some amount of functionality. Their db doesn't contain the models or textures or strings. But it does contain the location of every tree in the game. If you wanted a mod with a dozen golden crates to go find, you would use the db system for the logic.
Re: Thinking of games as databases
#5Well, yes. Anything with "stats" or "inventory" looks very much like a database to me. This kind of thinking could also help avoid the risk of object-duplication bugs that occur in games which haven't been entirely rigorous about transactions.
Re: Thinking of games as databases
#6Of course, a game is a virtual world, and the player's behavior in this virtual world can express his inner thoughts to a certain extent, including good and malice, and some sociologists have conducted sociological research through the player's behavior in games.
Re: Thinking of games as databases
#7If you use an entity component system then you’re basically already there.
Re: Thinking of games as databases
#8In 2013 I wrote about "game interfaces for work" where work interfaces should act like games. Real time strategy games make you feel empowered, if you could queue up real work in a units runqueue. Of course you'll have actions besides "build" and "attack" to map to the richness of the world.
https://github.com/samsquire/ideas#71-gaming-interfaces-for-...
Even the mouse is a database https://queue.acm.org/detail.cfm?id=2169076
I want a graphical representation of the spatial properties in a database
Re: Thinking of games as databases
#9Any time you put data somewhere, organize it and give it an interface for efficient retrieval you have a database. Game state, generic data structures and practically an organization of data in software can be thought of the same way, so this is not exactly any sort of revelation.
Re: Thinking of games as databases
#10Remember: game devs don’t create intelligent game entities; instead they create the illusion of intelligence. Game dev is a big smoke an mirrors charade.
Any system that could be queried needs to be built and maintained. Creating game entities that have models of feeling or have opinions about the groups of people they belong to has to be modeled and built. Unfortunately game dev is very informationally and financially sparse so creating these systems is a huge undertaking.
I heard a joke once about OOP: if you want to create a form that accepts payment information you must first create the universe. The joke speaks to a danger of overdoing your conceptual modeling. The real trick of a true craftsperson is to create a model that is excellent at solving the problem on hand.
What I’m saying is we’re a long way away from game entities behaving like west world hosts and embracing the ECS paradigm isn’t the answer. Just like how switching from OOP to functional doesn’t actually solve creating a profitable business.