Don't break the build

As we approach Demo day, where we will show off Alternalien, I have been working to tweak every setting in the build so that it is as smooth and consistent as possible. Emil mentioned a few weeks ago that he hopes our team breaks the cycle of working on the build directly before we present.

I intend to take his advice. As build master, I will restrict access anyone has to the build 2 days before we present. Up until then, I only want the build to get polished and add in sounds with a few last minute sprites and animations that need to work.

Poor planning

Poor planning at the start of the semester led our team to the "crush time" feeling, the one of a "death march". We were unable to see how we had over-estimated our ability to create 3 biomes with multiple levels with the lack of experience on our team.

Had we decided from the beginning to simplify the game even more, the game would be much more polished and a lot smoother. Furthermore, going back to the team synergy, had we worked better together, we could have learned and accomplished much more with much less stress.

From the beginning, we should have encompassed Kaizen...and especially so when Emil wrote it on the board for us to make a point.

Adding Kaizen to our work ethic would ensure we accomplished more throughout the semester more efficiently.

Adding music to the build

Once we received the audio for the game, I put implemented the background music for the Main Menu, Level select, and base level. Playing with the background music makes the game seem more complete and it really sets in that the semester is almost over and we will no longer be working on Alternalien.

While importing, Crushers inspector items were missing. When punching, the game would fail and I was required to add the audio in, since it was a part of the coroutine.

Team bonding

If we do not succeed this semester, it will be because the team was too stubborn to put aside petty issues and work together to make our an environment one of fun and excellence and commitment. Ego and selfishness run rampant.

Emil sat us down and told us that we must get past this in order to succeed. In capstone, we have to work together. Personally, I agreed. Our team took turns around the room telling someone one good quality and one they should improve. Afterwards, Mike treated the team for dinner at Dave and Busters for bonding as an apology for his previous actions.  

There was not a prevalent effort for professionalism in the team and, with the way the program is set up, we should treat this class as we would our career. It will be our career if we learn and exert the effort it takes.

Hopefully, the team will step up and realize how much our futures are affected by who we know and what we experience here today.

Main Menu Finished

Once I finished the GUI and found correct placement and sizing for the buttons/font, I created the necessary scenes for each buttons and linked them to ensure they worked.

For the Alien Data and Personnel buttons, I created a png for the normal and plan to use the same GUI.skin.

Menu GUI

Once I watched a few videos on the GUI, I was relatively simple to make the menu GUI and implement it. My first try, I over-complicated the task and tried to put an extreme amount of detail which gave my a very ugly result.

Taking a step back, I found a good font and colors. I then created a simple black box and a green one for the hover and normal, switching the colors on hover.

Main Menu Script

Working on the main menu script was simply linking buttons to the scenes. At first, we considered using a pre - made button without text for the main menu, since no one in our class has experience with the UI. However, it was much more time and effort to create each button and use that technique.

The harder part was coding the skinned buttons to be an acceptable size no matter the screen size. The font size made it very hard to hard code in a specific number. Once I found the fontSize component, the menu script came together.

The New Build

Coming to terms that the old build was too messy to export all as one package was frustrating. Items were too scattered as there were too many people who had access to the build.

The build is more organized and runs into less problems once I limited the access of the build to Mike and I alone. While I had originally wanted to have a separate branch for the devs, with time running so short and certain imports being difficult, I have been left to just importing the new items into the new build myself and referencing the old build when something is not as it should be.

Obligatory Build Master

On November 10th, our team had a dispute in which I was left as Build Master. At the beginning of the semester, I decided not to take on leadership roles so that I may learn a lot of programming in a short amount of time. In addition, I needed time to come to terms with personal issues which I knew would come in the way of being an effective leader.

Yet as the semester came to an end, with a very messy build, I became Build Master and was forced to step up. While the terms in which I was made to do so were unprofessional and unnecessary, I took the role in order to finish the semester out. I decided to accept the role with as much grace as I could.

