#ctect709

25/10/2021 Monday

Colour Editor UI

Today I worked on implementing UI for the colour changer. I first started by creating 5 colour wheels. The colour wheel types are red, blue, green, orange, and white. The red to orange wheels have 12 colour buttons within them, while the white contains only 6. I then made 4 buttons to control which body part is being edited. These are the primary, secondary, accent and emission. The accent was removed later as it’s changes weren’t visible on the BroBot model, and the emission was renamed to lights. Lastly, I made the BroBot parts change colour based on the colour button selected.

Gif of colour changer:

26/10/2021 Tuesday:

Improved Menus

I spent today improving on the buttons and menus. I firstly started by adding back in the loading screen we had made in semester one. I changed the text prompt to “press start on controller or space on keyboard”. I changed it to this as I plan to edit the player spawn to use these inputs. I also plan on only allowing players to spawn in on the main menu screen.

I then set up functionality between the different menus. Within the main menu there is the play, paint job (colour editor), and quit buttons. The play button loads the player into the levels. The paint job button transitions the user into the paint jobs menu. The quit button exits the application. I improved the BroBots title text and added blinking text saying the required button to spawn in a second player.

Within the paint job menu, I added a return to menu button. This button transitions the user back to the main menu. I also added a “paint job” title text to this menu and copied over the spawn player prompt from the main menu.

Button Effects

I created button effects for each word button, such as resume, quit, etc. These effects are a grow, shrink, and click effect. The grow makes the button bigger and brighter when selected. The shrink reduces the size and dims the button when deselected. The click shrinks and then enlarges the button creating a clicking effect.

27/10/2021 Wednesday:

Crate Button

I started today by creating a crate spawning system for Ashton’s button asset. It works similarly to the buttons in semester one. When a player enters a trigger collider over the button, a pressing in animation will play for the button followed by a crate being spawned. Upon the player leaving the button an animation for the button lifting out will play.

The button required some tweaking as initially if one player was on it and then a second got on, the button would press again. To fix this I had to create two booleans that check if players 1 or 2 are already on the button and if they cancel any new button presses until all players have left the button.

Gif of crate button:

Dead Zone

I then created a dead zone and respawn system. I made it so that on entering an invisible collider under the map the player's manager and mesh would be disabled. I then set it up so that after 1 second the player would be moved to a respawn point, with their player-manager and mesh enabled.

I set-up 4 respawn points for the 4 levels that will be in the prototype. The dead zone uses a trigger surrounding each respawn point to determine which respawn area to use. You can only trigger a respawn point once, this disables potential backtracking ruining the player spawners.

Gif of dead zones:

Updated Player Spawner

I redesigned the player spawn system. I had to redesign this system to work only in the menu and to allow colours picked in the paint job menu to persist in the game scene. Firstly, I made start and space spawn the players into the project. This was because pressing A on Xbox, X on PlayStation, or enter on keyboard would also press the menu buttons.

Next, I worked to make colours picked in the paint job menu persist between the menu and game scenes. I originally made it so that the player mesh and input provider would spawn on a persistent gameobject (does not get destroyed between scene loads). Then when loading into the game I would spawn in proper players based on the number of controllers recorded in the menu scene. I thought this was a decent approach, but it proved to be extremely difficult assigning the players in the scenes to their appropriate controls. The difficulty came from having to assign the players without being able to use device input.

While trying to get the previous approach to work I realized I could just spawn in the proper player and have them persist between scenes. Then all I’d have to do is disable their player-manager and cameras when in the menu and enable them in the levels. This worked and was simple enough to set up, only requiring a few edits to properly disable and enable the players. With this finished the menu system was functional and finished.

Gif of finished menu:

28/10/2021 Thursday:

Target Button

Today I started by creating the functionality for the target buttons. The targets are used to activate disabled jump pads. Similarly, to the crate button, this target button has a pressing in animation. However, the idea for this is that the player has to fire a crate at the target, and it will then stay down. In order to do this, I set up a trigger collider in Infront of the target that when a crate enters will play the pressing in animation. It will stay pressed in and activate a close by jump pad. This jump pad is then used to get to a previously inaccessible area.

Gif of target button:

Button and Jump pad Lights

After getting the target button working, I realized the buttons and jump pad lack flare. They all have lights on them that I decided to turn on and off depending on the objects state. To do this I created a colour value that edits the brightness and colour of the light. It sets the lights to dull when inactive and then assigns them to bright when activated by a player.

Level 4

My last additions to this project for semester two was the creation of level 4 and a return to menu event. Since Ashton was handling the design of levels 1 through 3, he helped me to use and snap into place the correct assets. Ashton and I had previously brainstormed the levels and aimed to introduce one new element in each level. For level 4 I was tasked with introducing the magnet gloves interactions with magnetic walls.

