The deadline for this project's interim report is coming up and so I'm currently very focused on getting the prototype to a presentable state and having a fully working gameplay loop. To this end I have been working on my levels to give the player a variety of environments to encounter.
I decided that the levels I was using to test the level generation system where too small, and as such I have increased the level size from 50x50 units to 100x100. The level spawning code shown in the level generation post has been altered to reflect this. This gives the player much more room move around and makes completing a level feel like a more substantial achievement rather than just a quick task. I am still undecided on if this will be the final level size as I am considering making them even larger. This will depend on the results of gameplay testing once the prototype is fully functional. For now though this feels like an appropriate size so I have created 4 unique levels based on these dimensions. I considered working out a way to have the level layout be generated procedurally but this would have caused more trouble than it was worth so I designed each level myself instead. To maintain the randomised feel of the environment I took an off-the-cuff approach to the level layouts, simply dropping in walls and floors wherever seemed appropriate as I went along with the only real rules being that each door must be linked by a path and that every path must be wide enough for the character to fit down. Once the objective, enemy and ability generation is in I will be able to conduct some proper testing of the levels and will then make adjustments to anything that feels too cluttered or empty. This method allows me to quickly create many levels, keeping each distinct from one-another without making any of them instantly recognisable, maintaining the illusion of an infinite random maze. Here are the top-down shots of the levels, which I will create diagrams of for the design document later:
The pink squares are enemy spawn points. The placement and quantity of these is not set in stone. As with most things, this will change over time. Speaking of changes, one alteration I have made since implementing the level spawner is that the navmesh surface component is now stored in the level prefab rather than the prefabs of the level elements like the walls and floors. This means that if changes are made to the level, I only need to rebuild the navmesh of the level prefab rather than each element.
The point of this project is to maximise replayability by increasing the variety of player experience in as many ways as possible using procedural generation. This extends not only to variety of content such as levels but also to aesthetic variety. Of course we want to maintain an overarching style but making elements of the visuals and audio procedurally generated can contribute to making the player feel as though there is even more content than there is already. If you play through a level but then play through it again once it has been rotated and with different lighting, you may not notice that this is not a new layout. I happen to have already created a procedural lighting system on an old indie project of mine called Block E, so I decided to import the code over from there and use it as the basis for a new lighting system in this project. I created this directionalLightScript and attached it to a... directional light. The script begins by declaring a series of variables which will allow us to modify the parameters of the lighting randomiser to be exactly how we want them.
In the start function we then assign the light component, call a function which sets a starting value for our variables and then starts a series of coroutines which will continually randomise these variables over time.
The set variables function allocates random values to the lighting angle, colour, intensity and shadow strength, based on the min and max values set in the editor.
The coroutines then each pick a new random target value for their respective variable and change the variables over time at a set rate until it equals the target. At this point the coroutine pauses so the variable stays at that value for a while. Once the pause is over, a new target is set and this cycle continues. Each of the coroutines works in the same way.
This system allows me to select the limits of the variation to maintain the aesthetic I want and ensure visual clarity. Alongside this, created a new material for the terrain which allows it to catch the light really well so that seems as though it is the terrain which is changing colour. I also made an emissive version of the same material for the characters to ensure they stand out against the terrain regardless of the lighting.
Here's a video of me running through the new levels with the lighting system set to a low change rate, provide subtle, gradual variation. I then crank the change rate up towards the end to show off the massive variety of visuals available to this system. What the change rate will be set to is currently undecided but I am leaning towards keeping it quite low, so much so that the player may not even notice it happening, they could just stop at some point and think "huh, why is the level green now?", creating a sense of uncertainty. In fact I may even have the change rate change over time too in the same way the other variables do.
Comentários