This week, we continued working on our team management, specifically team contract and user stories.
Team contract is something that ensures no boundaries are crossed and no rules are broken while developing the game. It was written down after a discussion with everyone on the team and I shared it on Slack .
Work preferences are also really important when it comes to teamwork, so everyone present that day had an opportunity to share their strength and struggles with everyone else. it helped us understand what everyone’s work pattern is to ensure the project runs smoothly.
My work preferences aren’t very aligning with team work, but my flexibility and ability to communicate at any time of the day should make up for it. Everyone on the team has a problem with deadlines, but I think by regulating each other and keeping track of things together it shouldn’t be ass troublesome.
After the team contract and work preferences have been established, we moved on to finally mapping out our tasks for the project with user stories.
User stories are short statements from the point of view of the customer/player that puts their wishes into words. It helps the team figure out where they will be working together and which part of the game require group effort.
I’ve put in first three user stories on the board as other people struggled to understand what they were for, so I took the initiative of explaining and providing examples for others.
User stories ended up ding very narrative heavy, as was expected from a game where mechanics are simple and don’t take up much of game’s content.
The tasks everyone came up with are connected to each user story and intertwine with each other. The first task I have started was a narrative flow chart (apart from researching the GDD). Because it plays such a big role in the game, everyone was kind of relying on me to finish it by the end of week 3 to have a basic understanding of what we need to do.
This week, I have also done research on what types of narrative and flowcharts exist.
Embedded narrative
Embedded narratives are pre-determined stories. The game creators decide the narrative and the player follows their direction.
The game has a similar narrative every time it’s played. The player can’t influence cut scenes and backstory. Games with embedded narrative are usually very atmospheric, and the closest narrative to a linear plot. They’re also commonly single-player games, focusing on drawing the player into the storyline tension rather than interacting with other players.
Emergent narrative
Player interaction influences emergent narratives. There are still rules and structure to the game, but decisions by the player can change the direction of the narrative.
These games usually have ‘authoring elements’, meaning aspects of the game allow the player to either create or influence their world (and consequently their narrative). Players can often replay emergent narrative games to achieve different endings.
Evocative narrative
Evocative narratives are stories that rely on connotations – the memories, imaginations and knowledge of the player. This type of narrative uses imagery we already know to tell us story information without explicitly explaining it. You have preconceived ideas of what to expect when you see a waterfall, blood trail, or red barrel.
Evocative narrative is determined by both the player and the game creators, but dependent on the player. The game creators can try to add evocative elements, but it depends on the individual player as to whether they recognise these elements. Players may also bring experiences and knowledge to their gameplay that the creators don’t have, and form narrative through their own perception of the game. Therefore, all games contain evocative narrative, and the player may discover new narratives every time they play.
Enacted narrative
Enacted narratives rely on players developing their characters. Story elements such as power-upgrades and levelling up use enacted narratives. These narratives are usually in single-player games that emphasise character growth
From what I have found and read, our game is going to be a simple embedded narrative with a linear plot, because no matter what the player does, the outcome of the game remains the same. If we had more time to work on this project, I’d say that we would develop a game with emergent narrative, judging from the fact that Scarlett herself has mentioned that the provided plot is only one of the many possibilities.
There are two distinct kinds of flow narratives: linear and branching. From them come the two types of game plot: linear and interactive.
Linear narrative presents itself as unchanging, predicted story that the player has no control over. Basically like watching a movie.
Branching narrative is supposed to give the player a choice, and depending on what they choose or do, the outcome will change. However, there are also instances of the game giving the player a fake freedom of choice, where you have two or more options to choose from, but the outcome of your actions won’t change in the long run.
In a flowchart diagram there’re some basic types of nodes:
- Story start/end nodes represent the beginning or the end of a story.
- Story exposition nodes represent any story fragment conveyed to the players.
- Story choices represent any story decision. they can be of three types:
- Challenges are story choices that are based on player performance overcoming a conflict. Challenge choices always transition to failure or success story exposition nodes.
- Player choices are story choices based on the player will. The player chooses what to do.
- Random choices are story choices based on randomness or luck.
Soures:
https://www.gamedeveloper.com/design/story-flowchart-diagrams
Leave a Reply