The purpose of this Devlog is to show our growth, challenges, and how we solved problems. The games we make are aimed at showing our growth and/or showing our knowledge. Demon Party is a text based game which was focused on demonstrating a system. Thank you to Alexander Brazie for providing us with guidance and an understanding of various game design concepts and processes which are incorporated with this Devlog.

Design Goal

[Our Goal]
------------
We were interested in creating a game which focuses on the topic of games and education. More specifically, a game which helps users learn how to better type on their keyboard. We wanted to focus on finding a way to make learning how to type fun, which we accomplished through visual feedback which results from a player's input, such that they take control of a chef and controls their actions through typing. In addition, we wanted to add a higher learning curve for the game so that it will become more rewarding for players who begin to master their typing speed.

Knowledge We Gained

[Main Questions To Address]
----------------------------------
Did the player understand what is going on and what they needed to do?
Did the player care about what is going on?
Did the player have a response to what they needed to do? Are those responses enjoyable?
Does it all fit together? Did we target the right things for the right audience?

[Introducing New Features]
--------------------------------
Present a concept.
Make it safe to experiment on.
Test on it.
Escalate (develop it further) and permute (change it up/make variations).

[Communicating With The Player]
----------------------------------------
All communication tells you about the one communicating. The tools and mechanics provided to the player tells them about the experience the developer is trying to provide.

The communication is for the other person. What the developer creates is for their audience, to communicate what they want the player to experience.

When reaching out to the audience, we are appealing to those who want to win and those who want to experience the game.

[Responses]
--------------
Strategic Response: Players think about the impact of their choices and have agency over their response.
Emotional Response: Player develop a feeling as a response to something.
Immediate Physical Responses: Player respond to a stimulus.

Challenges

[Improving The User Experience]
--------------------------------------
In order to make sure the game was designed to improve the user experience, we implemented various HCI design principles. It is important that one doesn't determine if a feature or design should be excluded or included because "it is good to me" or "I don't want to make the change because its not something I like". It may not be good for you, but it may be good for the player.

Using Jakob Nielsen's general principles (heuristics) for interaction/user interface design:

1. Visibility of System Status: UI elements are always displayed and updated on the screen for the player.

2. Match Between System and the Real World: UI elements and mechanics are designed to follow real-world designs and logic such as a pocket-watch used to display the timer and a vertical bar used to display the meter. In addition, text is highlighted green when correct and red when incorrect, an appropriate use of colors.

3. User Control and Freedom: Users are able to hit backspace to delete incorrect letters or press enter after typing something incorrect to reset the input.

4. Consistency and Standards: The gameplay loop is consistent such that they player can expect to have to type out another sentence after their current sentence.

5. Error Prevention (not yet implemented): The user interface element which the player types input to will have a cursor flashing to let them know that  the game is a typing game rather than having them wonder what form of interaction is used.

6. Recognition Rather than Recall: The required input is always displayed for the player to see. Previously, players would have to remember the various commands to type in which was changed.

7. Flexibility and Efficiency of Use: The player can input text at any time without having to use the mouse to select the text box.

8. Aesthetic and Minimalist Design: The user interface is displayed on the left side of the screen with the game world on the right side. This help the player quickly find what they are looking for rather searching around the screen to find a specific UI element.

9. Help Users Recognize, Diagnose, and Recover from Errors: Incorrect text input is highlighted in red and is deleted if the user presses enter on it.

10: Help and Documentation: How to play page provided on the main menu.

[Satisfaction]
---------------
In order to maintain player satisfaction, it was important to make sure that both winning or losing felt fair to the player. Whether the player wins or loses, the meter which determines the end condition is designed to help motivate players to replay the game and either beat the game faster if they already won, or replay to improve their typing speed to get the meter higher.

[Adapting To Change]
-------------------------
Prior to the game jam, our idea for this game was to be an RPG dungeon crawler in which combat and player interaction was handled through text inputs. One example scenario for how combat might be handled would be by parsing the user's input into separate parts such as "(action) (weapon) at (enemy)" --> "swing axe at rat". We also planned to have combat done in real time which adds a level of difficulty by requiring players to quickly type in their actions, pushing them towards learning to type faster.

Once the game jam started, we were given the theme of celebration. We decided to change keep our game dungeon themed and created a scenario in which demons have successfully taken over the human realm, with the player taking control of a chef who must serve food to the demons who are "celebrating" their victory. We decided to change our game idea to be more scripted such that the player will type input based on a prompt.

Finally, we changed our game idea to be more friendly and decided to put the player in control of a chef at Benihana during a Halloween party, serving children dressed as demons. We decided to expand on the mechanics by adding a meter which determines whether or not the player wins or loses. The meter slowly decreases and as the player successfully types input, the meter will go up. By the end of the game, if the player is above a certain threshold, they will win. Below the threshold, they will lose.


[Team Growth]
-----------------
While our team worked very well together, most of the problems we had during development came down to communication issues. At some points, certain features were created without knowledge to others which made those unaware fall behind. In addition, there were some problems using GitHub since their were some situations where changes to the same script or scene were pushed which caused merging conflicts.

As the team leader, Karim Najib, I take the responsibility for the communication issues we had experienced. For future projects, I will focus on making sure issues like the ones we experienced are minimized by creating a way for users to keep one another updated on progress or what had been done while also talking with team members about various logistics to avoid conflicts in repositories.