Vincent Slifer PPJ week 09 & Personal Post Mortem

This week was not the greatest, but not the worst week for me.  On a massive note, I got sick on Friday, which put me almost out of commission for Saturday and Sunday.  Other than getting sick, I was able to polish Popcorn Popper, Item Dodge, Ram the Planet, and Mechanized Warfare.  For Popcorn Popper, I added in the texture for the popcorn machine, increase the number of spawned popcorn to make it easier to fill the machine, as well as change the method that machine is simulated. In Item Dodge, I just change some colors to better fit the themes of the game and give the shooter a more recognizable model.  For Ram the Planet, I got rid of the power bar, as well as adding in assets to for the players to, more easily, recognize the speed that is supposed to be read.  For Mechanized Warfare, I changed the target selection so that the targets are now given a color overlay, rather than changing the material of the object itself.

New method for motion on Popcorn Popper

Ram the Planet

Positive Content

• Updated Popcorn Popper, Ram the Planet, Item Dodge, and Mechanized Warfare

Negative Content

• Was not able to get people to attend playtests
• Got sick

Work and Hours

Alterations (~2 hrs)
- Changed assets for Item Dodge to better read how the game plays
- Edited Ram the Planet so the sense of speed is better understood
- Made Popcorn Popper spawn more popcorn per button press for humans
- Edited Mechanized Warfare so textures show up before they are shot

Final Art Implementation (~1 hrs)
- Implemented final art for each game

Total Hours: 3 hrs

Personal Post Mortem
What went right
1. Iterative Design
A major part of the process for my games was the iterative design the games went through.  Planet Ram is the biggest example of this process.  Originally, the game allowed the players to move around in the space as they attempted to reach the goal.  This was found to be too difficult to both play and discern the goal of the game.  So, the game was changed so the players only had to just hold two buttons in order to win, reflecting on the original intent of the wacky nature the game was intended to have.

2. Influx of ideas
A major plus with a larger team was the new set of people that could provide in team feedback and ideas for the games.  For me, it was extremely helpful to have other members take an objective look at my own games, to provide concise feedback on what was originally envisioned versus what I had produced.

3. Cooperative Goals
A major element of successfully developing the game was that we were working together in each game.  What I mean is, each element of every game was designed to cohesively work together, to create a more consistent feel, rather than five different programmers designing separate games.

What went wrong
1. Playtesting
My own personal issue, I was not able to get people to playtest the game.  I was unable to get people to play the game on a local machine due to the fact I only have one controller, and I was unable to get people to go to the Drexel Ride in order to test it on the motion base.  This is more reflective on how I do not press people to go out of their way to do tasks that other people do not know if it would be fun or not.

2. Communication
This term, I was not as communicative as I previously was with others on the Slack.  I was more attentive of the slack, but I was more hesitant to actually communicate with others.  Again, this is more reflective of my hesitance to reach out to others and worrying about bothering others when they have their own work to do.  I did reach out to others when I absolutely needed someone else to complete a task, but otherwise, I tried to accomplish it myself to the best of my abilities.

3. Initial Team Growth
The start of the term was a little rocky, with the initial team growth.  We intended to continue with how we were operating from the previous term, but we quickly realized that with so many people, it was apparent that we would not be able to meet in person on Sunday.  There was also a major influx of catching people, from the other team, up to what and how team was doing things.  These issues, however, were not that troublesome because the teams, fairly quickly, assimilated into one.

Lessons Learned

• Work cooperatively
• Ideas and feedback from anyone is a must
• Take a critical look at everything
• Adjust to keep everything consistent

Cory Zicolella, Week 9 PPJ, Blog Post 9

Garnering Playtest Data - 5 hours
Editing Playtest - 1.5 hours

This week was pretty standalone from any other for me.  While I usually do many other extraneous things, this week was focused simply on getting all of the playtests we needed since we had to have 44, and we didn't get much testing on the motionbase this term.  A secondary objective I had was to get more footage for the video so I could edit it this week; while I did get the footage, the labs were full when I was available so I couldn't make the necessary edits.

Getting the playtest data was mostly done on the Wednesday group playtest where I spent 4 hours, and on the following monday where we reserved an hour to get even more.  I recorded testimonials of some people before and after their ride experience if they didn't mind being on camera.  I also had to edit the playtest for each of these sessions before they happened to make sure they were good (and in some cases, to streamline it).

