Skip to content

5 December 2024 - Physics, Entities, and ...Music!

<<< Previous Post Next Post >>>

  This is more of a generic status update post since I have been gone a little while and want to keep you all up to speed. Not much in this one.

Physics and Entities

  On the logic side of things, most of my existing entity code1 is still compatible with everything in the game now, the main hurdle here is the change in node structure. Another huge flaw I had was that living entities did not use discrete classes for each kind of entity. I have a separate class called Species which is used to store the identifying features of living creatures (it's almost the same as what Starbound does). I still have this class, but now entities need a dedicated class for their species as part of the data structure.

  Onto the area of physics. I'm still stuck. I have some options left before I just drop character physics.

  1. Try to make RigidBodies "kinematic-ish" with custom integration.
    1. This has the cost of giving a huge middle finger to physics which will result in weird behavior.
  2. Use my simulation technique as it stands now, but force all colliders to be spheres.
    1. This works best with my model of fast character physics because I can trim out calculations pertaining to inertia, mass, and friction. Without these factors, spheres become purely linear objects, and collisions become as simple as distance checks, allowing fast physics calculations.
    2. This has the drawback of pretty dramatically limiting the shape that physical bones can have and collide with. I don't think modders would like this.
  3. Turn bones into unstoppable forces. This is built in behavior to Godot via animatable physics objects, but as mentioned, they are unstoppable forces. It doesn't make sense for some dude's tail to yeet a box across the room because it got in the way. The tail should stop.
    1. This is definitely the easiest solution but also wreaks the most havoc. I doubt people would like this much either.
  4. Pull a BONEWORKS and have two rigs simultaneously, one controlled directly from code, the other simulated, and make the simulated bones try to reach the scripted ones.
    1. This would introduce complexity and I worry it will nuke performance in excess.

Music

  As of two days ago, I started learning FL Studio and how to write music. So far I think I have the basics down, but my capabilities are unfortunately harshly limited, and iteration time is long because I have to listen back to my own stuff after many idle hours so that flaws stick out a bit more. It's harder to find flaws when it has just been created. Useful tip for all art mediums. Make a thing, sit on it for hours or days, then come back, and the flaws will stick out to you.

  Anyway, that is definitely a background goal, learning to write my own music for the game.

  1. I tend to design "skeleton frameworks" for things I plan to work on in the future. This way, I can get a feel for how I want something designed in the moment, without putting a significant amount of time into actually developing it. It's kind of the manual equivalent of prewarming, and helps promote more agnostic and scalable designs. ↩