this week was the last week i’m working this year, i may tinker here and there but generally its time off.
the week was split between finishing off the ammo intake system i started last week, and adding some much needed ux to the factory side of the game
ammo intake woes
there was a lot of iteration on the ammo intake system, and while a lot of it was a success (modular ammo works now), it turns out aerodynamics and drag are complicated.
as mentioned in the last post; each projectile is rendered into a series of connected nodes. these nodes are useful as they let us figure out the sequence that the projectile follows and mean we don’t have to fiddle with a bunch of entities, but it has an issue which is centre of gravity
it makes sense to have projectiles that are unbalanced be less accurate, but it seems to be quite complicated to make it so. i started naively by simply taking the average centre of each node and if it has a decimal (it is between two cells) in the width axis then add inaccuracy. ezpz
but not, as if the bullet is 2 wide, then it always has a decimal.
so then i tried taking the total width of the projectile into consideration; if the bullet is 3 wide, and this component is 2 wide, then it must be inaccurate? turns out not, what if the next node offsets it?
i ended up making a matrix of projectile configurations to work my way though it. i ended up deciding that a centreline system is probably the go but then got bogged down while actually making it. so for now, everything is perfectly accurate
here you can see the various projectile examples, left should be accurate, middle shouldnt be, but what about each on the right?
this comes into a game design question pretty quick: whats the way it should be? most projectiles are symmetrical, but if the propulsion segment is offset, should the projectile be inaccurate? i think so, as you don’t see it in the real world nearly ever, and it stands to reason that an offset case should project in an off centre trajectory.
after playing with this for a day or two, i got over it and decided that the factory side needs some attention.
UX
factory games have been around long enough now that some features are taken for granted, its easy to spot these when a game doesnt have them, as it feels like you’ve lost a finger.
given how much of a factory game is about building the factory, its very important that it feels good to do, and doesn’t get repetitive.
placing and removing blocks is easy but what else makes the building process feel natural?
the basics, most of these are natural and make the game nearly unplayable if missing:
- pipette
- a stable of any “drawing” type system where one cursor will be placing many different options
- a toolbelt or picker
- cant let the pipette do all the work
- zoom in and out
- even though there wont be additional detail at closer levels, its a method by which to add faster scrolling over the map surface that feels natural and prevents getting lost (zoom out, move, zoom in)
- speed controls
- the game is about building systems that are very unlikely to work on the first try, which means repetition, which means boredom unless these repetitions can be sped though
- reset
- similar to above, if something doesn’t work, you’ll want to try again easily
- factorio doesn’t have this but it generally isnt a big deal as buildings are easily to pick up and put down again en masse
- _satisfactory also doesnt have this, but given how hard it is to replace buildings a mistake can quickly become quite frustrating (oops, your crystal belt is covered in iron now) _
more advanced stuff, you can survive these being gone but it will feel wrong:
- drag placement
- another repetition remover, but dragging can have different behaviours in different contexts this is one that can be subdivide again:
- belt snaking
- when placing belts, it should be enough to make a simple gesture of your intended path and have the belts figure out how to pass the item
- this is noticeable in factorio when one presses R to rotate a long belt at a point
- this is notable in its lack in infinifactory, leading to a bit of fiddling with belts at corners, as belts only extend in a straight line
- lateral tiling of buildings
- some buildings are designed to sit shoulder to shoulder. its not helpful to have a ton of welders sitting crotch to ass, they only work side by side, therefore dragging should only extend laterally
- this is seen in satisfactory when dragging concrete, it doesnt just plonk down where the cursor is, but snaps together in a satisfying (and neat) way
- rotation memory
- if you’re placing a building, it should face the way that the last instance of that building is currently facing. another remover of repetition.
- factorio is notable for having this, when placing splitters, they’ll remember their direction for the next splitter
- undo and redo
- mistakes happen, when one can’t undo and redo it is all the more punishing for it
- factorio has this, satisfactory doesnt, and personally i think it goes a way towards how natural they are to play
great to have, these are really useful but you can pretty easily live without them
- copy and paste
- this is specifically being able to copy and paste a given area in a single level. its another repetition remover, lets players remove problems they have already solved locally
- blueprinting
- the natural progression from copy/paste, with the added bonus of letting players completely remove problems they have already conquered, becomes more useful the larger the scale
- this is only useful if there are further challenges to face in the game, if the game only has ‘place block’ as its fun driver and you can just get the optimum ‘place block’ BP, then the fun is gone.
- factorios fun is deleted by using online blueprints
- yet satisfactory completely missing this feature (for most of its life) made building large scale systems very hard
- mass move
- cut and paste in disguise
this list is pretty long, but everything except copy/paste, undo, and blueprints has been added. a demo below.
showing the various dragging functions
all in all the ux increased dramatically in really not very long. the next priority is undo/redo but we can live without that for a little while.
