The elements of physics are the law of conservation, calculus, theorems etc. and they are used to design theories. For a programmer the elements are 'for' loops, 'while' loops, caches, data. The spaces that we solve in also have different levels. If we are doing graphics programming, vertex buffers, over-drawing become elements in the space that we are solving in.
In this movie they had an analogy of there are all these universes existing at once (the spaces we operate in), and we are like a radio that can tune into a station. The deeper we know a field, the multitude of different wavelengths exist for that universe that we can tune in to. A capenter sees the grain of the wood, understands how the wood will bend and cut with different implements, knows what strength the wood can handle. But an inexperienced wood worker only sees wood.
What this is all about is game design. A player comes to a game and solves problems within a space that they are presented. The space they solve in is crafted by the game designer. So as the game designer, the space I'm working within have elements like platforms, gravity, doors, game mechanics. So as I approach the game, I have two spaces I'm in. Programmer space, in which I feel like an engineer. Then the game design space, where I drag around objects on the screen, piecing together levels. Although there may be some overlap, I'm trying to just think with the unique elements in each space.
So in order to experiment and explore this space, I need a very strong save/load ability that allows iterative workflow, and that I'm not scared to use (because it will crash or corrupt the data). Previously I implemented a save/load data system that created just one file that contained all the entities, and the data was set out like a relational database. I found this wasn't the best solution. All the values were dependent on their order in the file, so if something went wrong (a value was accidentally deleted), I wouldn't know which number corresponded to which entity attribute. Also for enum types I just set the number, not the corresponding string, which doesn't jell well when you want to change the data in the file, look at the data and if I change the order of the enum, the data is invalid.
So coming at it this time I had a much higher bar. I first did the save data. At first I wanted to have a binary format, as it was suggested by Mr 4th dimension https://top.handmade.network/blog...s_on_cross_cutting_concerns#14759. But in the end I decided to go for a JSON style text format. Furthermore each entity is it's own text file, so a 'level' corresponds to a folder of entity txt files.
Each entity file looks like this, where the first object has attributes unique to that type of entity, and commons are attributes that all entities have:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Door: { partnerId: 2; } Commons: { id: 1; name: "player"; flags: 251; type: "ENT_TYPE_DEFAULT"; position: 1.000000 2.001000 -1.000000; renderPosOffset: 0.000000 0.000000 0.000000; dim: 1.000000 1.000000 1.000000; renderScale: 1.000000 1.000000 1.000000; shading: 1.000000 1.000000 1.000000 1.000000; texture: "door1.png"; inverseWeight: 1.000000; animation: "knight animation"; } |
For loading I followed the header modules engine style and made a portable lex.h file. It just creates tokens for a given char stream and has easy methods to move through them. At first I though maybe I could then create an Abstract Syntax Tree and treat it more like an arbitrary language. But I didn't end up doing this, as it seemed alot of work so I just treated the file as declarative data with implicit types.
Overall I think this is a much stronger file system than before. It will allow me to experiment with gameplay and allow me to edit offline easily. Maybe for the shipped game Ill move to a binary style file format that will be quicker to load at runtime, but for now this works great.
Any comments, suggestions or thoughts please leave below!
Oliver
NOTE: This philosophy further expands to we only know something in how it relates to other things. We can't know something absolutely. I think this is similar to Thomas Kuhn's 'The Structure of Scientific Revolutions' where a space is a paradigm and we solve puzzles (in this case design in that space) within that paridgm.