Week #12: A late goodbye

Fellow readers,

This report is likely to be my last post on this blog. The writing experience lasted for approximately three months of my life. Just a few days back on the 26th of May, we had the first fully online MOJO event in history; the day was overall a joy. Our team participation involved three components. See players testing our game and giving us direct feedback about their experience. Playtesting other teams' games and watching online streams where the developers and artists of each team talked about their developing experience, their goals, and what they would have done differently.

Our interview was set for 12:30PM, and overall, the conversation went well. We answered the questions honestly and talked about our game very naturally. The only unfortunate part, as mentioned by other colleagues on their blog posts, was that the wrong trailers and gameplay videos were displayed on the event. The trailer presented was a 720p initial draft made by Sofia Santos, and the final trailer was way better. In this trailer, the sound was mastered. The image quality was 1080p, and there were subtitles for people who had trouble understanding spoken English and included some hero shots of our game, including levels that were not used in the event. This happened because of me. With the hurry to deliver everything by the end of the 25th of May, I accidentally submitted the trailer we had stored on GitHub. Instead, I should have provided the version I had stored locally, which could not be uploaded to GitHub because it was larger than 100MB. However, when it comes to the wrong gameplay trailer being displayed, it was the streamers' error. We submitted a way better version at approximately 10:30AM and signaled this at least twice throughout the morning. The improved version better displayed how the game should be played and enjoyed, instead of being a rough speed-run throughout the level. Alas, we are all human. If you are curious you can check the videos below. The first is the final game-play trailer and the second is the final presentation trailer!

Overall, this course and the MOJO event made me learn a lot about game development. Although it gave me lots of hard work and ultimately set me back on my thesis progress, I do not regret it for a single second. I even enlisted as a volunteer for Game Dev Técnico. Wink Wink. I also got to make new friends in other universities, and I am not regularly going out with one of them! For lack of better words, this was a 'game' changing experience! See what happens when game development joins together an engineer and an artist:

Figure 1 - Francisco and Sofia find happiness in each others' company

I wish you all the best,

See you next time.

Week #11: final details

As we get to the finish line, it's time to finalize the dialogue. I wrote two dialogue trees: one for the General and other for the IT Guy. The first one needs a more defensive type of approach since the General is looking for suspicious behavior through all of the conversation and a wrong move gets you caught. The second one, it's a lot more exploratory: it's about engaging and guiding conversations for topics that are useful to the player. 

I found difficult to write dialogues since it's not really my strong suit but the final dialogue trees get the job done. 

Now... for the MOJO!

Weak #11: re-creating the dialogue system, more HUD, better information.

Figure 1 - Tutorial level, designed by Rafael Ribeiro

Squad...

The road so far was hard and full of perils, but the end boss is yet to be defeated. As MOJO approaches, we still need to create two exciting and playable levels, including a tutorial so that players can experiment with our game one "final" time. After that, we need to create a game-play trailer that is about 8 minutes long. But that's what we need to accomplish in the next 24 hours.

What I've done this week however, is another story.

I had to recreate the dialogue system, which was outdated, malfunctioning in a few aspects. Still, the most notable change was in the interface and how the player engages in the selection. The number of possible choices is still limited to three dialogue options. However, it is no longer required that the tree has precisely three possibilities. This should make the dialogue system less linear, and perhaps more exciting. The underlying system can easily be upgraded to have more choices. Still, the HUD would be cluttery, hence the imposed restrictions. We went from a cycle and mouse click to, W A D keypress selection, or alternately using arrow navigation and press enter selection.

Figure 2 - New dialogue HUD example. Following artists specification.

I also created the credits, intro, and trailer scenes in the game using our art student, Sofia, products. I also used her posters on our propaganda poster prefabs.

Figure 3 - Propaganda posters, by Sofia Santos. There is no better Art  collaborator.

I created a system that allows the user to select between game-pad and mouse + keyboard HUD at any time by accessing the pause menu or the main menu. The goal is to help the user better understand what he is doing. On that note, we now use icons to specify key-binds within the game instead of hardcoded strings. See Figure 2. Ideally, I would have liked for this to be dynamic concerning the "last used" device. Unfortunately, with the way we implemented the input controls, this would not be easily achieved in short notice.

