Saturday, May 2, 2015

Design Philosophy

So none of the programmers have developed games before, so when we met we talked a lot about the game, the process, version control and bit bucket. There was a lot of housecleaning like:
  • 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.
 The programmers had also never used Unity, so they had to take some time to get used to that. I explained to them my design philosophy, where we start with the core elements of the game and find the fun through rapid prototyping before we move onto the next feature. This ended up being a nice ideal, but in practicality it never worked this way.



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