4

I’ve built another random test area to learn how to export from Blender to Unity and make it more like the target environment. In other words to make a brutalist interior. I was hesitating on the size the model should be, because previously they turned out to be small when imported to Unity.

About size: the conclusion is that the size of a model in Unity depends on the scale value that is set up on the prefab before importing that to project. Before realizing it my model became huge, as according to several tutorials I set up the scale factor too big of a value (just didn’t think that they were importing small assets like barrels, while I was importing a whole area. Tutorial reference: https://youtu.be/nhJ8EJ_GtLI). This made the environment so big, that camera was clipping out several of its parts in the distance.

Lighting: this was done with some very basic knowledge of lightmapping in Unity at it is as it is. But it worked. Horrible, but worked, so it means I have to dig further on the topic.

I also wanted to try glowing panels following Brackey’s tutorial:

That turned out not ideal, but I got the idea how to do it.

Going further

After that I decided to model part of the floor plan that I’m going to implement in the final version. The starting one whith flooring/repetitiveness elements.

And I still couldn’t decide which way of modeling is better, because if building from solid blocks, then it becomes difficult for me to see through the model, and it take much more time to model.

Whilst I was strarting to research the topic of lighting, I noticed that designers quite often used panels for walls and floor, which are visible only from one side. That allows very good observation of what you’re doing. So I thought it would be a very good option since the area is big and trying to clip through walls to see something was not comfortable.

By that time after trying a couple of times to buld the area from modules in Unity doesn’t suite me at all, as Blender does that much more efficiently (especially with snapping tools and freedom to alter the modules in any way or add new ones very quickly). So my workflow is set up to modelling in Blender and exporting that to Unity.

To try that I completely recreated Brackey’s tutorial. (This was the time I discovered he was using panels. He didn’t mention how he modeled the room.) And those really turned out to be panels that he used. And practiced some more on lightmapping. That’s where I learnt to set objects to static in order to apply lightmap correctly.

I still hesitated between planes or solid shapes for walls, but started off with panels. And while it looked nice in Blender and was fast to make

in Unity it looked horrible and unable to work with it adequately, because you’re just not able to see the whole picture. I needed visibility, but not that much

it is the very same model with everything in place, but you can’t see them because they are panels

So my conclusion here is solid shapes are my only option. This method is suitable for more simple environments, but when everything is supposed to overlap, it makes a mess. + as test showed, panels have issues with collision, and character was often stuck in the walls.

I’ve spent several days building the final piece and it turned out pretty well.

So the next thing is to actually work with lighting. Hopefully it will be possible to implement what I have in mind.

3

So the donut experience turned out to be very useful and made me much more confident with modelling and following experiments. At least I thought that modelling would take me much longer than set up in Unity, but it all happened vise versa.

I had 2 approches in mind for level design in Blender: a solid level buliding and modular geometry.

I started with a solid level like in tutorial here:

I saw benefits in quick carcass of the whole level which I could fill with details afterwards. I all went fine in Blender and I successfully exported the model to Unity. And that’s where problems started. While Blender allowed clipping inside, Unity didn’t, what ended me having just a number of interconnected solid blocks.

But still the experiment didn’t fail entirely as I tried colliders and physics with a 3d object, which went well (and I must note seems a bit more adequate than with 2d colliders). Maybe there is a way to render the object with insides, but by that time I decided that I won’t use this method as it will be hard to make the interior layout with constant need to be inside the object.

So I quickly went for modular geomerty:

I quickly made simple modulars in Blender. Very basic just floo tile, wall tile, doorway and ‘stairs’ (I wasn’t sure how to handle normal stairs, so just made a slope for a quick test).

First I built a simple room and also tested collisions, which worked very good and smooth

Then I’ve developed it in a small interconnected area with flooring. My aim was to test how I can cope with stairs or at least slopes. The complete area looks like this, pretty simple, and very time-efficient with using modulars.

But that’s only camera movement, to test it properly I needed to make a first person character movement, which I never did before (ok, actually everything in this project is something I never did before since it’s a 3d game. So further on just keep in mind that everything was new for me). And though it was tiresome in terms of set up and figuring out the cause of some collision problems, it all went pretty well.

This was the end of my day of experiments which helped me significantly to see where to move forward. So the game will be definitely in 3d, and I can cope with a walking simulator. There are some pecularities on the technical part that I’ll need to keep in mind when exporting and setting up in Unity for the actual level map, but in general I can start thinking through locations and interiors as well as navigation elements for the project.

The next test area is ligting both in Blender and Unity. I tried a little bit of that even this time with a spot light in the first room. But I’ll need some atmospheric and special lighting for my navigation system, which might be easier to do in Blender as I’ve already tried some during my tests with donut. But that’s the topic of further research. So far I’m quite confident in the progress.

2

This week I’m starting to learn Blender. I have already learned some basics, and in general I found the program much more convenient and responsive compared to the 3D programs I used to work with before.

As the first test project I followed the donut tutorial, which made me familiar with some basic tools. The outcome was beyond my expectations, where I managed to make a photorealistic modelling and render.

It means so far I’m confident that I will manage to model the map for my game, which is much easier and won’t require even less modeling skills that with a donut since it will be very geometrical. Next step is to learn to export that to Unity and see, how it works as a game environment.

So for now what I’m doing is:

  1. Model a test map containing a couple of rooms and flooring
  2. Learn how to export the level to Unity and how to set it up correctly
  3. Set up character movement in 3d space and make sure all the test build works correctly

If that succeeds, then I’ll start producing the full map and gradually develop the game concept.

1

Final major project directly continues the thesis topic and is devoted to implementing proposed theoretical model of LL navigation system.

The thesis offers an alternative light&landmark based navigation system for brutalist-like environmments in contrast with signage and mapping system of Control, which causes significant navigation issues provoked by pecularities of brutalist style: repetitiveness, visibility and complexity.

Breefly, LL System is based of the following principles:

Light as the main navigation tool

Light forms landmark patterns or is combined with architectural landmarks:

Architectural landmark combined with area light pattern
Fill light area pattern

Light forms 2 types of navigation: global and local. Global is formed of key or fill lighting (depending on situation) of a particular pattern, assigned to a specific area. Local activates in complex rooms, where an action must be taken. Global lighting is deactivated not to interfere with local lighting.

A room before activating local navigation
The room after activating local navigation. Global lighting is dimmed.

Game genre

I see the game as a walking simulator genre because the main idea of the project is to test my manvigation system. But in order to make the game more like a game, but not a navigation test, some entertaining elements must be added. I see 2 options: a story or some puzzle element. The main point is that player will need to orient themselves in order to get to some key waypoints and reach final destination.

There’s a concern about split screen which was one of the first ideas about the project. Split screen will allow to compare 2 navigation systems: Control-like and my system. In case of a split screen, ideally it should resemble Medium, where pathways appear on another screen in spirit world.

The Medium review: a clichéd retread of horror tropes - Polygon

This will clearly demonstrate how my system makes pathways more evident. But I’m not sure about my capabilities to implement that technically.

Another option is to make 2 runs with different navigation, but that has familiarity issue, when player will get more familiar with the environment during the second run, which will make navigating easier despite the system. So I wouldn’t opt for that.

Map

Within thesis I’ve developed a Control-like map, which I’ve designed to imitate the 3 legibility issues of the environment.

Player will have a task to get to the ground floor, solve a puzzle (or get further instrustructions) and get back to the start to exit the level. In order to make navigation task more challenging, some of the fastest pathways will be blocked, what will tell the player to look for another pathways depending on navigation hints. The blocks will be placed in such a way that player will have to pass through all 3 test areas before finishing the game. That will allow to check navigation effectiveness in all of the 3 issues.

Visuals and inspirations

Visually I see the game similar to Fugue in Void and Naissancee wich combine simplicity and specularityof brutalist architecture.

NaissanceE and games that are hostile to the player.: truegaming
Naissancee
Fugue in Void by Moshe Linke
Fugue in void

This is the bare visual minimun to make brutalist environment work and won’t require much texturing. Also due to geometric forms this will allow low amount of polygons and relatively easy modeling. Also this will exaggerate repetitiveness even more wich is benefitial in our case as it will perform additional testing to the system.

Technicalities and further work

Currently I’m on stage to choose the game form, which requires some technical research. Ideally I see it as a 3D game, but I never made one in unity. So that will require modelling and importing models to Unity. As far as my research shows, levels are usually modelled in Blender and then expoirted to Unity. Same concerns lighting, which is key for this project. So my goal for now is to make a basic test level with a couple of rooms and stairs with lighting in Blender (which is also new for me) and try out how it works in Unity and if I’ll be able to make player succesfully move in that environment. If that’s succesfull, I can implement the map and focus on lighting navigation. So, basically the speed and form of the project depends on this key step as I’m still not as experienced with Unity.