🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Plot writing style

Started by
5 comments, last by Cpt Mothballs 15 years, 4 months ago
I'm writing the plot for my game (a space sim ala X-Wing / TIE Fighter) in a sort of a story format so that I know what happens and when. I've never written one before and I'm finding myself rewriting it because I don't know how much detail I want to or should include. I keep writing things like "The player is then called to escort a transport. The transport is attacked by ENEMY_NAME and the player defends the transport. It is not known to the player at this time who the enemy actually working for". Then I edit it and remove the bits about the player defending the transport, because thats what the mission is about and the player has to complete it to progress, so it really is assumed. Then I edit out other details about what the player does and doesn't know and what else is going on in the galaxy relevant to this story. Then I go back and add bits. I annoy myself like this. I'm just wondering if anyone has any suggestions as to what would be worth including and what would not so I can stop myself constantly altering the document for no real reason!
Advertisement
I don't know your ful context, but I think in general you need to distinguish between what the player does and what the player is told to do.

The things worth including, in your plot that is organized as missions:

1) How and what the game includes in a mission
2) How the game presents the role of the player in the mission
3) How and what the player can gain/change in the mission
I think what I am trying to do is the lay out the story maybe like a screen play? I'm writing the the main events as if it were a novel and I'm in control of the main character (but even then my writing style changes from descriptive to practical and concise).

I am describing my missions seperately but I'm finding the mission overviews are very similar to what the plot says in many cases. I then have a details section that specifies what the player must do and what will happen after they succeed, such as enemy ships attacking and such and an asset list. This will probably be expanded to include exactly what the player can obtain if anything, after all this is my first game and it's just me and a modeller friend with very little time so I'm setting low goals for completion. Having said that, I've spent far too many years in feature creep / perfection land, and now I just want to make a game, and I realise a design document is probably the thing that is going to help me most.
I think if you have a main sequence of missions, you could write it like a screenplay, with variations and options indented so that you could skip reading them easily. How you draw the line between being descriptive, practical, and concise is not particularly important.

Example:

In this example, we assume that there is one main plot with some variables. You could change this to make it more complicated, but that is not the point at the moment. I just want to show what I think are good to include.

STAGING This is the list of facts on how the game composes the contents of the mission. This is the list of conditions that allows the game to know which army is fighting whom, where they are fighting, why they are fighting, and what they are using to fight.

BRIEFING This is the list of facts regarding how the game presents the situation to the player. This step is separate from composition precisely because the player does not necessarily know the truth of the situation. I think this is important to distinguish in your case. By listing it as a separate section, you don't need to have little notes to mark whether a sentence corresponds to a knowledge of the designer or the player. Although the title of this section if briefing, the presentation method is not limited to dialog or text, and you could distribute the briefing during the mission.

TRANSITION This is a list of facts on how this mission could end, and how other variables can be triggered. The victory condition of the mission could be different from that presented during Introduction. The Introduction could have presented the player a goal that is impossible to achieve, it could be up to the player to figure out what the goal should be. In this style, it is not necessarily to highlight whether the information in the briefing is the truth. The transition implies the available range of player actions.

I suppose this style is a "factual" style.


[== 0.1 - CHAPTER 1 ==]
[STG] Randomly generate the forces of A and B according to algorithm X.
Select the scout force of A and the supplies forces of B. The location
of the fight is L1.

[BRF] A Scouts attack the convoy of B. Officers of B shouts for help.

[TXN]
o Chapter ends when either force is eliminated from the map
o A force is eliminated when it is destroyed, or when it leaves the map
o The destroyed units are deducted from the total forces of A and B
o The player could capture a unit of A by leaving with the unit or by destroying the rest of force A

[== 0.3 - CHAPTER 2 ==]
[STG] Randomly select 30% of light units of A and add it to the scout units
that survived in Chapter 1. Randomly select 25% of light units of B as
defenders. If the player did not capture an enemy unit during Chapter 1,
add the survived force of B during Chapter 1 to the defender force.
The location of fight is L2.

[BRF]
o Show the player that forces of A are approach L2. The objective of the mission is to defend L2.
o If an enemy unit was captured, tell the player during a briefing that unit must be relocated to the headquarter.

