{"id":812,"date":"2025-05-10T19:45:04","date_gmt":"2025-05-10T19:45:04","guid":{"rendered":"https:\/\/sites.wsagames.com\/sl1c22\/?p=812"},"modified":"2025-09-30T10:39:17","modified_gmt":"2025-09-30T10:39:17","slug":"esc-key-system","status":"publish","type":"post","link":"https:\/\/sites.wsagames.com\/sl1c22\/2025\/05\/10\/esc-key-system\/","title":{"rendered":"Esc Key System"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

When I was trying to build the menu and inventory systems, I used a key-pressed function to toggle their appearance and disappearance. However, I encountered a problem: the new system shares the same layer as the game screen. Although the new system visually covers the game, the in-game items underneath can still be clicked through it.<\/p>\n\n\n\n

I realized that the issue occurred because my new system wasn\u2019t built on Unity\u2019s UI canvas. Since I don\u2019t know how to control everything through code, I could only rely on Fungus commands to achieve the effect I needed.<\/p>\n\n\n\n

Now that I\u2019ve completed all the tasks, I\u2019ve realized that I could have simply disabled the clickable areas of the game screen when a key is pressed. That would\u2019ve achieved the effect I wanted as well. However, when I was building the system, I chose to create a new view to act as a separate canvas.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Pressed Esc Key<\/strong><\/h2>\n\n\n\n
\n
\n

When the player presses the ESC key, Fungus executes this command.<\/p>\n<\/div>

\"\"<\/figure><\/div>\n<\/div>\n\n\n\n

By switching the player\u2019s view to another camera view, the menu system\u2019s interface no longer overlaps with the interactive elements of the main game screen, effectively preventing any unwanted interference between the two.<\/p>\n\n\n\n

Click Quit Button<\/strong><\/h2>\n\n\n\n
\n

When the player selects the “Quit” option, Fungus executes the command to exit the game.<\/p>\n<\/div>

\"\"<\/figure><\/div>\n\n\n\n

Click Back Button<\/strong><\/h2>\n\n\n\n

However, things get more complicated when the player wants to return to the game from the Esc menu. Since not every scene has only one game view, such as Scene: 3.2_Hallway and Scene: 3.2 Hallway, figuring out how to bring the player back to the exact view they were in before entering the Esc menu becomes a challenge.<\/p>\n\n\n\n

\n

Back button command in the scene which only has one view, for example, Scene: 2.2_Lobby<\/p>\n<\/div>

\"\"<\/figure><\/div>\n\n\n\n
\n

Back button command in the scene which only has one view, for example, Scene: 3.2_Hallway<\/p>\n<\/div>

\"\"<\/figure><\/div>\n\n\n\n

Another issue comes up when dealing with multiple views: if the player opens the Esc menu without activating any of the variables tied to a specific view, the system doesn\u2019t know which view to return to, making the logic more complicated. So I also had to add a fallback command that returns the player to the first view if none of the view-related variables had been triggered.<\/p>\n\n\n\n

Moreover, in the final scene, the Basement Scene, there are not only multiple views, but they\u2019re also divided into two groups based on the background. This makes the return logic even more complex.<\/p>\n\n\n\n

\n

Back button command in the Scene: 5.2_Basement<\/p>\n<\/div>

\"\"<\/figure><\/div>\n\n\n\n

I set up group-based variables and used them to track the last view the player passed through, so the system can determine which view to return to.<\/p>\n","protected":false},"excerpt":{"rendered":"

When I was trying to build the menu and inventory systems, I used a key-pressed function to toggle their appearance and disappearance. However, I encountered a problem: the new system shares the same layer as the game screen. Although the new system visually covers the game, the in-game items underneath can still be clicked through […]<\/p>\n","protected":false},"author":15,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[38,64,33],"tags":[],"class_list":["post-812","post","type-post","status-publish","format-standard","hentry","category-programing","category-systems-in-the-game","category-semester-2"],"_links":{"self":[{"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/posts\/812","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/comments?post=812"}],"version-history":[{"count":34,"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/posts\/812\/revisions"}],"predecessor-version":[{"id":1320,"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/posts\/812\/revisions\/1320"}],"wp:attachment":[{"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/media?parent=812"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/categories?post=812"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sites.wsagames.com\/sl1c22\/wp-json\/wp\/v2\/tags?post=812"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}