Frictional Game Wiki

Link to this comparison view

--- hpl3:game:guides:scripters_guide [2013/07/19 13:16]
thomas
+++ hpl3:game:guides:scripters_guide [2014/11/12 11:38]
thomas [Code Structure]
@@ Line 60: / Line 60: @@
   * Press F3 to speed up the update rate in the game. This is especially useful to quickly playing through conversations, long events, etc when testing.
   * Press F7 to go into spectator mode. This allows you to easily move around in the map. Hold down shift to go extra fast.
-  * Press F2 to pauses the game. This is nice to use with Spectator mode and you can closely inspect something so look for bugs and make sure it plays out like it should.
+  * Press F2 to pauses the game. This is nice to use with Spectator mode and you can closely inspect something to look for bugs and make sure it plays out like it should.
+===== Code Structure =====
+Since a lot of people will be working on the same piece of code it is important that the same structure is maintained. This way it makes it easier for people to find what they need to do to change something.
+//Note: In the code below, spaces are used to indent, do NOT use this, use tab instead!//
+<code c++>//--------------------------------------------------
+/*Place any global values here. These must be const variables as they will not be saved*/
+/*This is also the place for enums and classes, but these should be avoided whenever possible*/
+//--------------------------------------------------
+class cScrMap : iScrMap
+{
+	//--------------------------------------------
+	//////////////////////////////////////////////////////////////////////////////////////////
+	// ==============
+	// MAIN CALLBACKS
+	// ==============
+	//{///////////////////////////////////////////////////////////////////////////////////////
+	//-------------------------------------------------------
+	/*OnStart, OnEnter, OnLeave, Update (avoid this), OnAction (debug only), OnPlayerDead, etc are here.*/
+	//-------------------------------------------------------
+	//} END MAIN CALLBACKS
+	//////////////////////////////////////////////////////////////////////////////////////////
+	// ==============
+	// MAIN FUNCTIONS
+	// ==============
+	//{///////////////////////////////////////////////////////////////////////////////////////
+	//-------------------------------------------------------
+	/*Put any variables that are used in more than one scene here.*/
+	//-------------------------------------------------------
+	/*Put any functions that are used in more than one scene here.*/
+	//-------------------------------------------------------
+	//} END MAIN FUNCTIONS
+	//////////////////////////////////////////////////////////////////////////////////////////
+	// ==============
+	// SCENE X *NAME OF SCENE*
+	// ==============
+	//{//////////////////////////////////////////////////////////////////////////////////////
+		 /////////////////////////////////////////
+		 // Scene X GENERAL
+		 //{//////////////////////////////////////
+                 //-------------------------------------------------------
+		/*Put any variables that are used by many events in Scene X here.*/
+		//-------------------------------------------------------
+		/*Put any functions that are used in more than one event in Scene X here.*/
+		 //-------------------------------------------------------
+                 //} END General
+		 /////////////////////////////////////////
+		 // Event *Name Of Event*
+		 //{//////////////////////////////////////
+		 //-------------------------------------------------------
+		 /*Put any variables that are only used in Scene X, Event X here.*/
+		 //-------------------------------------------------------
+		 /*Put any functionsthat are only used in Scene X, Event X here.*/
+		 //-------------------------------------------------------
+		 //} END Event *Name Of Event*
+	 //} END SCENE X
+	 /////////////////////////////////////////
+	 // ==============
+	 // TERMINALS
+	 // ==============
+	 //{//////////////////////////////////////
+		 //-------------------------------------------------------
+		 /////////////////////////////////////////
+		 // Terminal *Name Of Terminal*
+		 //{//////////////////////////////////////
+		 //-------------------------------------------------------
+		 /*Put any variables that are only used Terminal here.*/
+		 //-------------------------------------------------------
+		 /*Put any functions that are only used Terminal here.*/
+		 //-------------------------------------------------------
+		 //} END Terminal *Name Of Terminal*
+	//} END TERMINALS
+}
+</code>
+**Note1:** \\
+It is OK if terminals use variables that are scene or event specific!
+**Note2:** \\
+Have snuck in some { and } to make code folding for sections possible.
+**Note3:** \\
+Remember to always separate functions with a comment line, like this:
+<code c++>void Func1()
+{
+}
+//-------------------------------------------------
+void Func2()
+{
+}
+</code>
+==== Naming Conventions ====
+A few naming conventions for map scripting and level building:
+=== Areas ===
+Name trigger areas in the level Trigger_xxxx to make them easier to find.
+=== Sequences ===
+Name sequence functions in your map script Seq_xxxx
 ===== Design =====