Finally, I created a tutorial HUD and system that allows Rafael to give instructions to the player has he navigates the tutorial corridor, shown in Figure 1.

I could go on, but I have the stuff to do.

See you in two days.

Week #10: Heatmaps, Maptracing and lots of HUD.

Figure 1 - Heatmap and Maptracer combined

Hello fellow followers,

Figure 2 - A small part of the new HUD.

Throughout the 10th week I have been busy constructing Heat-maps and Map Tracing to use during the play-tests of the game during MOJO. Once again I did refactoring to improve the performance of the game but my best work so far this week was to work directly with the arts 
student Sofia, to integrate her HUD and menu on our scripts. As well as creating with her a custom cursor and adding it to our game. She also made one .exe logo for us.

Figure 3 - Game Over Screen for defeat case. Victory is similar.

I also implemented a loading screen to make smoother transitions and which asks the player not to close the game while we write log files to disk and upload them to the cloud as backup. Apart from these I haven't done much else. This week's post has been short and there is not much more to say, mostly because doing the heat map and the map tracing took up most of my time.

See you soon at Mojo!

Figure 4 - Uploads to cloud, checked.

Week #10: taking some time off

As the semestre comes to an end, I've taken the last week to focus on other projects and other responsibilities. Living in 2020 is harder than living inside '2036'.

Tomorrow, I'll create the overview of the narrative screen necessary to expose the history. I've talked about it with one of our artist and everything is already in motion.

May we meet next week, the last week of development before the MOJO event.

Week #9: More dots!

Figure 1 - New Overlay HUD, New Appreciatable Art, New Background Blur.

Hello gang,

I feel like I've been hit by a train. The development efforts really skyrocketed this week. I am so tired; I will keep it short. I've corrected an endless amount of bugs in the interaction system, in the pause game mechanic, in the HUD. That was the part that came naturally to me, as I am usually very proficient at fixing last-minute issues. The hard part included redesigning the Tooltiping System to allow more use cases, making it more flexible and more informative. I then connected the tool-tip system with Rafael's AI, so that the player knows he is being detected without using weird lanterns, even if the threat is not in his line of sight. Implementing an enter in closet mechanic, so the player has more places to hide, apart from usual WASD collider abusing. Applying a hug the wall mechanic, which was supposed to be a quick time event to perform last-second detection saving, but after extensive testing ended up being the traditional stuff that can be performed anywhere, a hit box with cover tag is available. I also brainstormed with Rafael, ways of improving his AI, which is right now still a work in progress. Cleaned up old code, increased performance on existing ones. Cleaning also included making ready-to-use prefabs both for decorative as well as functional purposes.

Figure 2 - New Cover Mechanic

Figure 3 - New Detection Hints

Many other things I do not remember right now. For example, a fade screen animation, to compensate for the fact that player changing clothes is just an instantaneous model switch.  Another blur background animation to be used along with newly created interactable classes that allow the player to appreciate art posters, read books, among others.
That's "basically" it — bye guys.

Figure 4 - More prefabs, more prefabs...

Week #9: the playtesting plan

As we approach the MOJO day, the time to think about our play test plan has come. After discussing what we needed to know about the player's experience with the game, we have concluded that some particular questions need answering:

LEVEL 1

• Does the player fear all enemies equally? Are the enemies' speed, detection range and patrolling style balanced?

As we focused on the walking guard enemy more, the question about how danger the drones and cameras are perceived lingers. 

How: by controlling the time the player takes on each enemies' section and how much the player uses the crouching and cover mechanic.

• Does it take time for the player to understand how to get through enemies

We need to inspect if the level is designed (or not) in a way that leads the player to plan a strategy rather than just throwing themselves into whichever path they instinctively choose. 

How: by controlling how long the player stays in the initial (safe) section before engaging with the level.  

• Are both paths presented on level 1 equally enticing? 