Piston Movement

For the piston movement, I originally thought of something with trigger box colliders, but I really enjoyed working with coroutines and decided to use it for the movement. While finding the perfect numbers was a little tricky, the movement worked the way I wanted it to:

We ended up using Mike's script using box colliders for the movement.

Working 2D vs 3D

For a while, the fireballs/iceballs thrown by temper were not setting off a trigger that was set on top of the geysers for the arctic wasteland. Mike Anderson and I worked on it one day in class as Mike could not make it that day. The balls were clones. We had to have the originals set in the scene (out of view) and we had to set the colliders as triggers. Looking in 3D, we could tell the balls were too far away in the z position.

Working in 2D, It is hard to tell how far away an object is in the z position. Toggling between 3D and 2D can help set up a 2D environment in an aesthetically pleasing way while making sure it is functional as well. 

Draw Bridge

Working on the draw bridge, I had the movement bound to keys in order to test. While I tested the object in a scene, I didn't notice until later that the pivot point did not stay on the far right as it was supposed to and so the bridge has a gap from the original position. To change that, I am going to translate the object downward as it rotates up and vice versa.

Angry Sun

Using the same script as the swinging vine, I created a sphere that will rotate and set active the "rays" that will harm the player. Once it exceeds the threshold, the rays will disappear and return when rotation returns to zero.

At first, I had a problem with the rays refusing to reappear. I had to set yRotation back to zero. Before, it counted past 360.

Swinging vines

While trying to use hinge joints for the swinging vines, I confirmed that the vine with be one sprite swinging back and forth. And so, I decided to code the vine instead of using hinges. Using and modifying a script I used in the Game Jam, I came up with the below:

Originally, instead of transform.rotation, I was using EulerAngles. This version is simple and fulfills our need.

Coroutines

The jump movement was buggy and would jump as many times as space was pressed, resulting in a flying char. When Mike coded the isGrounded bool, it helped some but the animations for them were still buggy. By using a coroutine, we set the WaitForSeconds with prohibited the character from jumping or punching while isGrounded = false and isPunching = true. 

Looking at the Unity API, I could see that Coroutines can be paused at a frame, restarted at the same frame, stopped all together and started again.

PlayerPrefs

For the level select, we needed to have the levels not yet reached to be inaccessible. To do this, I looked into PlayerPrefs and store a key specific to the level that unlocks the next. Once the player reaches the exit, then the key is added to player prefs and stored. In order to test the function. I used print and had a ClearPrefs() that deleted the keys. When the button was pressed without the key,  a label that states the level is still locked.

Being heard

Since there had been a lot of disconnect with out team, I am not sure anyone noticed that many of my suggestions were overlooked by the team. I had mentioned a few options, both with code and with the team, that would have been proper solutions. None of these solutions were heeded in the first place, but eventually tried my solution and most of the time it worked or lead to the solution.

Emil mentioned this during mid-terms. He said that everything he has heard from me in the past few weeks had been correct, yet I remain unheard.

http://thoughtstreamconsulting.com/

In the future, I want to ensure that my suggestions are noted, instead of overlooked.

Midterm Peer reviews

Last week, Emil noticed that our progress was slow and no one show any passion in the work they put into the game. Frustrated, he instructed us to relearn everything about scrum, as no one could answer his questions.

I too agree that there has been a lack of passion and communication among the team. I think we would have been much farther had we worked harder.

Reaffirming agile methods

That Monday, over half the team was gone from our work period. All of which had gotten sick. I talked to Mike Anderson about the main menu options for having certain levels locked or unlocked so I look more into that option. So far I have the idea to put the level map onto the button for each level, but only show the level map if it had been unlocked. I still have to look more into player preferences for the task.

Need for Customer Engagement

In order to know if our features are valuable, we are way past our customer engagement need. For now, we can take the box and some concept art as we explain the features in our game. By this time, we should have a level that is mid game difficulty that our customer can give us feed back for.