That was all I really did this week.

Total Time Spent: 6.5 Hours

This is a personal post mortem, and as such I will be measuring my work I did against my team as a whole.  I personally think I was a great asset to Alien Arcade; I was part of the original team a term ago and my placement as a sound/idea person carried through to this term as well.  Of course I did other things such as modeling as well, but my main placement seems to have been unofficially in the sound & video department, and idea creation.  This all being said, there was definitely good and bad that came with this project.  I',m happy I got the chance to work on it, but given another opportunity, there are somethings I would change.

What went right?
1. Reporting to the team.
I always made sure I would report back to someone if anything I did was finished (along with a direct path to that thing), or if anything somehow was an issue.  This really helped the team I felt because I was capable of doing more than I thought (if I told someone I didn't have much to do), and the team also knew exactly what I had been working on, and when it was finished.  Some people didn't do this as well as me I feel, and certain games may have slipped slightly because of it--they were always fixed, but usually never arrived to class in the state they should have been in.

2. Democracy
It is a weird label, but honestly I have no other clue what to call it (maybe team synergy).  Whenever I had an idea regarding a game, or an issue I had with an existing facet of one, or even a trailer decision, I ran it by the team.  This made it so everyone was aware of whatever idea/issue I had, but it also made it fair as to what we should do with it.  This essentially made everything a team decision, which I feel is really important for morale; everyone feels as if they have a say and in the end as if something important was credited to them.  This occurred often when brainstorming new ideas (this method of thinking eventually led to Draw at Noon) or during what I call 'issue meets' where we go through every game and list what is wrong (this is how we agreed to handle certain bugs).

3. Documentation
Personally, I didn't do a lot regarding this, but I think the amount that I did certainly helped the team largely and made the necessary processes faster.  When i gathered all of the sound effects for use in Alien Arcade, I made sure to document all relevant copyright information as well as a brief description as to what the ound actually is.  This made it extremely easy for David to add this into the GDD later as well as the credits of Alien Arcade; and it also helped everyone else who was trying to put music into the game.  Aside from this, my changelog submitted both to perforce and slack whenever I did something was very succinct and included exactly what went in and where each time, making finding those things easy.

What went wrong?
1. Timeliness
I am really bad personally when it comes to working in a timeframe, specifically because I work the best under pressure.  That being said, I always got things in on time and never really failed to do a task that I was assigned to do for the week.  I simply waited a long while or put the assignment on hold until the ladder end of the week to do other things in the meantime because that's how I've always worked.  It wasn;t necessarily a detriment to the team, it just forced me to change over time--I went from working mostly Monday or Tuesday on the project to starting to work on Saturday for it.  In some ways, this can be a positive thing; but it took 8 weeks to get there and I feel as if nothing but good would come from having me start and finish things earlier.

2. Not Getting Enough Playtests
Being in charge if playtests for Alien Arcade, this falls heavily into my hands I feel.  However, a few others and myself always mentioned playtests to people and we never seemed to meet our quota like we did from last therm (which is probably due to the huge influx of team members).  This means both on and off the motion base too; we managed to get many playtests our final week, but that was a desperation attempt because it was really required in order to fix bugs.  If we had more testers in general, and specifically more on the motion base, I feel like a large number of bugs we discovered could be fixed, and the motion could certainly have been tweaked already.  This was probably largely in part to there needing to be 3 people free, and 2 xbox controllers to even do a single playtest at all.

3. Time Estimation
This almost goes hand in hand with timeliness, but I'm setting it aside because this was a large reason why things were handed in later than expected as well.  This term in particular, I ran into many computer issues (both on my personal computer and on lab computers) that caused my various tasks to slow to a slog.  Whether it be the computer i was working on not having enough ram to handle a certain edit I made, or my computer deciding to randomly slow until I needed to do a system restore, or simply having something take longer than expected; time estimation always was an issue.

Lessons Learned:

• Reporting to the team allows everyone to know what's going on
• Team synergy is really important in a large group project for morale
• Documentation, no matter the form, will always help a process
• Working under pressure can be good, but in team projects it is not usually the best
• Playtests are extremely important to working out the flaws of a game
• It seems that estimating slightly more time than needed wouldn't hurt anything amidst all of the computer issues I ran into this term

Joseph Santos Week 9 PPJ and Post Mortem

This week, I just had to finish textures for any fbx in the currently in the build. That meant importing a transparent trexture for ufo in refuel and a texture for the popcorn machine in pop corn popper. That was the end of my art production for this week and the entire term. The rest of the week I spent time helping my team gather play testers for both the playtests on Wednesday with infinite skies as well as alien arcade's own individual play test on Monday. I created the event on facebook and constantly blasted it out to every drexel group in hopes to get as many people possible. During the play test, I've captured some footage for Cory's video.

Pros:
Finish tasks in art backlog and closed it.
Got enough playtesters for the game this week
Cons:
wished I could have helped more with any other art asset that needed polishing
Event I created in facebook to get people for play test didn't draw a lot of people as I hoped. Even though we met our quota, I wished we got more people.

Hours:
Finished textures for fbx:
ufo - imported = .5
popcorn texture = 1

Getting people for play test(posting posters, sending invites) = 2

Attending play test and getting additional footage = 1

Total hours: 4.5

Personal Post Mortem:
This term was a bit rough for me. In addition to this class, I had other production heavy classes as doing the co-op interviews. At times I felt being pulled in 3 or 4 different directions with these projects and as result as I fell behind at times. However, I was not the only one in team suffering from being over burden with stuff and together, everyone pulled through this term to deliver on most of our promises for this build.

Problems:

Time management: 1 Production class is enough work for a student but working on 3, I found myself exhausted each day that I would fall behind schedule. I also had to do interviews for co-op and usually after doing those and traveling to them, I wouldn't feel able to do anything else for the rest of day. Not only would better time management would serve me better but also maybe not signing up for 6 classes this term. Lesson is not to take on too much.

Playtesting: Getting player testers for our game was a big problem most people faced, especially on the motion base. For me personally, I was usually never available when we scheduled playtesting on the motion base since I other classes around those times. I tried to make up for that by spamming our website to various friends, families, and game dev facebook groups, asking them to download the build and take a survey. Turns out I need work trying to write better posting to make people curious about our game and willing to give 4 minutes of their time to play the game.

Some mis-communicaiton: This was a problem that popped up every now and then. Usually I use Trello as a reminder of what I have to do. However, some art assets I did or created wrong. That was due to me misunderstanding the instrucitons, whether written or verbal. Luckly, whenever I screw something up, I was able to fix it and turn the correct asset in before the deadline. Again, this problem popped up every once in a while. Not a major problem but something to note.

Success:

Teamwork: When Moo diary team from last term got absorbed into Alien Arcade, everyone got well. A week or 2 into the term, the team was shown working well together. Everyone did their best to deliver what they ask and for the most part, we gave updates with each other on slack, letting known what was done or needed.

Art: For the most part, I was able to deliver on crucial art assets needed from me. By the end of term, any art asset asked form me is in the build. Also, I was able to catch some errors with other fbx not made by me and fix them.

In summation, despite being overwhelmed with classes and interviews, everyone was still able to deliver a solid build and I am proud to have been on this team.

Angela Buchanan, Week 9 PPJ, Blog Post 9, GMAP 378

2D art, interface, texturing

I focused on refining the interface more this week. This included cleaning up instructions, adding missing elements, and reflecting any changes.

A big challenge for me this week was finding a way to the score and timer bar stand out. I tried a few different methods until I decided to try adding gradients to the sides. While it was a very simply solution, I felt it worked most effectively. My other methods seemed too bulky and thick compared the smooth gradient. Additionally, the gradients can be placed on-top of the dash as well, making the dash environment look less flat.

I also made some art to fill the blank space on the slot machine. Originally, before the aliens had their own console, that space was going to be used for slot instructions. Now it's just for decorative purposes.

Positive Content   

-  I don't expect to have to any more tweaking unless absolutely necessary.

- Found a nice, simple solution to make the time and score bar stand out more 

Negative Content

- Didn't work as much on the sell as I would have liked to

Work and hours

Instruction screen update (1 hrs)

Just a general update to fix changed instructions, add any missing ones, and fix any errors in previous ones.

Time and score bar visability fix (1 hrs)

My first method used a faded pixelated shadow effect, but I felt this looked to clunky and clashed with other interface elements.

The gradient also adds a stronger sense of space to the dash, so I decided to stick with that solution.

Slot screen art (.5 hrs)

The process for this went smoothly.I looked at some slot machines for minor influences, aside from that it was a simple asset to make.

Sell Tweaking (.5 hr)

I tweaked the sell as much as could with the amount of time I had remaining. I expect to do more next week, but the game tweaks had a higher priority.

Total Hours: 3 hrs

Post Mortem

Things that went right

- Overcame interface design challenges (Making things visual and quicker to understand)

Working on the interface was my biggest task for this project. The game heavily relied on players being able to quickly pick up and adapt to the instructions. At the same time, we wanted players to clearly know their progress.

This was challenging due to the chaotic nature of our game. With so much going on, good design is important to make the interface stand out. I knew without a good interface, the game would not be playable.

Taking feedback and using some of my own ideas, I felt I was able to establish a strong interface that has made significant developments throughout the term. Aside from some text instruction, the majority of our interface is visual, making it easy for the player to quickly grasp information.

- Managing more people

Communication is my weakness, regardless I felt I was able to communication more effectively this term with both the programmers and the artists. I managed to keep relatively up-to-date with instruction changes through the term and during meetings I encouraged the programmers to voice any needs or requirements for particular assets. 

As for the artists, I provided feedback when possible and helped direct some design decisions.
When asked for advice, I responded quickly.

Additionally I made it clear where all assets could be found and included direct file paths to assets during my updates.

- Produced a lot of work

The interface alone required a lot of components, updates, and changes. Along with that there was the slot machine (Another big project of mine) and the icons. Both tasks required a lot of attention and updates and took the majority of my time.

Despite this, I still managed to complete other tasks. Generally texturing, but I also took care of some basic modeling.

Things that went wrong

- Miscommunication and organization (Lack of firm leadership skills)

I prefer to have heavy influence over projects I work on, therefore I tend to lean towards leadership roles when possible. However, I struggle with effective communication and organization (The state of my desktop folders and desk support this fact),

I do feel that this negatively impacts the project.I did take initiative and attempted to prompt discussion on the art side of things, but the clarity of my words and lack of firm voice does not draw much attention.

Additionally, I felt folders could have been better organized and I could have contributed more documentation that set down a specific workflow for artists. I plan on relying more on reference documents like this for future projects to help add direction where my voice cannot.

- Insufficient planning early on (Game concept art)

I have mixed feelings when it comes to concept art. At the beginning of the project it contributed a lot to setting the mood, however many ideas expressed in concept did not make it's way into the game. Concept art also requires a lot of work, which takes time away from asset production.

During this term, there was game-flow concepts, which I ended up not assigning further as I felt they were not useful. I felt there was a strong disconnect concept and what was actually produced (alternatively, I felt there was also disconnects from ideas stated and concept produced).

Instead, I stuck to a reactive approach for assigning tasks. However, I felt I still should have set some side time aside to plan out and predict art assets ahead of time. I did some this, but not to the extent that I should have.

- Difficulties distributing work

This is partially due to the insufficient planning and organization, but I had difficulties assigning tasks.
Better communication while game were being built would have allowed me to create a stronger asset list that could've been in place sooner.

Additionally, the skill and style differences of artists made it hard for me to make decisions regarding task distribution.

Honestly, I'm still lost on how to effectively manage skill and style differences of artists. When you're working with deadlines, it's hard to make decisions for when assets need to be redone. Especially when those assets take a lot of time.

Jinghan Liu - Postmortem

Personal Postmortem

This term I joined in the Team Viicious and worked as a 2D artist for the Alien Arcade. Overall, I like the game I worked on and I got good experiences of work with a big team. 

At the beginning of the project, I was busy to learn the new art style and learn about the game that already has a playable build.

The biggest problem I had is team communication. In the first week of the term, we had meeting in Sunday, after that we assigned tasks to everyone after the class and report process of the work on Slack in Sunday. But I had another class after the game workshop class (from 3pm), so sometimes I have to leave in the mid of the meeting and ask someone about my task later. It makes I got confuse with my task and late on start work on that.

Also the art team people need to tell the path to the file that they worked on to the programming people. Because the game had already been worked on for a some times, the work folder has ton of stuffs, people are difficult to find a new file if just tell them “I uploaded some files”. However, sometimes I forgot tell them the path to the file, and realize that after some programming people ask the place of the file.

The another problem I had was different art style. I had to learn the existed art style and draw like that. Change own art style was difficult, but I enjoyed learn new art style. However, my works are almost looks like Angela’s but still has some differences, I think if people focus on see the art, they would be find that.

At the ending of the term, the most of the works are fix, update textures or 3D modeling, there was not much task for the 2D art. But because of I have limited skill with 3D modeling, I had not much thing to work on at the end. I realized that I need to improve my 3D model skills.

Overall, there were some problems but I enjoyed the works and enjoyed work with the team.  I usually worked in a 5-7 people group, so the team Viicious is one of a good experience of working with a big group, to learn about the team communication, share the files with all team members and work together. I get new art style that I never tried before. 

Xavier Smith, Week 10 Journal PPJ, Blog post w, GMAP 378

Content with Hours:

           

            Playtests and crunch time! This week was the busiest yet, another game I’m working on, RGB went into crunch time, so I spent the weekend until early Tuesday working on bugfixes and integration for a beta. That being said, I still managed to get a few things done for Alien Arcade this week

            Firstly were the playtests; I organized with the other section’s Team Lumpy Labs to host a joint playtest for both of our games at the motion base. Due to a few miscommunications however, we weren’t able to get enough playtests done, and so I scheduled for another one (with a fair amount of help from Joe Cory and David!) to get more playtests and find motion base bugs (3 hrs)

            Secondly, I did a bit of sprucing up on our sell presentation to reflect our latest build, and added a few more slides and talking points (1 hr)

            Finally, I made a few quick fixes on bugs we found from the motion base and tried to make the instructions for a few of the games a bit more coherent (1 hr)    

Content Positive:

- Got a lot of feedback from the playtests

- Fixed a few minor bugs

Content Negative:

- Didn’t have much time to work on the project due to RGB

Total Time Spent: 5 Hours

Personal Post Mortem

            Overall, this project proved incredibly draining. Most of the team and I were able to keep up with the project in the beginning, however the constant barrage of documentation, playtest requirements, and pressure to polish and add content while still keeping up with other classes took its toll on the team. Towards the end of development things started becoming strained between a few members due to the stress but we still tried our best to put out a decent game.

            

 What Went Right

1. Teamwork
As our team grew, we realized early on that we would need to change the structure of our team hierarch. To that end, I retained position of project leader, with John leading the programming team, and Angela taking charge of the art team. This proved to be a more efficient structure, especially for the artists as members were always clear on to whom they needed to speak to in order to get a task complete or a feature/art implemented. This also helped to ensure we did not repeat the mistake of the last cycle whereby members were unclear as to who was supposed to complete certain tasks resulting in the same work being done more than once. 

2. Content Generation
Despite time constraints and a few extenuating circumstances, the team actually managed to create more content than expected for this cycle. Halfway through the term our goal was to finish the project with roughly 16-20 mini-games; however we managed to finish with 22! One of the main reasons for this was having a dedicated programmer for functionality this cycle. Last cycle, functionality was done mostly by David and I. As a result, their ability to complete games was slightly hampered, and bug-fixes would be solved inefficiently as both programmers would occasionally work on the same problem unbeknownst to them. For this cycle, functionality was left entirely to John, who managed to complete all his tasks and still have time to implement a mini-game or two.  Additionally, our larger team size allowed us to work on more mini-games simultaneously, naturally resulting in more games being created. 

3. Documentation
In the previous cycle, most of the documentation was handled by David. For this cycle however, we managed to get more people on documentation, and so much more documentation could be done on a more detailed level. Due to the democratic process in which work was split up, not only did we ensure that no one member was overworked, but that each member got to work on something they actually had experience in or personally wanted to oversee. This proved to take a huge weight off the team’s shoulders (especially David’s) as we had the benefit of having more fair and even workloads while still being secure in the knowledge that all tasks would get done by the appropriate deadline.

What Went Wrong

1. Playtests
Playtesting was a more significant part of this cycle, with a much higher volume of playtests required for the game this time around. Due to the nature of booking the motion base as well as the necessity of 2 Xbox controllers and at least 2 players, gathering playtests for Alien Arcade has always proven difficult. While we managed to scrape up enough testers to meet quotas, each playtest cycle proved challenging to say the least.

2. Time Estimation
As a fair amount of our team members were in their senior year, enrolled in multiple production classes, or both, many members suffered from large workloads for this quarter. As a result, underestimating the time taken for one of our numerous deadlines would cause a serious setback, requiring no small amount of work to catch up and get back on track. As we are still fairly new to game development, these underestimations happened frequently enough to become a recurring problem throughout the project.

3. Clarity
One recurring complaint we received about the game was a lack of clarity for a few of the games. Due to the hectic pace of the game and our large library of mini-games, creating consistent, clear and concise instructions for each mini-game proved a persistent issue for the game. While the game now features a significantly more readable and consistent HUD complete with concise controls and instructions, we were still never quite able to figure out how to reach the level of clarity we wanted for every game within the project. 

Lessons learned
• Documentation can be very helpful in keeping track of goals and progress
• Setting aside time to test games is just as important as setting aside time to develop them.
• Team synergy can have a significant impact on morale
• Increasing team sizes eases workloads, but can make team management significantly more complicated

Ricardo Yanofsky, Week 9 Journal PPJ, Blog post 9, GMAP 378

Content with Hours:

Playtest session
I was at the joint play test session for 3 hours, making sure Alien Arcade was also being played. I also messaged some people to come play (some did) and played both in and out of the ride for people who did not have a partner. It was a little frustrating since there was a small group of people who kept replaying Infinite Skies and did not want to play Alien Arcade.
(3 hrs)

Animating the Alien
I spent some time animating and polishing animations for the alien, which I do not think I will make more of. I'll export them first thing this week so they can be put in the game. It should go smoothly, I think I've found all the problems.
I made:
-floating in space idle
-2 standing idles (taunt and wave)
-run cycle
-whack the alien animation
(3 hrs)

Content Positive:
-Got some playtest data from the ride
-Enough animations now

Content Negative:
- Joint playtest would have worked better separately.

Total Hours for the week: 6

Personal Postmortem:

Negative:

1. Rough start: Starting off the term with an injury was a big setback, especially with it being in the first few weeks and getting settled into a new team. It took some time, but eventually I was able to work in 3D comfortably as before.
2. Alien Arcade was not the best game for a 3D artist, since there are so many small scenes, it would be too much to work on each individually. With Angela's 2D general assets, the game was able to look good without as much art, but that also meant I had less to do. This was especially noticeable when I would go on trello and find very few things I could do.
3. Lack of coding abilities: due to my abilities being almost limited to art, I do not feel like I had as much of a creative input as I have had in other games. I helped brainstorm ideas, but did not actually make them happen. If I had been able to contribute more to the game creativity than I probably would have been more motivated.
4. More of a team wide thing, but one aspect of the motion base we did not consider before is the complexity of the controls and game. If a game plays in a unique matter, it usually needs to spend a few minutes teaching the player how. The problem with the ride is that we only have a few minutes to play the entire thing. Default mechanics and controls (such as Infinite Skies' driver/gunner) work well because they don't have to be explained. With Alien Arcade, although the controls were somewhat uniform, it was still too difficult to tell the player what to do.

Positive:

1. The alien rig; Once I had recovered from surgery I found something I was motivated to work on: the 3D rig of the alien. I was able to make a fully rigged character in 2 weeks, and then make several animations for it. I like animating for games and I am glad I got to do it for this project.
2. Work in Unity: While I do not know how to code well enough, I have learned some things about Unity. Nothing major, but I did get to import and tweak assets and mess around with mechanim,

Lessons Learned:

• 3D artists are not always a valuable team member.
• Games are better if you can play as long as you want.
• A few more things about getting fbx animations into Unity
• It helps to like what you are working on.

Ryan Crim, Week 9 Journal PPJ, Blog post 9, GMAP 378

Personal Post-Mortem:

As we approach the end of development for Alien Arcade, it is as good a time as ever to reflect on how it went. In general, having joined the development after it had already been worked on for a term meant that there would inevitably be a lot of ups and downs as not only did I have to become accustomed to how the game was currently working, but I also had to bring a different prospective to improve/change it up.

Issues

Concepting

The biggest regret I have regarding this project was missing the first group meeting since it was on a Sunday at the time (mentioned in my first PPJ). In this meeting, most of the brainstorming for how Alien Arcade should evolve as well as concepting game ideas took place so the majority (about 80-90%) of the mini/micro-games made during this production were pitched to some degree in this meeting. In my opinion, some aspects of the game seemed to be ignored to an extent and had to be handled later in the process (such as scoring), and some of the game ideas seemed to be missing something, and I think I could have been an asset to bring up early issues. In general, I think not enough was done during the concepting phase and that caused issues later where myself or others in the group were second guessing what exactly needed to be done for a few different aspects of the game. Looking toward the future, I definitely never intend on missing the concepting phase of a project again because it is the most important part in determining how smooth the production goes.

Soft spoken

In the same vein, one issue that tends to plague me on group projects in general is the fact that I am naturally soft spoken. For the first half of the project, the combination of this and the fact that we were not consistently inspecting the progress of the game as a team in a meaningful way resulted in a lot of issues existing for much longer than they should have. Furthermore, there were situations where I feel as though extra/unnecessary work was being put into aspects of the game and I should have spoken up more to prevent what I considered time sinks. For example, while the resulting alien model and animations look really great in Draw at Noon, I still hold the belief that the four or five weeks it took to make them (especially the time spent on the complex animations) was not worth the effort since the animations only appears in a single five second game and it took away time from improving aspects of a lot of the other games. Toward the end, I got a bit better about speaking up and mentioning my thoughts/issues, but I think it may have been too little, too late in some cases. Therefore, moving onto future projects, I will definitely try to continue to improve my communication skills and speak up more.

Motion base

Despite the fact that this whole game was being designed for the motion base, I was not able to regularly attend it considering that the open hours on Wednesday conflicted with my schedule and I was generally busy throughout the week working on Senior Design, the multitude of changes for this project and assignments for other classes. Therefore, while I was putting a lot of effort into each of my mini/micro-games to try to make the motions as obvious as possible, I was never really able to test them to make sure they were working as I wanted them to. Furthermore, I was not receiving solid feedback about the motions since playtesting on the motion base was sparse. I definitely wish I would have been able to test more on the motion base (although my motion sickness would have made that tough anyways).

Successes

Mini/Micro-game creation

The most fun and rewarding aspect of production for this game was definitely creating and working on my own individual mini and micro-games. Over the course of the term, I ended up creating four micro-games (Abducktion, Draw at Noon, Dance Off and Whack-An-Alien) and one mini-game (G-Switch), which I believe makes up almost a quarter of the games. This included setting up each scene, writing all of the scripts and, in some cases, creating art assets. With all of these different games, I was able to test my prior knowledge of Unity development as well as discover a whole slew of new techniques and perspectives that I will be able to carry on with me to future projects. For example, prior to working on this game, I knew that sound effects were important, but for a mini/micro-game collection they are crucial since players can heavily depend on sound cues to take in information without having to break their concentration from the action on screen.

Bringing consistency to the game

Having learned of the importance of prefabs in earlier game classes and utilizing them in previous projects/games to make updating reoccurring objects (such as UI) a cinch, I was surprised at the lack of prefabs when I joined the team, especially considering that this game would have a lot of different scenes for the multiple mini-games. Therefore, over the course of production, I made sure to create relevant and useful prefabs that are applied in each of the scenes, which made updating aspects of the game a lot simpler. The biggest example of a prefab that has saved a lot of work is the Dashboard UI prefab, since it has been updated many times throughout the course of production and required almost no effort to update each time after I added in the initial prefab to each scene. In addition to UI prefabs, I helped bring consistency to the game in many different forms, including updating the scoring logic (humans vs. aliens, centralized score values, high score saving, etc.) as well as made sure that each game had their own unique music and that said music was balanced between all scenes. Moving forward, I definitely intend to continue to make sure every project I work on properly keeps everything consistent and as centralized as possible.

Meeting deadlines

Another aspect of the production that I am happy with was that I was generally able to meet all of my deadlines that were set. The only cases I did not end up hitting my weekly deadlines were when I was waiting for an art asset that was not yet finished. In those cases, I made sure to find another aspect of the game to work on so that I was not wasting time. An example of this would be the few weeks I was waiting for the alien model and animations to be completed, so instead I made improvements to the general structure, such as updating the InputManager to be more organized, creating a custom version of Unity’s RigidbodyFPSController to easily change its inputs and adding the ScoreChange prefab. Also, I made it a point to help anyone else out with any issues that they were running into. In general, this project provided good practice for setting realistic estimates for work, a skill that I have been working on since my first Co-op.

------------------
 

Content with Hours (Examples included):

With the second beta out of the way, this week marks the sprint toward gold build. Therefore, a lot of this week consisted of fixing small issues and polishing up each of my games as it was needed as well as touching up different aspects of the experience as a whole.

Over the course of the production, one thing that has seemed to be neglected has been audio, especially the music, with some games still lacking music or reusing music from other games. Therefore, since Corey had already downloaded a bunch of music clips from playonloop.com a few weeks ago, I went through each game, added the song that fit best and made a note of all of these in a document. In addition, I know that there has been serious audio balancing issues in the game, so I added a prefab to play the background music in each game. That way we could manage the volume for all of the music from a single place and to hopefully keep the audio a bit more consistent. (1.50 hrs)

Moving on to my individual games, I started by making a few updates to Whack-An-Alien. Based on the feedback from showing it in class and a small bit of playtesting, the obvious issues that were occurring dealt with the alien moving a bit too fast and the controls being not as intuitive as they could be. Switching the speed was a matter of changing a variable and testing, and switching the controls consisted of changing the input strings in the Inspector to allow human #1 to control moving the hammer and human #2 to control banging the hammer. Also, changing the controls made it necessary to update the human control image with Angela’s help. Lastly, there was a suggestion to add a green light to appear in the hole that the alien was rising from to make it more obvious and it made sense so I added it as shown in Figure 1. (1.00 hr)

Figure 1. Screenshot of Whack-An-Alien with green light and updated controls

Next, I made a couple of different changes to Dance Off to try to make it clearer, easier and more consistent. In terms of making the game clearer, I added team name bars to each side of the game arena and changed the background color of each side to green for the aliens and pink for the humans as shown in Figure 2. Furthermore, I updated the coloring of the notes that scroll so that are more readable against the background. In terms of making the game easier, I made the offset for a correct note more lenient, so in the case of the humans it is about 3.5x more lenient and for the aliens it is 2.5x more. Lastly, I made the controls of the game more consistent with the controls of other games, such as Refueled, Space Aim and Stello Says, by making human #1 responsible for the vertical axis and human #2 responsible for the horizontal axis. (1.25 hrs)

Figure 2. Screenshot of updated Dance Off game

For G-Switch, there was only one real issue and that was the fact that it could be difficult to tell when you are nearing the end of the current platform you are walking along. Originally, I intended for the platforms in the upcoming section to be the guide, however, with the addition of the alien instructions panel the next platforms may not always be readily visible. Therefore, I added transparent pink zones at the end of the jump-able platforms in order to try to more visibly let the player know they are reaching the end and should jump as shown in Figure 3. Furthermore, I made sure these pink zones were short, so if the player thinks they need to hurdle this then they would still have plenty of jump to make it to the next platform. (1.00 hr)

Figure 3. Screenshot of G-Switch with transparent pink jump zones

The last of my games that I made changes for this week was Draw at Noon. While discussing the current state of the game, the team was adamant about how unfair this game was to the humans. Therefore, in addition to adding a fourth arrow sign for the aliens to press as shown in Figure 4, I also made the signs prevent showing the arrows to press until the instruction bar disappears. In terms of cosmetics, I updated the animation script to also change the alien’s texture so it would show different emotions depending on the state of the game. Also, I fixed a visual glitch that was making it appear as though the human’s bullet bounced off the ground due to the recoil motion. To fix this, I moved the location of the bullet’s start point forward so it would not be affected as greatly by the camera as it recoils back. (0.75 hr)

Figure 4. Screenshot of Draw at Noon with four signs and angry alien

Lastly, toward the end of this week, Angela submitted a HUD gradient that makes the in-game UI (score and time bars) stand out despite the background of the game as shown in all of the game screenshots above. In addition to adding this gradient in the form of a prefab to each scene, I updated the ScoreBar prefab to remove the temporary transparent black box around it and I updated the TimeBar prefab to instead use the pink to green gradient version that Angela had created. (1.00 hr)

Content Positive:

- Made sure every game has their own unique music

- Balanced the background music generally between the menus and games

- Fixed various issues in Whack-An-Alien, Dance Off, G-Switch and Draw at Noon

- Updated in-game UI (scorebar, timebar and HUD gradient)

- Helped resolve issues in others’ games

- Got five playtesters (off of the motion base)

Content Negative:

- N/A

Total Hours for the week: 6.50 hrs