Frictional Game Wiki

Link to this comparison view

--- hpl3:game:guides:scripters_guide [2013/02/28 08:16]
thomas
+++ hpl3:game:guides:scripters_guide [2014/11/12 11:38]
thomas [Code Structure]
@@ Line 7: / Line 7: @@
 At least one time, you need to do the following:
-  * Make sure that you have read the [[stash:depth:quick_summary|Quick Summary]] and all of the linked to resources. You must feel at home with the design principles we want to use and with the mood/themes of the game.
+  * Make sure that you have read the [[stash:depth:design_document|Design Document]]  You must feel at home with the design principles we want to use, the general outline of the player's journey and with the mood/themes of the game.
-  * Check out the [[stash:depth:design_document|Game Overview]] document. You can skip the gameplay and major elements sections as they are out of date (there are warning signs). There is tons of info here, and you do not have to remember all, but good if you have a somewhat deeper knowledge of what the heck is going on.
-  * Have a look at the [[stash:depth:player_journey|Player Journey]] document too. It is quite messy and not very easy to read and not super up-to-date. But just glance through to get a feel for the scope of the game.
   * Play all three Penumbra Games and Amnesia (do not forget Justine expansion) so you get a feel for what kind of activities are possible.
 Every time you start on a new map, you need to:
   * Make sure to read the design carefully and make a list of the things you need to implement. It is good to figure out some kind of priority order and what will be the hardest tasks from the get go.
-  * Have chat with Thomas and talk through the design of the level. Make sure there is nothing that you are unsure about. Remember that Thomas might sometimes forget these meetings, so nag at him. You do not want to start before having done a walk-through.
+  * Have chat with Thomas and talk through the design of the level. Make sure there is nothing that you are unsure about. Remember that Thomas might sometimes forget these meetings, so nag at him. You do not want to start before having done a walkthrough.
-  * The most important part of the design for  level is the Goals section. Make sure you have good grasp of these, as these should be in back of your head for every decision.
+  * The most important part of the design for  level is what it is meant to achieve in terms of narrative and mood. Make sure you get this.
 ===== Programming =====
@@ Line 31: / Line 29: @@
 This lecture is a must view: http://the-witness.net/news/2011/06/how-to-program-independent-games/
-Also important is that you structure your code in a way so that other people can easily see what does what. It is very common that other people will want to tweak something or just add some extra effect. It must be easy to see where this occurs. The engine supports TODO message pop-ups (''cLux_AddTodoMessage(..)''), so use that in all places where some effect/sound/whatever is required to be added. Despite adding a todo, you should still have your own temp assets. For instance, sometimes sounds are vital to see if an event works or not.
+Also important is that you structure your code in a way so that other people can easily see what does what. It is very common that other people will want to tweak something or just add some extra effect. It must be easy to see where your different events occurs. The engine supports TODO message pop-ups (''cLux_AddTodoMessage(..)''), so use that in all places where some effect/sound/whatever is required to be added. Despite adding a todo, you should still have your own temp assets when possible. For instance, sometimes sounds are vital to see if an event works or not.
 ==== Philosophy for level scripting ====
 A level script should not be thought of as file for programing. A level script should be written and read as though it is a story (or a sequence of events if you wish).
@@ Line 62: / 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 76: / Line 224: @@
 **0.30**\\
-Notice the fly particles systems and stuff like that? Try and add stuff like that where you think it works in order to increase the mood. This of course not your first priorty but I want to mention it because stuff like this is part of your work.
+Notice the fly particles systems and stuff like that? Try and add stuff like that where you think it works in order to increase the mood. This of course not your first priority but I want to mention it because stuff like this is part of your work.
 **0.36**\\
@@ Line 92: / Line 240: @@
 **2.30**\\
-The metal breaks as you climb it, this is good stuff for the engagment and also make the world feel more alive. Feel free to add unexpected (but realistic) events to the player's interaction. The plane falling down afterwards is also good. But if you do it in cut scene, you are doing it wrong!
+The metal breaks as you climb it, this is good stuff for the engagement and also make the world feel more alive. Feel free to add unexpected (but realistic) events to the player's interaction. The plane falling down afterwards is also good. But if you do it in cut scene, you are doing it wrong!
 **2.50**\\
@@ Line 107: / Line 255: @@
 **7.30**\\
-When the game opens up like this it is important that there is not only a single hotspot for the player to find, but that one can complete the task or find interesting info in many places. I think this is done nicely here with the deers showing up where ever you are.
+When the game opens up like this it is important that there is not only a single hotspot for the player to find, but that one can complete the task or find interesting info in many places. I think this is done nicely here with the deers showing up wherever you are.
-==== Rules ====
+==== Foundational Rules ====
 **No Puzzles**\\
-We do not have puzzles in this games. We have //Activities//. 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 require 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.
+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.
 **Always Interactive**\\
 Whenever possible, the objects in the environment needs to be interactive. For instance, a locked door should be able to move so the player can notice, by interacting, that it cannot be opened. Another examples is that the player might be able to grab and swing lamps that hang down from the ceiling. We want the player to feel part of a real living world and the interaction is the way we do this. Never waste an object that can be made interactive.
-**No Death**\\
+**No Trial and Error**\\
-The player cannot die in this game, there is always some other event. Mostly this is stated in the design, but important to keep in mind. If there is something the player might do that is usually followed by death then you need to figure out some other way around this. Remember invisible walls is not a good choice here, instead try and have some interesting consequence.
+Never have challenges where failure means restart. Examples of this is just about any puzzle in Limbo. We want the player to a smooth narrative experience that always moves forward. We do not want to to be stuck repeating the same actions over and over.
 **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 ====
@@ Line 126: / Line 297: @@
 http://frictionalgames.blogspot.se/2013/02/puzzles-what-are-good-for.html
+http://frictionalgames.blogspot.se/2013/03/puzzles-and-causal-histories.html
 http://frictionalgames.blogspot.se/2013/01/goals-and-storytelling.html
 http://frictionalgames.blogspot.se/2012/12/introduction-i-recently-started-to-play.html

Frictional Game Wiki

User Tools

Site Tools

Page Tools