---
# System prepended metadata

title: Team

---

# Team
- Galaga
- Galaga but when you get hit 2x enemies spawn
- Geometry Dash
- Mario (multiplayer)
- Mario v Goomba (reloaded)
- Smash brawl type beat

## Introduction

### What kind of game did we create?

- A sidescroller that can be manipulated to enable any kind of game with
  character movement and enemies

### What was the focus of this engine

- Create a way to make games easily creatable by defining general types and then
  overriding types when actually creating games. 

- Modeling the OOP structure within data files to allow for quick reuse.

- Separting data from logic entirely. The classes containing datafiles are
  separate from classes containing logic, this way we can focus the logic on
  managing data and reacting to it.

- Add *sane* defaults to all configurable options, this way using options
  doesn't require extensive knowledge of the options available.

### What was the focus of the GUI

- Seamless localization

- Event based API

- General components to create specific components

- Completely 

## What we learned


### Agine Scrum

**What I learned**:

Finding a moderate pace which can be kept up for an entire
project is much more important than being able to do a lot in the very
beginning.

### Time line

- 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.

- 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.

- 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.

- 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.



