a very busy week, with lots of non-game dev related updates like starting a business and doing hunting homework. anyway on to the point

the game feels like its made huge progress in the last few days as i pull together various disparate systems that have been worked on over the last few weeks and they all actually work together.

looking slightly better

demo

in order to get a fun game, you need a lot of testing. factorio famously was tested for many years before launch, the same could be said about doom eternal

to be able to test, i need more than just myself, so this week was themed towards getting the game into a state where it can be tested by others, even in a very primitive form. theres a lot to do to get this going and that was this weeks focus

  • primal interaction methods like main menu and level select
  • art so that the player can at least see the projectiles
  • level management systems and a way of structuring the level order

this culminated in creation of an itch.io page with an early demo:

https://claydegruchy.itch.io/ballistic-assembly

level management

had a bit of a quandary this week: how do you manage levels? and also what is a level? and why have them?

the answer why is easy: it’s a way to graduate the players progress slowly without overload, else you have a sandbox.

there are a few things we want to achieve with levels:

  • use levels to introduce new tools, challenges, or narrative components
  • not every level should do this, sometimes you just need to play the game
  • not all levels should be equally easy
  • levels are all or nothing events, not something you get rated on

with this in mind we had another question: how should a level be made? two main ways to think of this

**
**

generate at runtime

in this case levels are saved as basically an array with cell counts, cell widths, and lots of numbers regarding gravity and drag

  • this allows generation, also very easy to generate new levels on the fly and make “infinite” levels
  • pretty boring unless we make a good generator to make levels and at that point you’re just making a complier that produces levels
  • the levels keep themselves up to date as they are made on the fly

make by hand

in this case a level is crafted piece by piece

  • much better attention to detail, can design very closely to the desired experience
  • loading a scene is a lot easier as we can micromanage every little part of the scene
  • but means we cant generate anything easily and its tedious placing 250 building parts in a grid
  • doesn’t self update, if we change something big then we have to go change all the levels

ultimately we are currently making a level based game , so we’ll know which levels the player will encounter and the order so for the best experience, it makes sense to build levels by hand but who wants to do tedious shit. it wont be surprising that we went with:

**3rd option: hybrid **

we store the level as a scene with a custom type that includes data used to generate projectile cells and level boundries, but everything else lives in the scene

  • manual
    • place backgrounds
    • place doodads
    • place players, enemies, and structures
    • place the terrain
    • build the factory floor for the level
  • automatic
    • generate level boundries based of cell size and count
    • generate projectile cells based off the same

other changes

added terrain that is effectively an indestructible building. we can make it destructible later if we want.

added the notification system so that the player can see when damage happens or fires start easily while they’re aiming the guns

added some background art to show the player a sense of scale. really low quality stuff but sends a message (that message is “please go to art school”)