This is the start of a blog on a little game i’m making. the idea of this is to track what i’ve added and my thoughts, similar to factorio’s FFF

this week has been pretty productive. its early so theres tons to do with a lot in flux.

on the factory side

the factory side with walls and some spawners

added walls around levels, and added a core piece: the welder.

the welder takes two adjacent blocks and fuses them together. i debated a lot about if we should make a new abstraction to handle groups and decided against it, theres already a lot of moving parts in here so instead i opted that when a fusion takes place, one block is assigned as master.

the master keeps track of its slaves and its slaves redirect their events to their master for processing.

this involved a lot of thinking about pivoting offset bodies, as if a rotator turns a group we want it to rotate on that rotator, not the master.

on the shooting side

the shooting side as it looks now

with the addition of fused components, i could finally make progress on one of the main mechanics of the game: ammo formulation.

what i want from the game is to give the player a fairly concrete task (make thing go boom over there) and a lot of tools to get it done, and ammo formulation is right in the middle of the main game loop:

modify factory -> make ammo -> fire ammo -> check result -> repeat

when ammo is made on the factory side, it is deposited into a receptacle and gets shipped to the shooting side. but to do this we need to do a few things

  • we need to know how the projectile will behave based on what the player has made
  • i want to be able to make ammo with very complex behaviors
    • ie midair detonation or firing of additional projectiles
  • i want to be able to fire LOTS of shots at once

i always liked node graphs so below is a chart made from the bullet in the background. when a bullet is shipped it supplies the connected entities as well as the “firing point”. the munitions handler then walks out from this point through each block.

  • if the blocks are the same type and in the same orientation, then they go into group
  • if not they get a new group
  • after all is said and done we see what groups are connected and give them a magnitude based on the size of that group

this means we don’t have to deal with 20 blocks but instead transverse a simple tree, which will make things much easier for smart munitions later

a large ugly fused bullet

we then transverse this tree to calculate the properties of the munition. for the example above

  1. the cases on the left are where the “start” point is, so Case8 is consumed for velocity.
  2. then we have Slug3. slugs trade velocity for damage and weight.
    1. a projectile that is too light (or has an extreme ratio between propellant and payload) can’t actually deliver the damage that the propellant is creating, too heavy and it wont fire
  3. then finally we have Case2.
    1. cases in this position have nothing to detonate them, so they just add weight (and probably a ton of drag later)

then the munitions handler and the raycaster play together to figure out the trajectory of the shot, then hand that trajectory over to the projectile so it can act out the bullet flying

heres it all together