Casey Descoteaux
Programmer
Thomas College Undergrad; 2019
Major: Computer Science
What made you want to join this project?:
I wanted to join this project because I had some exposure to game design and game creation in Unity after taking the Game Design 1 course. In that course I really enjoyed taking a concept and being given the creative liberty to find a solution and I saw this project as an opportunity to continue that.
By the end of this semester I would really like to see a functional prototype of all of the areas of the game that we have discussed up to this point. Having a working prototype will give everyone involved a great sense of accomplishment since producing a prototype of a game is a huge milestone, especially for such a small team in a sixteen week time-frame.
During my time in this project I would like to experience what it is like to work as a programmer in a real world work situation when it comes to collaboration and the expression of different ideas. I would like to obtain different ways to think through complex coding problems as well as make my suggestions public to everyone so we all benefit from each other.
In the next ten years I would like to see this project go through to completion and know that it is being used in classrooms to teach the standards we set out to demonstrate using the Titanic and its story. I also hope that this project continues to adapt to the improvements made to AR as the technology becomes more prevalent.
1/7/18 - 1/13/18 Recap
ReplyDeleteThis week, with the addition of a new programmer, we had a programmer meeting where everyone was given a task for the next week. After giving Wade what I had for the inventory, I went back to the task of syncing the game messages, the player location, and the game clock. After trying to accomplish this a few different ways I can get the location and the messages to work together but the time is proving to be a more difficult task. My first project for the coming week is to get a working version of this and add it to my Titanic Proving Grounds test scene so that it can be viewed by everyone and eventually refined and incorporated into the main project.
~Casey
This comment has been removed by the author.
ReplyDelete1/28 - 2/3 (and prior) Recap
ReplyDeleteFor the past couple of weeks I have been going back and forth with different versions of a message displaying system that will give the player tasks depending on the time and location they are currently in. This system took multiple refinements because, on a small scale, my first full working version performed fine but would not function consistently when brought to a larger scale (more messages). After a few hours of debugging using Boolean variables, to test how far into the code the game would get, I had to do some research to find the best way to solve my problem. I found out that the problem only happened on larger scale projects because the method I used required more time to compute than I was able to give it. With only a couple of messages in my initial test it worked fine but when I upped the number of message to only 5, it would not work consistently. Luckily I was able to find a solution for my problem that takes less computation time meaning more message can be put into the system and get perfect results.
I have also been working on a simplistic day night cycle. The reason for it being simplistic is so that it will run with optimal performance on a tablet. My first working version of this was to make a simple animation. Although this method did work, the problem was that it would be difficult to line up the animation to the in game time (which runs faster than "real time"). My next approach to this was to write a script that updated the rotation of the sun by .25 degrees every in game minute. This may seem like a random number to adjust the rotation by but there is a reason for this number... there are 24 hours in a day each with 60 minutes which means that there are 1,440 minutes in a day. There are 360 degrees in a full rotation. 360/1,440 = .25. With a rotation of .25 degrees per minute the sun will perform a full orbit in 24 in game hours. To go along with the sun, I also wrote a script that will turn lights on and off based on the game time to act as streetlights.
In the final project, there is going to be a clock tower on the Cherbourg Terminal so we need a way to get the hands on that clock to move with the game time. I took on this project as well, and it turned out to be more difficult that I thought. Shapes in Unity only rotate at the center of the object which is a problem for creating clock hands since clock hands rotate on their ends. To overcome this obstacle I had to learn about gizmos, a class in unity that allows you to create a pivot point. Just putting the gizmo on the clock hands was not enough however because the clock hand will still rotate on the center. I had to combine the gizmo and the clock hands into a custom game object and make the gizmo move which, in turn, moved the clock hand since the clock hand is tied to the gizmo.
Wade and I did some work creating the baseline for a scheduling system. Wade created some nodes in the test scene which we put into an array. A game object (in this case a cube) was in the scene as well and was tasked with moving to one of nodes at a given time. Once we accomplished this we adjusted the code to allow the cube to rotate while in the node and stop rotating when exiting the node at another given time. The rotation is a placeholder for a character animation which will be implemented once we have NPC models and NPC animations. At this point I am waiting for a finalized schedule of times and which people the different schedules are relevant to.
Other miscellaneous scripts, organization, and optimizations have also been made but these are some of the bigger projects from the past 3 weeks.
This week I finished adjusting the sun script so that the initial sun position changes to accommodate for the starting time. I also worked on the Morse Code puzzle. I split the puzzle into different stages...
ReplyDelete1) Get a Cube to Flash
My first step was to get the cube used as the light to flash a given color. I did not worry about specific letters or messages at this point, just getting the flashing function to work.
2) Get Letter Codes Into the System
After I figured out how to get the cube to flash a color, I found all of the dot/line codes for all of the letters and added those into the system. I then tested grabbing one of the letters and having the cube flash the code of that letter.
3) Insert a Message
My third step was to insert a message into an array. The message had a time associated with it as well as the message itself. When the time was right, the message would be broken down into the characters and each character broken down into its code.
Step 3 is where I ran into a snag. Since I had the code from stages 1 and 2 in the script, there was some code that I though would be helpful even though it turned out to be clutter. The longer I tried to get the system to work the messier the script became. Eventually I took a mental note of what I had learned and started a new script. Once I did this I used what I had learned from my initial script and made a cleaner, easier to follow script that now works as intended. Now that the system works I want to add more messages to test that the script transitions from message to message as indented as well.
Last week I enhanced the Morse Code system so that not only does an object blink depending on if a dot or a line is being sent, I also synced it with a moving telegraph. The telegraph in the scene moves and when it makes contact with the a pedestal, the top of the pedestal flashes either the dot or line color then returns to it's default color. This required some more scripts to be added and a lot of trial and error but now the system works as expected. Along with this I made the first steps in allowing the payer to create their own messages and send them through to the telegraph. Currently, the players are able to create their own messages but I am having trouble getting the messages to make the telegraph move. I can have the player's dot/line message displayed in text but much more work has to be done in order to get this to work entirely as expected. In order to get this far I had to do the following...
ReplyDeleteMake three buttons...
1) A Button Labeled Dot - When pushed, "dot" is added to the player's message code
2) A Button Labeled Line - When pushed, "line" is added to the player's message code
3) A Button Labeled Submit Message - When pushed, finalizes the player's custom dot/line message and prints it out to the console.
This project took up the majority of my time this week. Next week I am going to finish this project and get it to work as expected, other assignments will come later in the week.
During the February break I completed the Morse Code system so that the telegraph conveys custom messages created by the player in addition to conveying preset messages. In order to show how I expanded on what I described in my last blog post, I fill format the steps in a similar way.
ReplyDeleteTo accomplish iteration two of the Morse Code system I put a series of buttons on the screen...
1) A Button Labeled Dot - When pushed, "dot" is added to the custom letter code
2) A Button Labeled Line - When pushed, "line" is added to the custom letter code
3) A Button Labeled Submit Letter - When pushed, the code inputted by the player pushing the dot and line buttons is translated to it's letter and added to a string
4) A Button Labeled Submit Message - When pushed, the string of characters made up of all of the codes from player input is sent through the telegraph moving script.
5) A Button Labeled Letter Table - When pushed, this button toggles a text field that displays all of the letters next to their dot/line codes for the player to reference.
One aspect that will have to be included at a later date is disabling the buttons when a message is being sent through the telegraph to avoid overloading the system.
Another task I accomplished during the break was a simple representation of having cubes (to be replaced with water) change to different shades of blue depending on the amount of heat it is exposed to. Currently, for the sake of testing, there are only three water levels but the system can be scaled to any number of temperatures. In my test I have one cube set to "hot", the cube touching the hot cube is set to "warm" through a script, and the cube touching the warm cube is set to "cool" through the same script. As long as at least one cube is preset to the desired temperature (in this case either hot, warm, or cool) the other cubes will change their color during run-time based on the temperature of the cube they are touching.
This is an update from the past two weeks. I decided not to write a blog update last week because I was only in the beginning stages of the projects I was working on so there was not a lot to discuss at the time. This week I made substantially more progress on the projects. The projects I worked on were...
ReplyDelete1) Working on moving water molecules for the boiler room scene.
2) Working on animator controllers that allow the two NPCs in the proving grounds to walk to different nodes and perform animations before returning to their idle states.
The water molecules bouncing in a box turned into a more frustrating process that I would have liked because no matter what I seemed to try, the molecules would always loose their momentum whenever they either collided with each other or with more than one wall (like a corner where three walls converge). To combat this issue I created some simple animations that make the molecules appear as if they are bouncing randomly when they are really following an artificial bouncing pattern.
The animations for the NPCs was based on a scheduling system designed a few weeks ago with some additions I made over the weeks. With the base scheduling system, the NPCs would slide (not walk) to their event node to perform an animation. Once the animation was over however, they stayed fixed in the end state of the animation before sliding to the next node. The code that I added now allows the NPCs to stand idle when they are not doing anything, and loop a walking animation while going from one node to another before performing the animations attacked to the event nodes. Some work can still be done to make the animation transitions a little more smooth but do not look too bad currently so I am going to come back to this refinement at a later date.