Textures & presenting

While I ran out of time to make an end game screen, I planned to make the losing screen a morgue wall of coolers. Looking up a written tutorial on making a texture, I did learn how to make my own metal texture and added it to my Photoshop options. Within the second image, I learned how to warp the image to curve and give the image more depth.

While our presentation did not go as well as we would have liked, our team fixed a lot of the sloppy code & created better objects. Our main feedback from the senior class was to keep positive on which sections work well. Sell the game as if it is the best thing ever made. Be a good salesman.

Keeping that in mind, I remembered a show called Shark Tank which entrepreneurs and inventors pitch to a group of investors in order to find a backing (or sell their product all together).

Credits Scene

Keeping consistency with the start menu scene, I kept the same font and inverted the colors. However, I had trouble trying the write the script that would scroll automatically. Every time I looked up "scrolling script" it would give detailed instruction as to how to script a scroll bar.

Luckily, looking through the old scripts, I found a credit screen which was scripted in a way that made it sensible to modify to look more professional. I did have Mike (the instructor) show me how to center the text within the script.

Attending the CSG board meeting as a student rep

As a student attending from Carroll University, I was asked to be a student representative and discuss my thoughts on the program in the Computer Simulation & Gaming board meeting.

Despite a few paperwork issues at the beginning of the year, and very little information available through Carroll, I adamantly expressed how much I enjoy being within this program. By far, the CSG classes have been the best experiences I have held within a school. The instructors keep the curriculum engaging and challenging.

Many of the other students stated the same. I think it was a very prideful moment for everyone who had a hand in the program, but it really made me realize how much I do enjoy this program and the appreciation I have for how carefully planned out our curriculum is.

Loading screen

For the loading screen, I looked up about 10 Photoshop tutorials after having the idea of putting the loading screen as a hospital badge.

With very little experience within Photoshop and being a perfectionist, I worked on the screen for the majority of the class period. I continued to tweak it throughout the semester when I had small amounts of time free.

After this picture was made, I rounded out the letters and shaded the rest as I had the L in Loading. The background was switched to the same gray as the lettering of the menu, to keep a consistency with each screen.

Being useful

With code as messy as it was given to us, I was distracting our experienced programmers too often with problems and questions for them to focus on their tasks, so instead, I switched focuses.

I focused on the look of the game instead. Looking up as many tutorials on creating a menu, I tried to first use the same technique as the the previous group, coding the buttons in and placing a background image.

Struggling to accomplish that, I found a tutorial that showed how to create a menu using the pre-existing GUI options in Unity. Creating the buttons and finding a professional but interesting font, I placed the gray text with a backdrop of white. The color scheme reminded me heavily of a hospital. I kept the menu simple to keep the look professional.

Resources

Many in our group turned to blender for creating new objects for the simulator. Mike showed us two websites that help identify and fix problems with code: StackOverflow.com & MSDN.com.

The most helpful tutorial I found was from Unity itself, posted on youtube. It explains the most basic aspects of C# programming within MonoDevelop. While having some familiarity with the basic structure through a Carroll Uni class, I understood how to connect my previous knowledge to how to utilize it for a game code.

Project Manager

As many of our group is inexperienced, it was difficult to assign people to tasks. Luckily, we had two experienced programmers within our group (Michael Peck & Daniel Strong), as most of the problem with the simulator were a result of sloppy coding.

As for the rest, I had the group look up everything they possibly could about their related fields that could help the simulation not only run better, but look better. We also decided to have them continue finding bugs within the game related to the pieces they were looking to change.

JavaScript to C#

As I did not know where to start with the programming, I worked with Michael Peck as he switched some of the sloppy JS code over to C#. As he made switches, he asked if I knew what certain strings meant and if I knew the datatypes.

Anything I was not clear upon, or was yet to be taught, he explained until I understood completely. Personally, I feel I learn much quicker when my teacher goes through an example, explaining not only the meaning, but why it needs to be changed. I learned in the one class more than I was taught the past four at my Carroll course.

Breaking the game

Since this is my first semester working with programming, I had never heard of "breaking" the code. Essentially finding as many bugs as you can in order to list the problem that need to be addressed in the code. You look to see which code would be the easiest or hardest and deciding the priority needed for each problem.

Once we all had to nursing simulator running, we found the bugs and noted which screens we wanted to make more appealing.

Mequon

As William Breece (the previous team's PO) had suggested, we set up a meeting with Stephanie, our client at the north MATC campus. Through a snow storm, and the subsequent traffic, we made it to Mequon safely and navigated the building to find the real life nursing simulator.

While not all of us were needed at the demonstration of the cardiac arrest event, I believe we all had a better understanding as to what our user was supposed to accomplish through the simulator we were working on. We have high hopes for our project. I hope we can fix all the bugs in time to accomplish the amount we would like to.

Team roles

Using the same teams as CSG-110 made assigning roles much easier than it would be otherwise. I had decided to forgo product owner as I was that role in CSG-110. Not only did I want the chance to experience another role, I wanted to be sure I would be able to fulfill both roles to the best of my ability.

The team activities in high school cannot remotely compare to the type of team work we have done so far in the CSG program. Everyone in our group wants to do well in classes, but even more so, they want the project to be as good as possible. If they do not care, it shows.

Picking a project

During week 5 of CSG-115, we were given the option between two different projects to work on for the semester. The first shown to us was the Cops for Kids, which had mini games that encouraged kids to appeal to cops. The second was the nursing simulator which had major glitches and almost none of the GUI worked.

We chose the nursing simulator because we wanted experience in simulations as much as games. We also wanted to get a feel of working with a real world client.

Immensity

The tutorial drops you into a game which is nearly finished. Many of the items (prefabs, scripts) are already made; the others are explained in detail.

The biggest impression the Lerpz tutorial left upon me is how immensely difficult and meticulous a game really is to create. You must have a detailed idea of every aspect of the game you are putting together. You then have to check and debug whatever you have changed or added.

It is best to implement additions or changes incrementally so you know exactly which section is the problem.

Organization in Lerpz

Unity via Steve Jarman

        Nearly finished with Lerpz, I noticed that some prefab models were not reacting the same as others. Particularly, the enemy, Copper, would fail to move or attack. I realized that I had been modifying individual Coppers, instead of the prefab. In result, different enemies would react differently. In the end, I deleted all of the enemies and worked on the prefab before adding it back to the platform.

       Furthermore, while working through the script of the GUI's with the tutorial, I noticed the comments throughout. Neat code provides easy modification and the comments help the user understand exactly what the code is referring/connecting to.

      Working more with the script, the terms begin to look more familiar.

Lighting Effects

Lerpz from Unity

     I experimented with different aspects of lighting on the platform. Before working with art (sketching and extending to Lerpz), I had not appreciated lighting or shadows. In Lerpz, the lighting made the characteristics of the platform stand out. The lighting of the jetpack enhanced the look of Lerpz. Furthermore, the lighting on the respawn points not only serve as an indication if stepped upon, but as an attractive aesthetic.

Lerpz Tutorial

Lerpz from Unity

     Beginning on the Unity Lerpz tutorial, I learned some of the basic terms involved in programming and designing games (assets, GUI, components, etc.). As I moved further through the tutorial, I became more familiar with Unity: especially positioning things well and, after several moments of confusion, that you have to pause the game before making changes!