Designer_Devlog_4

This was an incredibly impactful sprint for our game! We went through some pretty solid design changes to improve the look and feel of the game significantly. Going into this sprint, we had an alpha build, but it did not look anywhere near polished enough for our taste. We had our core game loop established and the game was playable, but it felt unpolished and lacked a good amount of art.

As a designer, I decided to go through the game and look for any way that it could be visually improved to look more professional, even without having our animations implemented yet. 

What I found was that the orthographic camera makes a huge impact on the look of the game and it seems to suit the style of the game beautifully. This led to the first design change that was made. Switching to the orthographic camera led to some necessary changes in the level design. The level needed some restructuring and the players approached the game differently. It helped the game a lot, but there was still more to be done. From here, I found that players were having a noticeable lack of depth perception with the new angle. They could not tell how close they were to objects or how far away things really were. 

This led to the next design change, which was switching the camera to the classic isometric angle. This change was huge! It instantly changed the look of the game and made it feel more professional. It allowed players to see depth much more clearly and gave them a clear view of the exit points in the level. With some more minor changes to the level design, it ended up looking so much better than it had before. These changes to the design made such a significant impact on the look of the game that we knew they needed to be kept, but this introduced a new design problem for me to solve. When changing the camera to this angle, it broke the way that our movement system had been set up and made it very hard for the player to move in the direction that they thought their character would move. This forced me into making an important design choice. Do we continue with the new and improved look, at the risk of costing our programmers a significant amount of time, or do we keep the older, less polished look, in order to keep the game in a working state and free up our programmer to work on other user stories? This was a very difficult decision for me to make as a designer. I had to evaluate the worth of this change and whether or not its impact on our game systems would be too much to handle with regards to our scope. In the end, I decided that we would continue forth with the older look in order to avoid putting ourselves into a crunch situation, but I also spoke with my programmer, Alex, on the side. I mentioned the problem I was facing to him and that I didn't want him to have to spend too much time trying to solve the problem. We agreed that we would continue with the older look, but he would take a peek at the code and see whether or not it was something that we could get done without costing too much time. He blew me away by fixing the bug perfectly and getting the game to work in the new isometric angle. This was such a huge win for us as a team. We were all worried we would have to use a look for the game that we thought was worse, and this change put us right on track with our new and improved perspective! 

Another problem that I faced as a designer revolved around the farmers tools being limited resources. I wanted to find a way to manage the amount of crops that the farmer could harvest. In playtesting, I noticed that without restriction, the farmer would just run around harvesting anyone that got in his path. When I broke the system down originally, I considered this possibility and decided that the best way to manage that would be by limiting the amount of harvests the farmer had. This sprint, I set up the harvesting limit and got it working. Immediately, the change forced farmer players to be much more decisive and put some thought into which crops they truly thought were human players. The problem arose when the farmer would run out of harvests. If the farmers tool is out of uses, how can he continue playing effectively? This created a hole that needed to be filled. If the farmer made enough wrong decisions, he would be forced to watch the player crops finish the touchpoints and escape successfully, and there would be nothing he could do about it. To solve this problem, I came up with a repair system that allows the farmer the opportunity to repair his tool and start harvesting again. I didn't want the farmer to be able to just repair whenever and wherever, though, because this would remove the purpose of limiting the harvester in the first place. To get around this, I decided that the farmer player would need to collect scrap, just like the crops, and they could then bring that scrap to a workbench to repair their tools. This solution made it so that the farmer could still continue to play and have a chance to win, even after using all his harvests, but at the cost of time. Time is a valuable resource in this game because the more time the farmer wastes, the more time the crops have to activate the touchpoints and get closer to escape. Now the farmer needs to make a choice, harvest recklessly until he needs to spend the time to repair his tools, or be selective in which crops he harvests so that he only uses the tool on player crops and does not need to harvest. This solution also created the opportunity for different playstyles to emerge. The full speed farmer that is trying his best to stop anyone in his way, and the precise and cautious farmer who takes his time in deciding which crops seem real.

I am very happy with the improvements we have made in this sprint and with my team's progress on their user stories. People seem to be motivated and excited to make new changes which is very exciting to see. As the designer of the game, I was very worried that my team might not be invested in the game idea, but everyone seems to be having a lot of fun with it and pitching more ideas. I am very excited to see where the game goes!