Following the previous post, and still according to this design process, let’s move on to the preliminary design document.
This document lists the features of the game, going into more detail than the Design Treatment. Next step will be to start prototyping.
Preliminary Design Document of “Project D: A Brutally Realistic Dating Sim”:
Technical specifications: frame rate can be kept low, as there will be no animation. Good resolution.
Backstory: The Guy really wants a girlfriend. Fortunately, the God of Dating has heard his prayers. After magically perfecting his looks, confidence, and body language, the Dating God sends the guy on his way to his challenge: pick up a girl in the street.
Cast of characters:
– The Guy, aka [player_name]. Wants a girlfriend, but sucks at it. Has great looks, confidence and body language thanks to the Dating God.
– The God of Dating, he went on Earth to find a champion.
– The Girl, aka [random_name]. Walking down the street when approached by The Guy. She is a [random_occupation], likes [dogs/cats] and [random_hobby]. She is single.
When starting a new game, the player will be presented with a short description of the “story”. He will then immediately start interacting with The Girl.
The interface will consists of a Dialogue Box, The Girl’s picture, answer buttons, and three gauges.
– Dialogue Box: will display The Girl dialogues, and The Guy conversation choices.
– The Girl’s picture: static picture, facial expression will change depending on the conversation
– The Gauges: Interest / Friendship / Desire. They will vary depending on the conversation choices.
The player chooses conversation options by tapping them. This will affect the gauges and conversation flow. Different endings will be achieved based on the player’s choices (get a number / get a number but she never replies / friendzone / run away).
Three things need to be tested:
– Buttons location: the buttons will either be located separately from the dialogue box, or will integrate the answers directly. User testing is necessary to find which one is more usable.
– Orientation: The UI is horizontal for now, but putting it vertically could have benefits: more space for buttons, more comfortable for users. Again, this needs to be user-tested.
– Values: As of now, the user has no idea on what each answer’s result will be. This is nice from a teaching point of view, but could be problematic. A solution would be to have the possibility to turn “hints” on and off.