REAL DEV LOG 3 — Saving and first rooms

 

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.

 

Unity_2017-03-30_10-57-16Saving 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 :

  1. The name of the event (That we are going to put in the list)
  2. The type of event
  3. 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.

Unity_2017-03-30_12-11-37.png

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.

Area events

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

  1. Door unlocking/locking

Unity_2017-03-30_12-45-13.png

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

Unity_2017-03-30_12-45-25.png

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

Unity_2017-03-30_12-45-38.png

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

Unity_2017-03-30_12-46-46.png

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

Unity_2017-03-30_12-46-38.png

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.

 

3D Works

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 :

 

Unity_2017-03-30_12-52-56.png

 

Unity_2017-03-30_12-53-36.png

 

Unity_2017-03-30_12-53-47.png

 

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.

Advertisements

One thought on “REAL DEV LOG 3 — Saving and first rooms

  1. […] Three weeks after the last update, a lot has been done on the style of the house the work was focused on, and a better options menu. We don’t have a lot to showcase except some screenshots and the explanation of the new options menu. […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s