Week of Preperations

This week was spent mostly preparing for Next week's 3to1 Studios: Slightly Touched game jam. This jam required all submissions to involve multi-touch, so much of this week was spent creating a gesture recognizer system. This week my team and I planned out the refactor that we will be starting the week after the game jam. I also spent a lot of time helping others with various miscellaneous tasks like teaching the basics of the UE4 material editor and helping to create a galaxy generator.

Misc. Side Projects

Gesture Recognizer

I wasn't able to make much progress on this over the week due to me focusing too much on one desired (but not required) feature. Basically, I spent a ton of time looking for a way to make a Blueprint event node with multiple execution pins. It turned out to be possible but it would require me to learn how to make a K2 node which I want to learn eventually; however, it would take too much time, and thus I had to settle for using a switch on enum instead. All of this time spent searching meant that I still haven't made much progress on the logic of the gesture recognizer, but I should be able to complete it over the weekend so that I can use it in the upcoming game jam.

Voidsinger

Refactor Planning

First, we discussed changing up how we use git to be more similar to its intended use. Previously, we had a unique branch for each person on the team and they would develop whatever they were assigned on that branch. They would also merge with anyone who said that it was safe to merge with their branch. This system was bad because people couldn't easily change tasks and it made the master branch mostly useless. It also means that it was easy for people to get sidetracked and when a branch got corrupted it was hard to find the latest stable branch. It was also hard to mix and match WIP features when developing reliant features. So we decided to make branches based on Issues. This means that whenever someone was assigned an issue on Backlog they would create a new branch for that issue and work only on things directly pertaining to said issue. This meant the people could easily tell what branches had what features. Once a feature was complete the person working on it would submit a pull request and merge into master deleting the issuing branch in the process.

Next, we discussed how everyone would review each other's code and suggested improvements before the start of the actual refactor. This would allow everyone to get a familiarity with everyone else's code as well as help find solutions that the original coder didn't think of.

We also discussed commenting, naming, and folder conventions. We didn't make much progress on creating a standardized commenting system but we did come up with a naming convention that went like this: AbrivationForFileType_RelatedFeture_(optional)SpecificPurpose. For example Tex_Hull_Corner. We also declined to base our file system on inheritance and related features.