Three weeks ago we talked about the fact that everything needed to engage into level designing was a working saving systems, and some area to triggers certains event. Everything has been done smoothly for the last three weeks and the development is now engaging into it’s first true levels rather than just a test room.
So for three weeks, work has been focused on these three main things.
Saving system and events
The fact that no lifespan has been completely set for this game can cause a bit of headache. Do I really need a complete save system or the lifespan is going to be so small that it will be not necessary ?
Regardless of the answer a save system is always a good things to put in place pretty soon in the development, even if the system will not be used in the end, at least the fact that it’s there would be a good thing for two reasons :
- You can modify it then reuse it in later projects
- You can use it for other things than just saving the player progress.
The save system used in the project has for now two functions. Saving the player progress, inventory, position, and scene in the game. The second is to check if an event has been triggered when entering in a new scene.
Why did this system exist ? Well if the final game has a lot of scenes in it, it’s better to put every events that happened in a list (That we are going to fetch in the save file every time the game loads), then check every dynamic event in the scene and tell them “This exist in my list of event happened, so trigger the final events without the intermediate”
How does this work exactly ? Without going into the details of programmation, every event has three parameters :
- The name of the event (That we are going to put in the list)
- The type of event
- The time of the transition or the time that is going to pass until the event will trigger (This depends on the type of event)
When the timer (3) is going to be done, the name of the event is going to be put in the list like this :
[SceneName] + EventName
This ensure that the same name can be used across scenes without causing any problems. If we would only save the EventName, this would cause problems if we used the same name in another scene. The game would recognize that the second event is triggered even though the first event only has been triggered.
Of course the same problem can occur if the same name is used in the same scene, but that can also be used at our advantage. For example if two types of events are triggered at the same time, we can give the same names to both of these events and create the illusion that it’s just one single event rather than two.
And to avoid these kinds of problems if it’s not voluntary, a custom inspector script can take care of that for us and inform us that two events have the same name in a scene.
And every time the scene changes, every GameObject with the tag associate with interaction will check if the name of their event is on the list of events. This seems unoptimized, but this is a good compromise since everything is happening during the start of the scene, will the screen is still black so it can be interpreted as an additional loading time.
We talked a bit about the events and how these are working. Now for the area more specifically.
The script we used has four fixed parameters, and several other parameters depending on the type of events. The four fixed parameters are :
- The type of the event
- A timer before the event is going to be triggered
- A boolean (true/false) if the event is unique (Cannot be repeated)
- A boolean to ask if the script should be destroyed after triggering.
Every area can accept five types of events as of now
The name says it all. For this type, only a GameObject is asked. The GameObject must have a “Door controller” script apply to it, if not Unity will send an error and nothing will be done except sending endless warning messages.
2. Activation of a GameObject
Once again this type wants a GameObject, but this time any GameObject is acceptable, since it activates the object. If it’s not a unique event when the player will get out of the area, the GameObject will deactivate itself once again.
3. Light color change
This type wants two things : The color at the start, and the color at the end. It also wants to target light. This type should always be timed to have a smooth transition. If not, the light will change it’s color immediately without any transition which can seem abrupt.
4. Scene changer
This type just wants a string, when the player will step in the area, the scene will change after the timer is done ticking.
5. Area changer
This type change the room in which the player is in. It take a GameObject, the position of this game object will be used to determine where the player should be moved to.
Of course every single one of these scripts, proprieties and how they work is bound to change to have a better workflow in the end. But right now these are how the prototype work.
Lastly these weeks brought 3D work and the general style of the game. Better than a lot of words, here are some screenshots in engine :
Of course texturing is mostly not done yet, but the general style is there : Only plain colour. The reason is simple. The game treats of a literal memory of a character. When you remember something you don’t remember every single details on the fabric. Only plain colour and some pattern at best.
It’s also a way to cut the work in half since texturing is very hard and the development needs to be focus on other aspects. Lighting needs to have some work put into it too, but it will come when the first house will be done.
In the meantime be sure to comments or ask any questions. It will be answered in time. Feel free to send a mail too if you want to contact us at ArealSnake@gmail.com
Next update next month ! Have a good day.