# Individual Recording

Almost done y'all. You just need to record a video of yourself speaking about the questions within the "Team" section of the [demo](https://www2.cs.duke.edu/courses/compsci308/current/assign/04_final/part5.php)page. Try recording with zoom so we cah get a more consistent quality and let me not have to learn how to deal with different resolutions lol.

When you're done recording your video, upload it here:

https://drive.google.com/drive/u/1/folders/1B--xZfKr20JJhWlg_TvSNF3fpBWJ63qQ

lmk if the link doesn't work, I gave share access to the same gmails we used yesterday.

Here are the questions you should answer:

### Scrum

> Individually, share one thing each person learned from using the Agile/Scrum process to manage the project.

Oliver, could you also answer the question in addition:

>contrast the completed project with where you planned it to be in your initial Wireframe and the initial planned priorities and Sprints with the reality of when things were implemented

### Time Line

There are 2 questions, we all have to answer both.
1. > How each person was involved or learned about it later

Talk about how you responded to ~~each of the events~~ I think we should only talk about one, in the interest of time, listed on the [time line](#Time-line-information)

2. > Individually, share one thing each person learned from trying to manage a large project yourselves.

### Culture

> Individually, share one thing each person learned about creating a positive team culture.

I'll answer this in addition:
>describe specific things the team actively worked to improve on during the project

### Team Contract

> Individually, share one thing each person learned about how to communicate and solve problems collectively, especially ways to handle negative team situations.

Robert could you also answer:

> revisit your Team Contract to assess what parts of the contract are still useful and what parts need to be updated (or if something new needs to be added)

## Time line information

Talk about how you responded to each of these. You can use some of the stuff I wrote down about each if you would like

1. Lost a teammate

Earlier on in the process, after the first demo, one of our teammates couldn't
continue with us. We were fortunate to have that happen earlier on so that we
could reorganize the project to suit that.

2. API Redesign

After we lost our teammate, the person assigned to work on his portion of the
project got very nice ideas on designing ways for the internal backend API to
interact. We were already fairly set on the API design we had before, but
decided to go ahead and make the change. This required a lot of work on the part
of creating the change (moving from data and logic in one class to separate).
This required a lot of explanation for the entire team because this would alter
a lot of the internal backend APIs. Overall, however, this made the job of
updating the state of objects much easier since we had classes that could update
each game object based on the data that they tracked for that object.

(for example an object that is supposed to fire a gun with a specific bullet
type can do so in a potent way.

3. Engineering classes

4 people on this team are taking project based engineering courses, and this
meant that a lot of us ended up having our time split between finishing an ECE
project and this one, especially towards the end of the second sprint. To
accomadate for this and the increased business we started meeting more
frequently for shorter intervals. Some of us would meet in the morning for an
hour and some of us at night and we'd try to keep topics focused so people could
continue doing what they needed to for other courses also.

4. Obscure bugs

The day of the second sprint presentation we wanted to add on one more feature
which should've taken no more than 5 minutes to hook together. Because we
heavily use reflection, strings become a very critical part of the code and
source for bugs.

We had one particular issue in which everytime we tried to instantiate a class
through reflection its type kept showing up as the base or super class instead
of the subclass which had the needed data.

We worked from 10AM to around 2PM trying to figure out where the problem might
have lied. This required every teammember since we were walking through the code
entirely to try and find whether problem area was in how collision events were
triggered, how systems accessed data, how we used reflection.

It all came down to us missing an 8 letter word before the base class
(abstract). Because we didn't declare a class as abstract it did not through the
necessary errors when we instantiated it directly using reflection. We had
already gone 10 pages deep into learning about type erasure and compiler
technology before finding out the simple, statuc solution to our bug.

Being able to debug things such as this as a team was very critical as we all
needed to bring our understanding of how our specific parts were implemented in
order to efficiently assess where problems may lie.