Map Generator Style Guidelines - Revision history

Maikel at 21:54, 21 January 2011

2011-01-21T21:54:58Z

← Older revision		Revision as of 21:54, 21 January 2011
Line 11:		Line 11:
	--*/		--*/

	// ''Short comment on what ~~the overlay~~ does.''		// ''Short comment on what this template does.''
	overlay ~~External~~ {		overlay Template {
	algo=rndchecker; a=8;		algo=rndchecker; a=8;
	zoomX=-50; zoomY=-50;		zoomX=-50; zoomY=-50;
Line 19:		Line 19:

	map Landscape {		map Landscape {
			overlay {
			mat=Earth; tex=earth;
			algo=sin;
			zoomX=60; zoomY=35;
			ox=25; oy=35;
			Template { mat=Gold; tex=gold; };
			Template { mat=Rock; tex=rock; };
			};
	};		};

Line 38:		Line 43:
	Misc:		Misc:
	* Use comments wherever you feel it is necessary to improve the understanding of your code.		* Use comments wherever you feel it is necessary to improve the understanding of your code.
	* ~~External overlays~~ should have a comment which explains what they do.		* Templates should have a comment which explains what they do.

Maikel: /* Guidelines */

2011-01-12T18:16:34Z

Guidelines

← Older revision		Revision as of 18:16, 12 January 2011
Line 37:		Line 37:

	Misc:		Misc:
	* Use comments wherever you feel it is necessary to improve the understanding of ~~others~~.		* Use comments wherever you feel it is necessary to improve the understanding of your code.
	* External overlays should have a comment which explains what ~~it does~~.		* External overlays should have a comment which explains what they do.

Maikel at 17:09, 11 December 2010

2010-12-11T17:09:20Z

← Older revision		Revision as of 17:09, 11 December 2010
Line 1:		Line 1:
	Since many developers are involved in the project, it is necessary to define some style guidelines for map generator code. Please adhere to these style guidelines if you are creating landscapes, so that other developers can read your code more easily. You will notice that clearly written code allows you to change specific things more easily and that you'll be able to learn from that code.		Since many developers are involved in the project, it is necessary to define some style guidelines for map generator code. Please adhere to these style guidelines if you are creating landscapes, so that other developers can read your code more easily. You will notice that clearly written code allows you to change specific things more easily and that you'll be able to learn from that code.

	==Example==		===Example===

			Here is a detailed example of a well styled Landscape.txt file.
			/*--
			''Scenario title''
			Author: John Doe

			''Short description of the landscape.''
			--*/

			// ''Short comment on what the overlay does.''
			overlay External {
			algo=rndchecker; a=8;
			zoomX=-50; zoomY=-50;
			turbulence=100; loosebounds=1;
			};

			map Landscape {



			};

			===Guidelines===

			Naming conventions:
			* Use <code>CamelCase</code> for names of overlays and maps.
			* Try to use meaningful and self explanatory names.

			Indents, braces and spaces:
			* Code is indented with one tab.
			* The opening brace is on the same line as the overlay or map.
			* The closing brace is on its own line on the same level as the overlay.
			* There is no whitespace around the <code>=</code> operator.

			Misc:
			* Use comments wherever you feel it is necessary to improve the understanding of others.
			* External overlays should have a comment which explains what it does.

Maikel: Created page with "Since many developers are involved in the project, it is necessary to define some style guidelines for map generator code. Please adhere to these style guidelines if you are crea…"

2010-12-11T16:23:56Z

Created page with "Since many developers are involved in the project, it is necessary to define some style guidelines for map generator code. Please adhere to these style guidelines if you are crea…"

New page

Since many developers are involved in the project, it is necessary to define some style guidelines for map generator code. Please adhere to these style guidelines if you are creating landscapes, so that other developers can read your code more easily. You will notice that clearly written code allows you to change specific things more easily and that you'll be able to learn from that code.

==Example==