Indie Horror Game Starter Kit
Documentation
Overview
So far we’ve taken a broad look at all the elements that comprise this project. However, it is important to break down the project into parts to understand how each part works and they are interconnected.
To begin with, let’s take a look at the scene. First, the "Environment" object houses various 3D models that comprise the scene, such as walls, ceiling and floor tiles, windows, and more. Next, the "Light" objects houses the static in-game light sources, such as the ceiling lights. The primary light (located inside the main room) is connected to the lightswitch script, alongside with the light-switch 3D object. When the player interacts with the latter, the light is toggled. The light-switch object itself belongs to the "Interactable" object category. All interactable objects have the “interactable” script attached to them, which allows for these objects to be interacted with within a certain distance (which is defined in the “Cursor Manager” script). Besides the “Interactable” script, these objects also come with custom scripts that contain functions unique to them. For instance, the aforementioned light-switch object also has the “Lightswitch” script attached to it. When the player interacts with the object, the “Toggle Switch” function is invoked via the “Interactable” script from the latter.
Next, we have the “Game Manager” object. As mentioned before, this object contains core configuration scripts, which contains scripts which govern most of the in-game systems such as the invetory. When modifying your project, you will need to create your own custom scripts for your interactable objects, and modify the existing scripts to suit your project. However, most scripts attached to the game manager object are ready to be used without modifications. It is also worth mentioning that most of the scripts attached to the game manager object come pre-configured; with other objects linked to them. The bulk of these objects are either UI objects or prefabs. If you wish to modify the existing UI completely (removing or adding objects), you may be required to re-link the new objects to these scripts. Most of the linked fields are self-explanatory, but you are highly encouraged to explore the template scene and source code to understand the purpose of linking each object to these fields. Lastly, most keybindings can be configured via the scripts attached to this object, with the exception of some scripts like the “Movement” script which is attached to the player object instead.
The player object is one composed of four core parts. The parent object itself is the main body of the player, containing the collider and rigidbody used to movement. All movement scripts related to movement are attached to this main object. Under this parent object, we have the “Player Camera” object. This object is used as the main in-game camera, and is used to move the “head” of the player up and down (meanwhile movement on the X axis is performed by rotating the parent player object completely). Under the camera object we can find the “Right hand spawn point object”. This object is used by the “Spawn Points” list, under the “Inventory Manager” script, which, in turn, is attached to the “Game Manager” object. The spawn points allow for the inventory manager script to spawn objects when items are equipped. This is achieved via the “Items” list under the aforementioned script.
Underneath the camera object, we have a simple audio source (used by the Footsteps script for footsteps sounds), and the collision detector object. An additional audio source is also present, which is used to play “one shot” sounds by various scripts (such as the sound of equipping an item). The latter is placed at the tip of the player’s head and is specifically used to detect if the player is able to stand up while crouching. This object is utilized by the movement script, and when the player crouches, a ray is cast from the object upwards (at a distance which is equal to the standing height of the player minus the crouching height), to detect whether there are obstacles. If they are, the player cannot stand up.
Lastly, we have the Canvas object which contains the UI. Since we have already explored the existing UI windows. It is important to highlight once again that all UI buttons, images, and fields are connected with specific variables (such as those connected to script instances under the game manager). This means that any changes to the UI must be done with full understanding of the purpose that those elements serve. This also applies to the prefabs spawned within the scope of the UI. For example, if we take a look at our inventory object, we will notice that there is an empty object, dedicated to displaying the items available to the player. All available items are by default spawned by the “Inventory Manager” object, under the Items scroll view within the inventory (more specifically Items - Scroll View - Viewport - Content). The spawned items are essentially instances of the “UI Item Prefab” (from the prefabs folder). Taking a closer look at said prefab will reveal that it has three child objects (image, name, quantity). By default, the intory script accesses the children of this prefab (the aforementioned objects) in the exact order that they exist in within the hierarchy. This means that the script “knows” that the image object goes first, then the name object, and then the quantity object. It then assigned the item image name and quantity to those objects in that specific order. If you were to change that order, that would either lead to wrong values being displayed, or an error being shown (since these objects do not all share the same components). In order words, if you were to make changes to this prefab (beyond simple visual changes), you would also need to rewire the way that the “Inventory Manager” script assigns these objects. Thus, a good understanding of how the related scripts work is essential to make any modifications beyond superficial ones. Although this asset provides a framework for developing an indie project, it is important to understand that framework to make use of it.
Before proceeding with any modifications, you are encouraged to browse through the scripts which comprise the in-game systems. All scripts are well-commented and user-friendly, and are designed with ease of modification in mind.
Useful & Misc Information
1) Project Lighting: By default the demo project uses HDRP for project lighting. The package can be imported via the package manager window, and default lighting settings can be configured via Project Settings - Graphics - HDRP. In addition, you can configure scene-specific lights via the “Sky and Fog Global Volume” object. However, please keep in mind that this project does not focus on lighting, and all lighting on the demo scene is purely experimental.
2) Models: All models were made in blender for this project specifically. Again, these models are made solely for showcase purposes. However, feel free to use them if they suit your project.
3) Audio: All sounds used in the project are copy-right free sounds found on the web.