- getting bitbucket and sourcetree set up
- using U of U servers to do so
- getting the unity file from Jinghui and into the programmers
- choosing production software, we used Slack, and a couple others, I don't even know what we ended up using.
One of my biggest disappointments of the game was that we didn't stay small and find the fun early on. There was a pressure to keep moving forward and adding features. According to the programmers, Dr. St. Germain needed them to show certain requirements at certain milestones throughout the semester. To me the milestones and features felt arbitrary and not related to game development. This meant that we spent a lot of time adding features before we fixed the bigger fundamental problems with the game. Pretty soon I realized I needed to be ok with this. Because of my schedule and the lack of abundant time I had, I couldn't devote as much time to the game to keep up with them, so at a certain point, if they needed to move forward and add features, then I tried to support them, and gave them the game assets they needed to do move forward.
We tried to fix the problems along the way, but there was always a pressure to keep moving forward and add features and levels. As a result, I don't think the core mechanics or design were ever truly proved out. I like what we accomplished, and the programmers put in a tremendous amount of work, but I think the game suffers from a lot of problems that are now a lot more complex to fix than had we fixed them early on.
This is disappointing because this was one thing I wanted to prove out at school. I had worked on enough games using the above described method, which has produced a lot of mediocre games. I was hoping this experience would be a little different, but I completely understand why it went this way.
No comments:
Post a Comment