GSoC Limited play area - Revision history

Abma at 17:55, 2 March 2012

2012-03-02T17:55:15Z

← Older revision		Revision as of 18:55, 2 March 2012
Line 20:		Line 20:
	Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).		Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

	~~== Possible Mentor(s) ==~~		[[Category:GSoC]]

	~~{{GSoC2010_bottom}}~~

Koshi: backlink and category via template

2010-03-13T17:19:05Z

backlink and category via template

← Older revision		Revision as of 18:19, 13 March 2010
Line 22:		Line 22:
	== Possible Mentor(s) ==		== Possible Mentor(s) ==

	~~[[Google_Summer_of_Code_2010]]~~		{{GSoC2010_bottom}}

Tobi: Protected "GSoC Limited play area": protecting during application period [edit=sysop:move=sysop] (expires 22:00, 10 April 2010 (UTC))

2010-03-12T16:04:00Z

Protected "GSoC Limited play area": protecting during application period [edit=sysop:move=sysop] (expires 22:00, 10 April 2010 (UTC))

← Older revision	Revision as of 17:04, 12 March 2010
(No difference)

Tobi: /* GSoC idea: Limited play area */ typos

2010-03-12T15:41:19Z

GSoC idea: Limited play area: typos

← Older revision		Revision as of 16:41, 12 March 2010
Line 2:		Line 2:

	== Why ==		== Why ==
	Current spring map formats have a ~~harcoded~~ rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.		Current spring map formats have a hardcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

	== What ==		== What ==
	The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.		The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non-rectangular shape restrictions.

	The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.		The restriction shapes should be readable and changeable mid-game through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

	== Required skills ==		== Required skills ==
	* Knowledge of C++ a		* Knowledge of C++
	* Knowledge of Lua/C API bindings		* Knowledge of Lua/C API bindings

Line 21:		Line 21:

	== Possible Mentor(s) ==		== Possible Mentor(s) ==

	~~[http://www.example.com FORUMLINK]~~

	[[Google_Summer_of_Code_2010]]		[[Google_Summer_of_Code_2010]]

Brain damage: /* Technical Details */

2010-03-12T15:12:01Z

Technical Details

← Older revision		Revision as of 16:12, 12 March 2010
Line 16:		Line 16:
	Estimated: medium		Estimated: medium

	== Technical ~~Details~~ ==		== Technical details ==

	Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).		Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

Brain damage: Background -> what, splitted difficulty from technical details

2010-03-12T15:10:58Z

Background -> what, splitted difficulty from technical details

← Older revision		Revision as of 16:10, 12 March 2010
Line 4:		Line 4:
	Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.		Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

	== ~~Background~~ ==		== What ==
	The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.		The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

Line 15:		Line 15:
	== Difficulty ==		== Difficulty ==
	Estimated: medium		Estimated: medium

			== Technical Details ==

	Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).		Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

Brain damage: standardizing requirements format

2010-03-12T15:02:20Z

standardizing requirements format

← Older revision		Revision as of 16:02, 12 March 2010
Line 10:		Line 10:

	== Required skills ==		== Required skills ==
	* C++ ~~and~~ Lua/C ~~api~~		* Knowledge of C++ a
			* Knowledge of Lua/C API bindings

	== Difficulty ==		== Difficulty ==

Brain damage: /* Why */

2010-03-12T15:01:13Z

Why

← Older revision		Revision as of 16:01, 12 March 2010
Line 2:		Line 2:

	== Why ==		== Why ==
	~~So the mappers can define which part~~ of the ~~map is designed for gameplay and which for~~ the ~~looks~~.		Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

	== Background ==		== Background ==

Brain damage: /* Background */

2010-03-12T15:01:05Z

Background

← Older revision		Revision as of 16:01, 12 March 2010
Line 5:		Line 5:

	== Background ==		== Background ==
	~~Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.~~

	The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.		The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

Brain damage: removed grep reference

2010-03-12T14:50:49Z

removed grep reference

← Older revision		Revision as of 15:50, 12 March 2010
Line 12:		Line 12:

	== Required skills ==		== Required skills ==
	* grep
	* C++ and Lua/C api		* C++ and Lua/C api