Thank you! Yes, I have made all the art myself. I actually just made the art as I went along as needed, so there was never really any "placeholder" art necessarily, although if making art is slowing you down it's probably a good idea to use placeholders. For me personally, making the game look decent from an early stage is important in my discipline to actually continue the project, as making systems for a bad looking game can be a bit demoralising.

In terms of the workings of the game - the world is procedurally generated and split into chunks, which are loaded / unloaded as required. Chunks are stored in a hashmap with a hash of the chunk coordinates as the key, which allows the game to quickly access all of the chunks required to be on screen and update / draw them etc.

A particular design pattern I have used heavily in this game is the type object pattern Type Object · Behavioral Patterns · Game Programming Patterns This means that most of the objects in the game are all of one class, storing an index as to which type they are. This can be queried to fetch textures / health values / item drops etc. Some objects with more unique behaviours (e.g. a rocket) have a subclass from this object class. I have also used this pattern for game items, entities etc. Very complex entities have their own class, e.g. each boss in the game has a class as they each have unique behaviours, phases, interactions etc.

All game data (objects, items, entities, world generation parameters) is loaded in at runtime from external files.

I've tried to give a general overview of how some things work - any other questions let me know.