DAY 49
Today was a much more productive day than yesterday (actually more than the entire week, for that matter). I got done one of the tasks I set out for this week: the modular assets for what would be the cave levels.
And here is how that area looks like from the inside: https://drive.google.com/file/d/12dxP6Jm-FmGLVN1nuZACmgDcghIVk0MC/view?usp=shari...
These are not all the assets that are going to be used in the cave levels, though. I intend on having some specifically modelled rooms, when the need calls for them: some big, sprawling areas, some scenic ones as well.
Also, these assets are going to be used at the scale shown above as well as at 2 times and at 4 times their current scale. Why? Well, mostly because the designer wants it and he wants it done yesterday :)). OK, but seriously now, if I don't do it, he will berate me in front of everyone. Just kidding...or am I? Yes, I am a solo dev... But the designer will kick my butt tho :D
But I digress.
The modular assets at scales other than the original scale have one big advantage: they leave room for verticality in an otherwise mostly horizontal game space. There are disadvantages, but they are minor:
- one has to be mindful about their placement so as they would line up seamlessly
- they may lead to option paralysis when it comes to where exactly they could be placed (lower left corner exit, lower right corner exit, etc. In short around 9 options to choose from)
- in the context of random generation, they may lead to inconsistent gameplay (yes, this is still minor, and I'll explain why later)
- one big disadvantage is that it involves a lot of manual labor
The practice for the cave levels would be the following
- place the modular assets in the level
- place mechanics/puzzles
- set-dress manually
Now, you would think that if I made modular assets, I would use each placeholder piece in the modelling software as reference to create an asset and then be done with it. No, we don't do that here. It's obviously a time-saving pipeline, no doubt. You could say that it is a smart thing to do it like this and I would agree 100%. But that's not what I'm after. The set dress will be done manually for 3 specific reasons:
1) More control over variety on similar modular pieces (each piece, even if it is the same, will look and feel different)
2) More control over the environmental storytelling aspect (allows making fast changes)
3) It's good risk management and time management (if I make one piece and I ultimately reach the conclusion after a few playthroughs that I don't like it, I have to make another or modify it in the modelling software, which takes time. If I do set dressing manually in the engine, I spend significantly less time modifying without altering all the other identical pieces)
I mentioned earlier the fact that random generation of said assets may lead to inconsistent gameplay and said that it was a minor issue. The amount of random generation that is going to be used in the cave levels will be relatively small, but also relatively controlled.
Say we have a cave level that has 3 places where it randomly generated rooms, all 3 in different parts of the level. These rooms would be pooled in 3 different arrays and spawned at runtime. At each "spawn" point, there will be 3 different rooms (so 9 in total). For simplicity's sake, there's an Easy Difficulty spawn point that picks one of 3 easy rooms, a medium spawn point that picks one of 3 medium rooms and a hard difficulty spawn point that spawns one of 3 hard rooms.
Having this controlled creation in place would greatly diminish difficulty inconsistencies, but will not completely eliminate them. So the reason that this is a minor issue is that there might be one combination out of 20 or so (I've forgotten my combinatorial maths knowledge completely, so there's a very high chance that the number mentioned isn't even in the same zip code as "accurate") that will invariably produce difficulty inconsistencies. So there's that.
That's all I've got for today, guys. See ya in the next post. Bye