Devtober Day #9

Welcome back to Day 9 of Devtober, in which yet more schoolwork piles at my feet and I continue to unlock the secrets of the rigidbody.

As is the bane of every college student, I completely lost track of just how much schoolwork I had to finish up today, so today's also been pretty sparse on progress. On the upside, it's given me plenty of time to come up with some solutions to my item system problems from yesterday, so hopefully, I should be able to start acting on them more tomorrow.

The crux of my problem with items is that they need to act both as physics objects, but also static ones when being stored. While I can switch between the two modes rather easily, it's getting objects from point A to point B that remains the problem. 

My solution to this issue has come in the form of a couple magic functions-- namely, the rigidbody's "_integrate_forces" and the transform's "interpolate_with." Integrate_forces should, in theory, allow me to adjust the rigidbody's transform values similar to the _physics_process() function, but without completely breaking the physics system. Interpolate_with, on the other hand, will give me a smooth transition between one transform and another, allowing me to smoothly slide my item into position. 

Of course, trying to do that by itself would cause a whole heap of clipping problems as the rigidbody tries to move through objects in order to get into place, so I've also added a toggle to switch between different collision layers when switching between storage and worldspace. Since inventories will be storing items in a physical location based on their location in the array, I can just set the target of the transform interpolate to wherever that physical location may be. I can also do this in the reverse, interpolating an item into the player's "hand" before reactivating physics and collisions for the item.

Well, at least I hope that's how it'll work. Actual implementation will have to wait until later when it's not 4:30 am and I feel like death.

Another issue with items is having to store their data in between games. It wouldn't quite do for a player to make a whole load of progress, only to have none of it persist between sessions, now would it?

Luckily, Godot allows us to define our own custom resources, which can essentially be thought of as containers for data that we'd like to both read and store. These resources can also be instanced just like any other class, so we can also reuse them and allow specific items to have their own copies of the resource, yet still be able to easily store that data. Thus, the challenge is in creating a hierarchy of classes and resources to abstract the data we need individual copies of vs general data to inherit from.

For example, a smithing grid is split into a smithingGrid script and a smithingGridData script, which inherit from the Item and ItemData scripts respectively. The Item class essentially defines how the item works as a physics object, governing things like the movement and collision code I described earlier. ItemData, on the other hand, is a resource class that is inherited by the various kinds of data that a particular type of item will be using. The smithingGridData resource stores all of the information the smithing grid needs, such as the voxel matrix, forging resource, and component type, the latter two of which are resources on their own. You can probably start to see how easy it is for the system to get a little out of hand once we take into account the many different types of items the game will be supporting. Since a lot of these scripts are meant to work in a modular fashion, carefully choosing what data should and shouldn't be at certain levels of abstraction can shape up to be quite a challenge.

Anyway, that's about it for now. 'Till tomorrow,

- Ian, Lunarium Works