Devlog 2 - Level Blocking

Devlog 2 - Level Blocking

Quite a lot of work was done this last week, but not yet enough. Again, I have fallen behind in regard to sticking to the weekly theme, however Dark Testament is at a stage where I can easily describe and convey what development will follow regardless.

Most of this week was spent on artwork and lighting, as I felt getting at least rudimentary artwork into the game would help visualize the environment. Obviously, I got carried away with it, redoing the player character sprites and creating most of the first level’s tile-set.

Using Adobe Illustrator to make the wall tiles was a complete nightmare, primarily due to my lack of foresight regarding layer management. The entire sprite-sheet (vector-sheet?) is on a single layer. Instead of just fixing the problem, I instead opted to just put up with it, turning it into a massive headache and a well-learned lesson. The future tile-sets will be given more forethought for sure.

The floor tiles were a lot more straightforward. The first attempt wrought some hilariously bad artwork. This will never be used, and for good reason.

It did however allow me to come up with a way to use Illustrator’s ability to randomize position/rotations of masses of objects to my advantage. Below is the 3x3 tile sheet, note the identical border tiles

Some oddities are noticeable with these tiles, caused primarily by some bricks being in front of or behind others on one side of each tile but not the other, causing a seam. This will be fixed or overhauled later. Also the brickwork isn’t interleaved because I forgot that was a thing.

Another experiment undertaken was creating a simple 3D model from scratch and transforming it into a 2D prop for the game, mainly to explore the process I could use for later art assets. Starting in Blender, I made a simple 3D model of a rock using the default sculpting tools. More precise objects would simply begin in Rhinoceros, but Blender has better sculpting tools.

It was then transferred into Rhinoceros, where the normal map was generated.

I then exported the vectors into Illustrator in order to get the sprite itself. It only needs to be a single colour as the normal map creates the “texturing”.

The resulting prop in-game turned out well, with only some slight alignment problems due to the normal map being rendered at a slightly different size, a problem I am still trying to find a solution for.

From these results, it could be said that this process is feasible for more artwork, as this particular prop only took about an hour from start to finish.

I also generated a simple noisy normal map in a similar fashion that I can use to add detail to otherwise flat or simple artwork through Unity itself.

It started with black and white noise generated and blurred in Photoshop, put into Rhino as a heightmap, and then turned into a normal map as usual. I then adjusted its contrast slightly in Photoshop once more.

Some tiling mismatch is visible, but this will be later ironed out.

Onto the new lighting, I spent quite a while trying to get the Universal Pipeline Renderer implemented. What I have now is a pretty good lighting system, along with easily placeable torches to use with them.

Starting room lighting

An earlier test of the wall shadowing

Prop lighting

They even have flicker and particle effects to them.

It took a while to get the particles right.

Having the lighting ready, I am finally moving onto the actual level generation system. It currently isn’t functioning yet, but I am in the process of laying out the framework and supporting code for it.

At the moment, I am putting together the main template prefab from which I can create and spawn the different rooms. Each prefab is an empty object with child tile maps for the walls, floor, and static props that will make up each room.

Each RoomTemplate parent object will eventually contain the scripts for the spawning of enemies, physics props, and the spawning of each further room. Currently, only a yet-to-be-finished script for the room spawning is present, but is arguably the most important anyway.

Each possible room is stored as an independent prefab, and the room spawning script spawns them wholesale. No idea if this is efficient or not, but it seems easy to do. I have pre-emptively set up some data structures and their accompanying gizmos to visualize them.

Each room type will have a set north, south, east, and west opening, which will procedurally spawn a random room type connected with said openings. Just prior to spawning a room, it will check the proposed area using raycasts to ensure that the space is empty. If it isn’t empty, or it chooses not to spawn a room on that end via dice roll, it will simply seal off the opening instead. Using a global counter for “rooms left to spawn”, it will determine when to spawn an end room. If it corners itself and can’t find space to spawn more rooms before the counter runs out, it will reset and try all over again. Hopefully this leaves me with a fairly versatile system for easier development.

The physics props are under their own global parent, in order to use a composite shadow caster.

I also implemented a look-forward mechanic onto the camera, which looks further ahead towards the mouse. My first implementation had some math errors, and was a bit jittery, as picked up in the feedback received.

I have updated this system and fixed the jittering, now the transition is consistently smooth.

The nuking of the gifs is mainly a result of the flickering lights, which I’ll definitely add a global toggle to now for recording.

The next steps in development are to get the level spawning functional, followed by the player’s attacks and object interaction, and then sorting out enemy behaviour. 

Enjoy