[TXN]
o Chapter ends when either force is eliminted from the map by being destroyed or by having fled
o The destroyed units of deducted from their corresponding total force
o The fled units of B are flagged as "Fled".
o Update whether L2 is "Captured"

[== 0.5 - CHAPTER 3 ==]

[STG] The location is L3. Select the survived forces of A during previous
battle plus another 50% of unselected light units and 30% of heavy units.
Select 50% of unselected light units of B, 20% of heavy units of B, plus
the surviving convoy force if it was transporting the enemy unit. Place an
additional 20% of heavy units of B in unoperable state in L3. If B had
captured an enemy unit in Chapter 1, allow B to use its normal abilities.

[BRF]
o Show that the enemy is coming to L3
o If an enemy unit was captured, introduce its normal abilities and tell the player that it is operable
o The player is suggested to select part of the defending force to go to L2.

[TXN]
o Chapter ends when either force is eliminated from the map by being destroyed or by having fled.
o The destroyed units of deducted from their corresponding total force
o If B fled from the map, A absorbs the remaining unoperable units of B.
o If B fled, mark L3 as "Captured".


[== 0.7 - CHAPTER 4 ==]

[STG]
o Location is L2.
o Force A: 75% of existing light units.
o Force B: The selected forces going to L2 during Chapter 3,
o Force B: Add 20% of unselected heavy units of B
o Force B: Add any survived defender (including fled ones) during Chapter 2
o If L2 is captured, Force A takes the base, Force B takes the invader position

[BRF]
o Show the situation of the map.
o If L2 was captured, tell the player to retake the base
o If L2 was not captured, tell the player to defend L2.
o If the captured unit in Chapter 1 survives, introduce its special abilities.

[TXN]
o Chapter ends with elimination of either force by destruction or evacuation
o Total forces take their losses
o If L2 and L3 are both captured, end the game in defeat.


[== 0.9 - CHAPTER 5 ==]
[STG]
o Location: L4
o Force A: Select All
o Force B: Select All

[BRF]
o Show map of L4
o Tell the player that this is the final battle

[TXN]
o Chapter ends with elimination of either force from map by destruction or evacuation
o Total forces take their losses.



[== 1.0 - ENDING ==]

o If Force A is destroyed, show Victory Scene 1
o If Force A flees, show Victory Scene 2
o If Force B flees, show Defeat Scene 1
o If Force B is destroyed, show Defeat Scene 2
o Battle summary of the 5 fights with slides of the locations and forces
o Slideshow of all heros and units (both A and B) in the order of their appearance,
o Slideshow includes the number of enemy destroyed by that hero or unit type.


In this particular example, even if the force that the player controls is completely destroyed in Chapter 1, 2, or 3, the game still continues. Chapter 4 is the first chapter where the game could end if the player is defeated. This is not important to know. I am just showing that the structure is flexible to define this kind of effects without explicitely stating them.

[Edited by - Wai on February 5, 2009 12:46:07 AM]
I have written very linear stories and quests as a novel, like you are describing. It works well for linear gameplay. If you want to give the player many options to alter the story, or change the direction of the story, then the novel-method breaks down. But for simple, strict story outlines, novel style works well. Its the same as storyboarding sans the cool artwork.

Wai, that's pretty awesome and close enough to the kind of thing I'm looking for. Huge thanks.

kru, given that this is my first game and I'm a lone developer with a wife and kids and a day job who wants to finish his first game in his own lifetime, I'm pretty much going for linear style with a strict story. I have intentions (like we all do) of expanding to dynamic play more like what Wai has suggested if I ever make it to game #2. For now it's more about how to lay out my thoughts in a coherent manner without rewriting them every five minutes.

Thanks to you both for taking time to reply.
Really, if it's your first game, don't go for an epic storyline.

To be honest, if you want to get some experience down with development, just make a game, like Tetris or Space Invaders. Stories are hard to do right normally, finding the right pacing for one even in a linear game is hard.
Work on both skills separately first, then try to bring them together and make it even more awesome.

At least, that would be the thing to do if you want to make something you can take to an indie games festival at some point. But if you're in it for the experience of making a game, then I'd say doing what you're doing now is fine for a hobby.

This topic is closed to new replies.

Advertisement