Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits)

I don't even know how I crafted this thing (in 2 weeks ! (and +-1 month for 1.1 I guess)) . I was like...possessed and the thing just happened. I have no resources to give you except the 1.1 devlog here and me :

Among all the inspiration I already gave on the comment below, there are also City bomber (or Blitz, the game generate the city each time) an old computer game I was playing in elementary school, this game was also clearly in my mind when I made SLUMS 20 years later.

You can see how the buildings layout made of cells influenced the making of SLUMS. It's the same here. Just see the layout as a giant grid where 32x32px cells are colonized procedurally. When a cell animation reach a certain point it just trigger a "coin toss" and then the program decide to colonize a nearby cell and how to colonize it (or not), and then, the process repeat, again and again, on multiple layers, until cells cannot be colonized. The program follow a ruleset to build the city, while also picking building element on different pools depending on many factors. This, a ton of handmade assets, mixed with a ton of RNG, is what give life to the SLUMS

The rest, is just dark magic 😈

If you have any question...

Thanks :) Ok so if I understand correctly, you'd have a main structure grid with "plugable blocks" and some decorations grid picking random assets to enhance and bring more life and chaos (in an ordered way :P) + some variations depending on the different depths. Then vehicles + some ppl animations.
Rince and repeat for different biomes.
Is that correct?

(2 edits) (+1)

That's more of a logical grid, all the logic is made around 32px size main " plugable blocks", for art and math and all . Each blocks is effectively, a unique sprite/obj, with its variable and all. It's overly under optimized I think, that why you can sometimes read +1000 obj on the top right, near a "60fps" I hope. On early prototype the blocks were able to spawn without following any kind of grid placement and that was more ... complicated and chaotic, both from a dev or art perspective. You got the recipe. Here for example you have the very famous frame n°16 of the animation "BLOCK10" :



And here you have the frame n°11 of the object "SHIP", the USS... Callister :)


Yeah, that's about it, a bunch of sprites, some rulesets and RNGesus put into the equation. Amen. 

(+1)

Ohh it's so nice, clever, it's a bit like pre-rendered morphing. It make a lot of sense! Thank you so much for your kind explanations and for taking the time to answer me! :)

I don't know if you already use batching, but it could help a lot with draw calls and perfs.

If you talk about the draw call render technique. The engine do that natively. The perf seem ok on my side considering the number of moving shit on the screen. Stable 60 fps on HTML and + on desktop. But I really don't know if the engine does the job correctly in this case considering the astronomical number of animation frames spread on multiple spritesheet. I also considered the use of tilemap at early dev, a giant texture atlas for everything, but I finally used this method.