@@ Line 108: / Line 258: @@
-==== Rules ====
+==== Foundational Rules ====
 **No Puzzles**\\
 Do not think of our puzzles as such. Think of them as //Activities// in stead. This is very important to keep in mind as they are not meant to pose a challenge but to make the player feel more part of the world. The player might still be required to think, but we do not want to end up in a "guess the designer" type of gameplay. It should feel natural and the player should "solve" any activity by simply just trying enough. For instance in Amnesia you can break down a wall by throwing a rock at it or simply clicking on it a lot. In either case the player has made a proper attempt at breaking down the wall and needs to be rewarded. Being streamlined, intuitive and coherent comes way ahead of being a satisfying problem to solve.
-**The 4 Layers of puzzles**\\
-Every puzzle has been designed with a 4-layered approach in mind. It is important that you know how this process works as it can be good to have in mind when implementing. The purpose of this design is to make the act of solving a puzzle feel highly connected to the game's narrative. Solving a puzzle should not feel as going through required obstacle. It should make the player feel as an agent force in the story telling process. Now for the layers:\\
-**1:** The first layer is simply the basic puzzle. It is important that players do not get stuck at it, but player should not feel spoon fed either. Some kind of thinking and/or action needs to be required. Usually a puzzle blocks the path forwards and/or makes them fully explore an area.
-**2:** In the first layer the puzzle is merely there as an obstacle. The second layer adds a narrative reason for the player to solve it. There needs to be some kind of mystery or narrative tension that solving the puzzle will achieve, and it is okay for it be a side thing. For instance, by opening a door you might not only open be able to progress but also give air to a dying man.
-**3:** This layer adds a narrative that is connected to solving the puzzle. While doing the required actions, the player is told a story that has something to do with the puzzle. For instance, while opening a door, you might find out (through items found and dialog) that it was blocked to keep monsters out. It is even better if this layer connects with the second one, eg. the dying man was the one who blocked it.
-**4:** The fourth layer is the hardest one and cannot always be pulled off. It is about the puzzle maintaining and contributing to the current mindset. This means that the previous three layers should help encourage the player to think in a certain way. Let's say we have a game where the monsters are able to impose as the ones that they kill. Players will never trust people they meet until they are sure they can be trusted or not. Given the previous layer examples, this layer might be that the player is not sure whether the dying man is a monster or not. Is he simply tricking the player to open the door and let more monsters inside? Now the players does not just take in the story in a passive way, but base their tactics and thinking on it.
 **Always Interactive**\\
@@ Line 131: / Line 270: @@
 **Physics When Possible**\\
 Do not "hard-code" behaviors, but try and use physics when ever possible. This will also allow the player to experiment more and to allow a great set of possible solutions to activities. Beware that physics can be very unruly and make sure that there are restraints on what can be done. When using physics you really need to test a lot.
+==== Specific Guidelines ====
+**Readable items must have consistent placement**\\
+When placing things that can be read, such as notes, books, newspapers, pamphlets, etc, it is very important to follow strict rules on this. We want the player to figure out by simply looking, what is possible to read and what is not. The player should not need to go pixel hunting. Here are the two basic rules for this:\\
+) Readables lying by themselves can always be interacted with.\\
+) Readables that can not be read, bust be in groups; piles, stacks, rows, etc.\\
+Also make sure that the colors on the readables that are slightly more saturated than the group ones. The only exception for this is scraps of paper, which are possible to have lying by themselves. But these can not have any longer text, but only pictures, diagrams, etc with some small written notation. They must also feel crumbled and fairly useless.
+**Longer must be confined to single lang entry**\\
+Any longer text for notes, descriptions, books, etc must be inside a single lang entry. They cannot be spread out over several entries for any reason. When having a single lang entry, it makes it a lot easier to maintain and translation gets easier.
+=== Books ===
+For books, we can show the front, the back, or an interesting page in the middle (swapping the model lets us show an 'open' version).
+  * If the back, then we show text of blurb
+  * If the front, then we just show title, author & whatever
+  * If somewhere in the middle, then we show an extract from the book.
+The key thing to remember here is:
+"If the protagonist picked up this book, which bit would he be most interested in?"
+i.e. it's unlikely we'd show an extract from the middle, unless it's critical to the protagonist's current plans e.g. the instruction manual for a device he's interested in or something.
 ==== Further information ====

Frictional Game Wiki

User Tools

Site Tools

Page Tools