Endings and new beginnings. Lessons to bring into the next chapter.
We have arrived! Well, sort of. The project is almost complete. We are working out the last of the bugs which means, this is the end of the road for this capstone project blog. This week we will be moving on from team performance to look at some more individually-focused takeaways and best practices that I found while working on this escape room challenge.
Tutorials First
Without watching Unity tutorials before starting the project, I would have really struggled. Throughout the process of the project I was reminded of how it is both time saving and frustration saving to look up resources about whatever task I am trying to accomplish before I tackle it.
Designate Design Time
I often have to remind myself to designate time just for designing classes, their interactions, and the logic of the code before trying to implement it. Especially, when I am starting out with something that is less familiar, I tend to want to jump straight to implementation. I think this is because I am not exactly sure how to start with something unfamiliar which goes back to checking out tutorials and researching to get some context before designing. Ultimately, setting aside design time saves a lot of time and refactoring later on.
Prioritize Features
It was easy to get distracted by what features could be possible and to start multiple features and not work out the bugs in any of them. Prioritizing and focusing on a particular feature until it was done was definitely important. This was especially noticeable in this project where the requirements were very open ended versus many of the projects from previous classes. The game could easily grow in size and complexity. Knowing what to prioritize and where to draw the line on features was important.
Take Breaks
I tend to have a hard time letting go of a problem when it’s not solved. Time and time again though, I come to a solution or an idea that leads to a solution when I take a break. Taking breaks more frequently when I get stuck tends to help move things along, but it can still be challenging for me to do.
Make a Test Plan
When testing programs and implementations, I have gotten in the habit of unit testing and being more systematic in my testing approach. Testing was different for this project though since you had to actually run the game and see how things were working together. This difference made my typical approach seem less helpful. I should have taken some time to thinking about how to be more systematic in my testing. This became more important as the complexity for testing grew. When I was more systematic and paid attention to the order of testing, I could do one run through of the scene instead of having to do multiple run throughs.
Commit Each New Feature
Going back to a previous version without a certain feature is much easier if you commit for each feature regardless of how small it is. For smaller features, I tend to not commit until I have a handful done which works fine if you don’t want to go back. It’s makes things more complicated though if you are trying to undo one of those small features. There is no easy way to do it.
Review Before Committing
I noticed I was doing a lot of commits to clean up after something worked. I tend to get excited when something works and then I commit it immediately. Then I go back and realize it needs either minor edits or fixes. Taking the time to review before committing would make for a cleaner git that’s easier to navigate. At the very least, I could be more consistent about squashing commits when there are a bunch of minor fixes or edits.
In Conclusion
Overall, the project process was a positive experience. The process clarified and reinforced best practices and design and implementation principles I learned throughout my time with Oregon State. As an added bonus, I had a great experience with the team. The skills I’ve learned in this program will serve me well in this new beginning as I start up a new career in tech.
Until we meet again… be a goldfish, y’all.
