Xavier Smith Week 12 PPJ

What Went Right

1. Collaborating on ideas.

While creative freedom was an important part of this project, that doesn’t necessarily mean everyone could just do whatever they want or have complete control over a mini-game. All of our games were run by the team as a whole. We would then come to a vote as to what alternative we’d go with in the case of a disagreement. Surprisingly this never became an issue, as most of the pitches for ideas and games usually resulted in team members adding even more to a game idea, or mechanic, resulting in a better game that we almost always agreed on. While there may have been times where some of us may have disagreed with the direction on an individual idea or game, there were never any hard feelings and we always respected final decisions of the team.

2. Covering each other’s weaknesses

Occasionally there would be a problem with a game or feature: be it a motion base error, a 3d model, a script or what have you. The person assigned to that particular task would have problems with. In such a case, there would always be another person on the team that could and did solve that problem. A concrete example would be the movement controls for Space Aim and Stello Says, where Chenghao and I initially had some difficulty getting the movement to work for a controller, and so David went in and reconfigured the controls for both games.

3. Creation of a modular system

As stated above, one of the huge goals for our project was a modular system, whereby new games could easily be added without having to redo much of the code. I and David did a lot of work to ensure that controls were set in a consistent manner and that this could be done easily in the future. The resources such as an easy to use timer and score keeper were available to just slap onto games so that members did not have to worry about having to mess with the timers and other common elements to get their games to work. Angela also created textures and materials that could easily be applied to more than one game for art.

What Went Wrong

1. Motion base

Being inexperienced with the motion base and having never made motion-based games before, our team ran into problems with the platform. A lot of time was spent debugging and smoothing out scripts and objects that influenced the motion of the Drexel Ride. One particular issue that gave us trouble was switching between mini-games. If the object that held the script governing motion base movement was destroyed, regardless of whether or not a new one was created it would cause the motion base to stop. Eventually a solution was found to prevent this and implemented in such a way that the fix could just be dragged and dropped into each mini-game. This again conforms to our idea of modular scripting and design.

2. Communication

Communication within the team, while vastly improved, was always a difficulty for our team. Initially our team communicated via e-mail, however this led to problems as certain members would not get some e-mails, and we would have to look back through dozens of e-mails if we wanted to find something mentioned a few days ago. This was solved by moving to Slack. However not all of the difficulties were resolved. There would still be the odd occasion where we simply could not get a hold of some group members or some messages remained unseen. This resulted in work being done by others that were not assigned to the task. Sometimes the task would be done by two individuals, but the original person would never tell the group that they had already done it. This will stop next term as it resulted in several people doing more work than was necessary.

3. Perforce

Our team had great difficulty in setting up version control for the project, and these issues persisted until near the end of the project. We were slightly late in setting up Perforce, instead opting to use Google Drives to zip and rezip the project for the first week of production. When we were all moved to Perforce, some members had trouble setting it up correctly and that also took an extra week to get everybody on board and familiar with the software. Additionally, we would constantly run into errors when pushing, with scripts missing/conflicting, textures and materials not showing up, changes being undone etc. Towards the end we achieved an understanding of the platform and learned to use it with minimal error, although issues with textures still occurred somewhat frequently.