Debugging Begins

Our first round of debugging (with the levels put together, that is) has begun. Unity will behave very oddly such as throwing a random error message. We've learned sometimes you just need to close Unity and re open the project (computers need breaks, too). We have also found that just because it works in one project, doesn't mean it works in the other. A good example of this was when Katherine pushed her dialogue branch (which Brayden pulled) and the dialogue box sprite did not show up properly in Brayden's project (it was showing as a red X). It turns out the reason for this is somehow the width of the sprite was set to negative so the main camera couldn't actually see it despite somehow being able to see it on Katherine's project.

Brayden and I have become VERY familiar with Fork and we have learned the hard way to communicate better before pushing/pulling and letting each other know what we are working on. I've never had an issue with communication, but when developing a game you almost have to give too much information to your partner.

Working with a partner instead of building the game solo (like an assignment) has been a whole new ball game and a true challenge on it's own. While Fork and git are relatively user friendly, they do take practice to get right. Brayden and I have spent countless hours on calls practicing pushing and pulling to make sure we don't lose anything and we are doing it correctly. I have come to understand why it takes game studios (even with large teams) so long to develop and publish games.

Another great thing about working in a team is sharing the load. I really thought I could make a game from scratch by myself, and having gone through this experience, I see now that there was really no way I could have (two brains are better than one!). At the very least, I think you should have one developer and one designer. While one person can accomplish it all with a different timeline, I think it was important for us to assign those roles so we had a clear direction and focus.

When dividing the load, we wanted to make sure it was done evenly. We were in constant discussion of what steps needed to happen next, how we were each feeling about our work load, what we were ready to take on, etc. We also checked in so that if someone was struggling with an assignment, we could re assign as needed to get the game done.

While this course has taught us a great deal about programming and game development, this capstone project taught us a lot about what it is going to be like when we enter the field and start working in a team. This project taught us lots of new things (UI/UX design, Dialogue controller/manager, State Machine-ception, etc.) and we have had a (stressful) blast making this game.

Attached is a photo of our poor hero being attacked by some of the enemies!