The first level is divided in two possible paths: one with walking guards and other with CCTVs. We need to see if the players find both equally challenging at first glance.

How: by observing which path each player chooses.

• How do experienced players approach the cover mechanic?

By previous testing with our focus group, we came to the conclusion that experienced players didn't feel the need to use the cover mechanic. With a revised model for that mechanic, we need to see how many players use it during this level. 

How: by marking where and how long the players stay in cover.

• Do players feel the need to backtrack? 

We find important in a stealth game to give to the player's strategy validity at all times. The player shouldn't feel like they chose a "wrong option" and should always feel they can progress on the path they are in. 

How: by making a map of player's movement. 

LEVEL 2

• Does the path chosen on level 1 affect the success on level 2?

As stated in the progression document, the choice of path taken on level 1 should affect how prepared the player is on level 2. We want to see if the players that chose the guard enemy have a higher success rate on level 2.

How: by seeing if the players that chose the CCTV path take longer to figure out how the guards move on the level.

• Does the player use objects as distractions on first try?

We want to see if players understand that to get through the level they will have to use distractions to get guards off a fixed location/path. 

How: by controlling how many players die in the level before they interact with objects.

• How long does the player stay put?

Level 2 needs more observation. Without seeing where the guards are in the room, the player won't be able to understand how to get to the other side. We need to check if players go about the level that way.

How: by controlling how many players die in the level before they interact with objects.

• Does the player use hide mechanic? 

After implementing the "hide inside object" mechanic, we had doubts about if the players would integrate it on their strategy.

How: by checking how many players chose to hide inside the closet on their way to the objective point.

CONTEXT DATA

Data about which platform the player uses (PC vs MAC), the screen size of their device and what input device they choose to play the game with (keyboard and mouse vs controller) could inform choices of implementation going forward. 

Tomorrow I'll be writing the game experience and game engagement questionnaires.

On the playtest experience, we plan to have  a"Think Aloud" concurrent feedback (when possible) to see how players react to the game as they're playing it.

As a side-note, a great video about the importance of playtesting and the right way to approach this decisive phase of the project:

Week #8: Fix, Improve, Repeat

Personally, this week has been focused on improving existing systems and fixing known issues. I adjusted the reusability of the interactable systems. I applied it to dialogue characters so that they are triggered when the player desires and not when he accidentally passes through a collider somewhere on the scene. After making talking NPC's part of the interactable system, I realized the outline animations had a bug. The package we used and previously adapted from the asset store did not support objects using multiple composed mesh renderers. After some reverse engineering, I found an easy and effective solution that required no hammering, and now the outline works with complex NPC Humanoid models as well as it does with simple geometries like cubes. The code could be more efficient, but when I tried fixing that issue, I started suffering from null pointer exceptions. I am aware of unity's lifecycle system, and I know how to use Awake, Start, etc.. Still, somehow a list I saw being populated in Start method with desired non-null objects using breakpoints and Rider's debugger became empty when accessed later. No big deal, the current code works, it's not as efficient or elegant as I would like, but works and does not cause any performance issues. I might look into this at some other point in time.

Figure 1 - Outlining Humanoids and other complex Shapes

Other tasks included extending the menu system with the capability of unlocking Levels as the player progresses through them in-game. Meaning that he can only access Level 2 if he completes Level 1, and so on. This mechanism can be bypassed by manually altering the JSON file in the streaming assets folder for testing. Still concerning the menu, it now includes an option to modify the sensibility using a slider to the liking of the player. Some play testers complained about how jaggery and fast the free look was, but with this functionality, it should no longer be an issue. Player preferences are kept through his sessions, and he does not need to customize his game every time he executes it.

Figure 2 - Better tool-tips

Other UI improvements include presenting the key the player should press to interact with or grab an item that is highlighted in the world. While this is not an essential feature for players who dedicate some time to the game, as they start associating the keys to each action, newer players will feel lost and did so in the play tests, if they are not presented the key binds during their session. 

Figure 3 - Before Exchanging the Player Model

Figure 4 - Exchanged Player Model

