Content with Hours
(Examples included):
The group tasked me with
going through several of my own games along with games from last quarter and
fixing several bugs in them. I also added several enhancements throughout the
games. The first game I needed to fix was Space Aim. The movement style was
switched to using AddForce many weeks ago. As a result the gameplay was
completely different. It was changed in order provide a more fluid experience
on the motion base. The group decided it made the game much worse, so I was
tasked to change it back. Another fix in Space Aim that I had to do was to make
the “collision box” encompass the feet. The feet no longer clip through
geometry or walls! Last, the controls for Space Aim had a slight bug from the
work I did on them last week. The controls would still flip every so often.
After bug hunting for a while I did find the issue. It was related to old code
from last quarter… I hope it works correctly now!
(1 hr)
Next, I moved onto bug
fixing the newer games that I produced. The Press game needed to have sound
effects added to it in order to enhance the experience of winning and losing.
Thus, I had to rework some of the code to allow for some time to play the sound
clip before moving onto the next game. I did the same for the Quiz game. There
are now distinct, and fun, sounds for when you win and lose them. In addition
to adding sounds, I added some cabin motion for when players win. Previously
there was only a shake when the players lose. Now there should be motion for
winning or losing (different types of course). The Water Gun game required a
number of tweaks that the group asked of me. First, I switched the controls
from being “holding” to “mashing”. Based on the in person feedback the group
said that players kept mashing the bumpers in Water Gun. This took a fair
amount of time as the code for shooting was tide to holding the buttons instead
of mashing them and had to be rewritten/restructured. The alien controls for
moving their target up in Water Gun was switched to the spacebar instead of the
up arrow. This was also based on group’s and player’s feedback. I then made the
cardboard waves in the Water Gun game move up and down. The group’s feedback
indicated that they didn’t realize that they were supposed to be on water and
moving the waves may help. The Water Gun game had a slight bug where the balls
being shot would spawn behind the gun and go through the water gun. I fixed
this and now the shooting looks great! Last, the Water Gun game had some stale
code from the beginning of the quarter that result in some weird controller
behavior when relating to the new controller scheme I implemented last week. I
took the old code out and fixed the places that broke after taking it out.
Water Gun, Press, and Quiz should be ready to ship now!
(4 hrs)
My last
major task for the week was to rework the initial welcome/controls screen. This
is the screen that players first see and use to define who is player 1 and who
is player 2. I brainstormed with the group at our weekly meeting to decide what
information the screen should convey. After a couple iterations I found that
the screen shown below is the best version. I reworked the screen to get the
logo in it, add proper controls where the players should be looking, and even
told the aliens where they should start paying attention to. I had to make
control images from bits and pieces of other controls that Angela had made. I
just Photoshopped them together. The goal of this layout is to get the humans
and aliens looking in the correct spots from the start of the game! After we
play test this version I hope that my intuition is correct.
(1.5 hrs)
Content Positive
(Duplicate hours from above):
-
I fixed Space Aim hit boxes, movement, and
controls bugs were fixed (1 hr)
-
Numerous Water Gun game bugs were fixed by myself
(Button mashing, shooting, waves, controls…). The Press and Quiz games got some
added audio effects by myself. They also had their code reworked to display the
new controls on the dashboard instead of text. (4 hrs)
-
I reworked and created the new control
screen/welcome screen scene(1.5 hrs)
Content Negative
-
None
Total Hours for the week: 6.5 hrs
GDC Vault Post Mortem
Reaction:
I chose to watch the Among Friends
– An Uncharted 2: Among Thieves Post-Mortem from the GDC Vault. The game studio
behind the game is Naughty Dog. I’ll give the general layout that Naughty Dog
chose for the hour long talk and then give my analysis, take away, and reaction
to it. The general flow could be summarized as follows:
1. Introduction to the studio and game (Who they are and where they’ve been)
2. Idea and direction of the game (Where the team wanted to go with the game)
3. Preproduction and concept designs (Ideas that the team wanted to implement)
4. Macro design and layout of the game as a whole (High level game layout and flow)
5. Full production of the game and micro design (Methods for full production both art and code)
6. Methods used for full production and organization (Development models used – 1 week sprints!)
7. Technical Challenges and how they overcame them in production (Art and Code)
8. Analytic tools and methods used to test and gain data from testing (How they collected data on the game)
9. Play testing methods along with example test data gathered (How they tested the game in alpha and beta stages)
10. Final conclusion and turnout of the game (Obviously it was a huge success)
1. Introduction to the studio and game (Who they are and where they’ve been)
2. Idea and direction of the game (Where the team wanted to go with the game)
3. Preproduction and concept designs (Ideas that the team wanted to implement)
4. Macro design and layout of the game as a whole (High level game layout and flow)
5. Full production of the game and micro design (Methods for full production both art and code)
6. Methods used for full production and organization (Development models used – 1 week sprints!)
7. Technical Challenges and how they overcame them in production (Art and Code)
8. Analytic tools and methods used to test and gain data from testing (How they collected data on the game)
9. Play testing methods along with example test data gathered (How they tested the game in alpha and beta stages)
10. Final conclusion and turnout of the game (Obviously it was a huge success)
My main reaction to the overall
presentation is that game developing is incredibly fast paced and it’s
difficult to organize almost anything. By the time production begins the team
is on such a tight schedule that everything is on either a daily or weekly
basis. The developers made a point of saying that at some point talking about
what to implement needs to turn into actually implementing it. They claimed
that this is the best method of game development. Simply implement as many
things as you can and see what works and what doesn’t. You can’t just keep
things on the whiteboard or on paper.
A point that I felt deserves being
discussed is that fact that they seemed to only go heavy on play testing at the
end of the game’s development. This is different with regards to how we play
tested on game. We play tested in grey box stages. I’m not sure which is the
best, but it seems like they just internally play tested during the early
development stages.
When they discussed preproduction
I found it rather interesting that the simple most important deliverable from
preproduction wasn’t any GDD or anything like that. It was more of a high level
abstract layout of how the game would flow from start to finish. This gave the
team the ability start breaking our tasks into chunks based on levels and gauge
how much team was needed for each section.
Time management and estimation was
an interesting topic that was peppered throughout the talk. The team made
several points that showed just how inaccurate time estimates can be. They cost
the team significant production delays and ended up having to wait on either
artists or programmers to finish certain sections. Eventually they had to build
their work schedules around these pieces that took the longest to make. Time
estimation is something our own team has learned that is critical to timing the
deliverable of any game. It’s interesting to see that even professionals
struggle with it.
The last section of discussion
that really stood out to me was how even within this face paced development,
the team was able to take time to optimize the game. Usually from my experience
at Drexel, optimizing the game is almost an afterthought. The team specifically
set aside time to make sure that each level ran at a consistent 30FPS. They
were thinking entirely about how the end user would experience their game. In
contrast to the games I’ve made at Drexel, the teams usually don’t think as far
as pleasing the end user since the games are done at the end of the term. GMAP
377-378 are slightly different though since the games will be kept on the
motion base.
In conclusion, the Naughty Dog team
created an excellent game and the development of the game was not exactly
organized, but was directed enough to get to the finish line. Ultimately it was
an excellent game that tackled many development challenges that were explained
in the talk.
