Now that we have the basic 2D mechanics of pointing, clicking and dragging implemented, I want to start working on the next part of our scene: a large shelf or cabinet that the player will need to collect items from throughout the level.
Creating 3D Models
I made these sketches after looking at reference images of old wooden shelving/storage units, particularly Victorian ones and apothecary cabinets because aesthetically they fit the style and setting of our game. I think something with a mix of shelves and drawers would be best; this way we can have a mix of items that are more visible and on display and items that are hidden in drawers. We want the player to be able to interact with the shelf/cabinet, so being able to have a selection of drawers and doors to open seems ideal.
The second design I made fit our needs the best, so I decided to use that as the reference for modelling our cabinet. We can always use the first design later if we find we need more furniture and want to add an extra unit. We also felt that the second design had more of doctor’s office look to it, and the labelled drawers and display case also seems more fitting for a workshop setting.
We plan to use low poly models for the game, so admittedly some of the detail from these sketches will have to be omitted. However, I still think it should be possible to create something very close to what I designed here. We have decided to use the second design, as we think it will provide more interactivity and also seems the most fitting for the setting we are trying to establish in our game.
I made this model in Blockbench. Blockbench is a free 3D modeling software for creating low-poly models. It is relatively simple and is similar to modelling programs like Blender (although much more basic and restrictive in its features), which makes it ideal for creating simple models from pre-existing forms like cubes and cylinders.
This was my first time using Blockbench but I found it fairly intuitive and easy to pick up. It also allows you to easily paint a solid colour texture/UV map for the model which can be exported as an image. For our purposes the textures we need will need to be painted elsewhere so we can add more detail, but it is very convenient that the program can give us a basic unwrapped texture to directly paint on top of.
Importing Models to Unity
I exported the cabinet model from Blockbench as an obj file, then imported it into Blender to get a better look at it and double-check everything. Then I exported it as an fbx and imported into Unity. For now, I’ve just applied some different materials but later I will also be able to import the texture created in Blockbench and edited by Sam in separate software.
I had some problems when trying to import the model with its drawers and doors in place, because they need to be separate objects in order to function as separate parts, but doing so means the transforms are set to the wrong place. I couldn’t find anything I could really do about this other than having to manually reposition each moving element (doors and drawers) into roughly the right place. I wasn’t entirely happy with this because these elements are no longer in exactly the right placements, but it doesn’t seem as if that will cause any issues.
I also wanted to set up the drawers as prefabs so that any changes made to them would be applied to all, so it seemed as if manually positioning them would still be necessary.
Considering Camera Perspectives
There are 2 options for the main camera view in Unity, one being orthographic and one being perspective. Up until now I have been working with the default perspective view, but wanted to look at the orthographic option as it might be closer to what we want for our game which blends 3D and 2D assets and uses fixed front or top-down viewpoints.
Perspective Camera
Orthographic Camera
Difference Explained
Orthographic cameras seem great for isometric perspectives and when you want to essentially “flatten” your field of view or make everything even.
The problem with the orthographic camera in Unity is that I can’t use the transform of the main camera to zoom in and out of objects, instead, I will also have to add something to the script to change the size of the camera. The orthographic camera also proved to be much harder to move and position compared to the perspective one.
However, it does seem like it might give us a nicer, cleaner view, especially when it comes to simplifying the many rows of drawer handles on the shelf unit. It does however make the space feel less 3 dimensional, which is a shame considering the work put into having some 3D models, and it also makes it harder to distinguish the layering of details like the rows of drawers.
For now, I have decided I will stick with the perspective camera and will try to get the best possible camera angles, but I will keep this in mind in case we decide we want to change to orthographic
Interactive Drawers
I created a script that would allow me to move the drawer game object by tracking the mouse’s position and using the OnMouseDrag() method to update the game objects position to that of the mouse’s x position. This script is attached to a box collider on the drawer’s handle.
I then have add some conditionals to essentially clamp the game object position so it can only move as far out and as far in as we want (e.g. the start position and as far as as possible whilst still being on screen).
We also decided to make only the top 2 rows of drawers nodes, so I disabled the box colliders on the drawers on the bottom row so they would no longer be interactable.
I then used the same method to make the cabinet doors interactable as well.
For this, there is an extra step because I have 2 doors that will slide in opposite directions to open/close, so will have different transform positions to specify. My solution for this was to assign a tag to each door, one which specifies the right door and one the left.
I did originally want to make it so that the doors would have more horizontal movement, and would only be stopped by the edges of the cabinet and the handle on the other door (so essentially they would be able to overlap almost completely), but doing this proved to be more complicated.
The coordinates of the edges of the cabinet would stay the same, but the position of where the handle on each door is could be constantly changing, so couldn;t be hard coded. Instead I tried adding more colliders with rigidbodies to the edges of the doors, or having a second transform component to track, but neither of these worked, causing the doors to clip completely through eachother.
To keep things simple, I decided to make each door only open about halfway (so they can overlap nicely in the middle), which still gives the player a column of space on either side in which we can put objects for them to fetch.
To keep things simple, I decided to make each door only open about halfway (so they can overlap nicely in the middle), which still gives the player a column of space on either side in which we can put objects for them to fetch.
Now that we have some original art assets in the game, it is starting to take shape. I am gradually implementing more and more features, such as more UI, update sprites and textures, and the remaining core mechanics. Soon we should be able to have people test what we have of the level so far, and we can think about incorporating their feedback going forward.
Laura Alford