Finally, I implemented one required feature tied with the core of the game. Which is allowing the player to select and change is disguise. Two solutions were available. Exchange the skin mesh renderers, or change the player model at runtime. The first approach yields better results but has many prerequisites that the team is not capable of fulfilling, e.g., clothes would need to be explicitly designed for the models, which is not possible since we are using mixamo models and they don't bring any replaceable clothes. I still tried to make them work by reusing clothes from different models, but this solution did not work very well, because not all dresses were made alike. By this time, the 3D Artist Humberto replied to my consultation and agreed that the second approach was more comfortable and faster to implement for both of us. Hence, right now, exchanging clothes means that we are changing the player model, which has the downside of having a different body shape and a different face. This, however, should not be an issue once we start using our own models instead of free ones downloaded from the web.

Week #8: time for progression!

In '2036' the player is going through 3 levels of out 5 developed levels:

Level 1

Setting: in front of the Forte do Bom Sucesso, dozens of guards, CCTV and drones patrol around the building, making sure no intruder can get in the party.Since Forte do Bom Sucesso became a military base again, the surrounding of the building has been filled with military vehicles and crates.

Enemies: guards, drones, CCTV.

Objective: get through the patrolled-filled area without being detected to get to a back door or the further side of the Forte do Bom Sucesso.

Mechanics: walk, crouch, run, hide in cover.

Level failed: character 1 is detected by enemy and is arrested.

Level success: character 1 gets to the door, character 2 opens the door from the inside.

Level 2

Setting: character 2 sends character 1 to a locker room where character 2 has hidden some disguises. To get to the locker room, character 1 has to get through a barracks with some military men on fixed position inside.

Enemies: guards

Mechanics: walk, crouch, interact with object.

Objective: interacting with objects to distract the fixed guards and clear the path to the locker room.

Level failed: character 1 is detected by enemy and is arrested.

Level success: character 1 gets to the locker room and finds the locker of character 2. Inside there’s 3 outfits: guard, catering staff and formal sergeant outfit.

Level 2 (alternative)

Setting: character 1 was arrested with the usb drive needed to complete the mission. Character 2, an infiltered guard, now needs to complete the mission alone, starting by accessing the cells and taking the usb pen without raising suspicions.

Mechanics: walk, crouch, interact with object

Objective: interacting with objects to distract the fixed guards and clear the path to the locked cabinet where the usb drive is.

Level failed: character 2 is detected by enemy and is arrested (game over state)

Level success: character 2 gets the usb drive and now walks to the party where he’ll need to find a way to access the server room.

Final level

Setting: character 1 has infiltrated the party with a disguise and needs to access the server room. Beforehand, the team knew there were two key cards that could access the server room: one was with a designated IT guard that needed to give manual input as a safety measure and the second one was a backup in the Marechal’s office.

Enemies: guards

Mechanics: dialogue

Objective: through dialogue, find a way to get one key card, access the server room and insert the usb drive to get the border’s defence down. Character 2 will assist by providing information he gathers.

Level failed: character 1 raised suspicion with intrusive dialogue options, the Marechal triggered code red, locking down the server room (game over state).

Level success: character 1 gets a key card, gets to the server room with character 2’s help and shuts down the servers.

Final level (alternative)

Setting: character 1 has been arrested and character 2 needs to access the server room. Beforehand, the team knew there were two key cards that could access the server room: one was with a designated IT guard that needed to give manual input as a safety measure and the second one was a backup in the Marechal’s office.

Enemies: guards

Mechanics: dialogue

Objective:  through dialogue, find a way to get one key card, access the server room and insert the usb drive to get the border’s defence down.

Level failed: character 2 raised suspicion with intrusive dialogue options, the Marechal triggered code red, locking down the server room.

Level success: character 2 gets a key card, gets to the server room and shuts down the servers.

____________________________________________________________

The focus has been writing the narrative beats: the initial narrative screen with exposition of the setting the player is put on and the final narrative screen depending on the mission success, short biography for the main characters (two rebels and the president) and dialogue for the final mission. Making environmental storytelling elements such as posters and letters is the step after.