Before we do so, I think it is important to set an isGrounded bool in order for the character to only be able to jump once from the ground only, rather than being able to jump of all of the obstacles, which can be done at this moment.

It is a major bug that should be fixed before the game is tested.

Scene Loader Menu

While unity has a great UI for text and buttons, which I used in the Nursing Simulator last semester, I was interested in learning how to code buttons into Unity. It was relatively simple, but I still had to look up a reference on the Unity community page.

Customer engagement

Early customer engagement is an important process to building a product that is actually valuable. You could have a well put together and working project that is reasonably priced, but if no one wants to buy the product then it is worthless.

Working in hand with customers using a working increment of the project is a vital for progress. Since our team works Kanban sprints, we should have a working increment every Monday, but we haven't implemented nearly as much as we should have.

For customer engagement, we looked into Nordstrom Innovation Lab's video in class.

Ice Movement

While working on the ice, I had researched many different methods, including materials. None of which would could get to work at all. After spending a few days on the ice movement, we decided to put it in the ice box, as it was taking up too much of my time.

Eventually, I would like the ice movement to look similar to the start and stop of sonic. When the button is first pressed, sonic is slow to start. When the button is let go, sonic still moves for a few seconds.

Event system

Tuesday - CSG 130

The next day, Mike and I worked on getting the text to appear when the character passes a certain point. He had my try to find the answer at first. Since I have little experience programming, I had trouble finding the answer. In the end, an event system was put into place when the character, crusher, reaches a certain point.

Slime troubles

While continuing to work on slime, we kept encountering problems with gravity and having glitches with his movement while upside down. Once again a movement had delayed our progress so we put him back in the ice box, until the crusher animation could be implemented. I worked next to Taylor and Mike as they implemented the animation.

Box Colliders for Slime

We started on the box colliders, but we had trouble with the gravity working the way we would like. When the character leaves the upside down wall, it does not revert back to the normal state and can, essentially, fly away.

Later on, Mike implemented a switch which four different cases. The gravity is fixed, but the character still needs to revert to an upright and retain gravity when off the ceiling.

Slime movement

Because we were having trouble with the slime movement, I tried to look for possible solutions on the unity website. One answer I found used raycasts, but since Mike had no experience with them, we reverted back to the idea of using box colliders on each wall.

Survey

Because of Labor day, we only had one day of class. I worked with the biz dev team in order to create a survey that will help plan our marketing plan to the public. We had a few responses to start. The biz dev portion is extremely important to launch a successful game. We need to pay attention to it closely.

Wasted Time

Near the beginning of our project, the team was worried that we would not have enough artists to finish the project with quality. While I am competent in drawing, it takes me a long time to finish and I don't have any experience with digital painting.

Emil noticed that I was placed on art, and we both agreed that pair programming with Mike Peck would be much more beneficial than being on art.

Tutorial level

Monday - CSG 129

The next week, I worked a little with Mike on the tutorial. We wanted to add text to the screen when the user reaches a certain point. While working on a nursing simulator last semester, I was more familiar with unity's built in UI system, so I explained a little about the Text feature in unity. Later on, I searched for fonts which would fit the design of the game and asked (PO) Sam his opinion.

Reading Code - Demo Scene

Tuesday - CSG 130

The next day, we used planning poker to asses the value of the item or task based on effort & complexity. Using the Fibonacci sequence, the team assigned the scores for each feature. Mike Peck had Marco and I look through the break down of the code again, since it had been awhile since the beginning of the summer. I understood almost all of the breakdown, and asked about anything I was confused on.

Sprint 0

Monday - CSG 129

The first day back into the building, we started our sprint zero for Alternalien. We entered into Psyberfire as many tasks as we could, that needed to be accomplished to build a working game. Our game would have been further along had our group been more dedicated to work on the project over the summer months.