I created gaps that the player can only cross using their magnetism on magnetic walls to pull them over the gap. There are two gaps in the beginning, the first being easy to cross and the second being more difficult. After that, to the left, there is a platform with a magnet wall that has a crate button spawner. To the right, there is a target and a jump pad that gets the player up to an area that returns them to the menu. This area is a trigger collider that requires every spawned player to enter, after they all enter the players are loaded back to the main menu screen.

Video of level 4: Watch from 3:48 to see level 4.

Completed the scene transition animation which looks amazing!

Increased Mozart emotional range

Finally completed tuesday (why has it taken my team this long to produce content?)

Video of existing demo of current build that I made for Michaela’s lecturer: https://l.messenger.com/l.php?u=https%3A%2F%2Fyoutu.be%2Fbo8eEvGnyeE&h=AT2rB6yhS8HYi75OXDrWy1ydPPBI-72mNcZ4hoUIx94BTqn4hcPVs2TBH4p1-HqQ6LRmcYkO9JYdl0_X8j08Ny6e-dK9hYQk8dZ7TDRkqHfzhbJowxfDe85GUMMRoLgfSE0fBQ7pM8o

Today we gathered our research and posted our work on the wall in studio. As a group we spent the whole afternoon discussing and analyzing the assumption we individually made supported by our research on what will Auckland be like in 2038 and whether or not public transport is still an issue. During the discussion everyone's prediction was extremely detailed and well thought out, so we decided to combine our ideas together. 

Through this it has lead us to our final prediction of Auckland 20 years from now there is likely a potential of Satellite town being built that consist of Central Business District (CBD) and residential area around Albany (North), Waitakere (West) and Manukau (South). Ports of Auckland will be moved to the Manukau Harbor in order to cope with the future freight. In the night there will be no people in the city, in the morning all the people will come from North, West and South area to the city. 

With the increase in population growth and high density in Auckland 2038,  transport is still a major issue and will only get worse over time. We also notice that tertiary student and staff is a large group of transport users so we will create a floating island near the harbor and take all the tertiary academic institute in the city over there to free up the traffic flow in major cbd and also re plan a new railway system to connect pretty much all of Auckland and new areas to improve public transport. 

Here is a google doc link to our research that lead us to our final prediction and concept idea.

 https://docs.google.com/document/d/193H3xmPGE-C5Dmvs9LJF_UlmpJtBQFSmG7uS66pB_GQ/edit?usp=sharing

At the same time we have also been thinking about what sort of creative technology tools to present our speculative future of Auckland and its improved public transport. We believe the best fit for this project is creating a short 3d animation with voice over to give an overview of our concept idea. 

Team Role has also been assigned:

Alan - Assistant 3d modeler and writer/editor 

Harry -  Main 3d modeler 

Sunny - Team leader, Working on Animation

At this stage, I want to create a guessing, parlor and party game which tightened up with my interactive hat. The game would encourage deductive & logic reasoning and creativity.

In the game, one player is chosen to be the Mad Hatter, who wears the hat. Rest players are the Guests. The Guests have to come up with a word (which it has to be a noun), write it down on a paper and stick it onto the front of Hatter’s hat (make sure the hatter doesn’t see the word). The hatter asks questions to guess the word on the hat.  which can be answered by the Guests with a simple “Yes” / “No” or “Sometimes.” Lying is not allowed in the game. If the Hatter guesses the correct answer, that the Hatter wins. If 10 questions are asked without a correct guess, then the Hatter loses. During the game, if the Hatter ask question which include the word in it, then the Hatter lose. 

For example, the word is “chair”, so if the Hatter asks “Is it bigger than a normal chair?”, then the Hatter lose. However, questions for confirming a guess doesn’t count, eg like “Is it a chair?”/”I guess the word on my hat is ‘chair’.”

When the Hatter loses the Hat lights up and make some sound in an unpleasant way; if the Hatter wins, the hat also lights up and make some happy sound.

“There was a table set out under a tree in front of the house, and the March Hare and the Hatter were having tea at it: a Dormouse was sitting between them, fast asleep, and the other two were using it as a cushion, resting their elbows on it, and the talking over its head. 'Very uncomfortable for the Dormouse,' thought Alice; 'only, as it's asleep, I suppose it doesn't mind.'

The table was a large one, but the three were all crowded together at one corner of it: 'No room! No room!' they cried out when they saw Alice coming. 'There's plenty of room!' said Alice indignantly, and she sat down in a large arm-chair at one end of the table.”