User:Nightstrike - Revision history

Nightstrike: Replacing page with 'Next version coming up soon. :)'

2009-03-26T17:30:50Z

Replacing page with 'Next version coming up soon. :)'

← Older revision		Revision as of 17:30, 26 March 2009
Line 1:		Line 1:
	~~=Modularization of Game Logic and State=~~		Next version coming up soon. :)

	~~== Synopsis ==~~

	Currently, much of BZFlag's game logic is intertwined with it's graphics code and this does not allow components like bzfs or bzrobots to make use of the game logic as and when required. This has lead to a considerable amount of code being duplicated across different portions of the source tree. Furthermore, this goes against the concept of software modularization, the implications of which will lead to slower development in the future as a change in one instance of such code will have to be reflected everywhere else as well.

	This project aims to solve the above issue by the modularization of shared game logic into libGameLogic and game state into libGameState. This code can then be accessed with subtle ease by the client and server applications.


	~~== Why? ==~~

	A quick glance of the source itself will reveal quite a lot of redundancy. For instance, [1] and [2] have a lot of code which is exactly similiar, like the updateNumPlayers() function definition, which is same all the way down to the last character. Duplication of such an order is only a hindrance to ongoing development. Furthermore, the current implementation of libGame is far from complete and mostly consists of files which were formerly in [3] along with minor changes.

	~~Hence, the need of the hour is to refactor existing client code and modularize both the game logic and game state into libGameLogic and libGameState respectively. This will help:~~

	~~1.strengthen the game server and keep it more authoritative,~~
	~~2. provide a base for development revolving around cheat prevention and the network testing framework, and~~
	~~3. make the modularization of OpenGL code a trivial issue. :)~~


	~~== How? ==~~

	The gist of the work would be to strip down client side code to an extent that we get to abstract the logic from the communications, graphics and initialization components of the code. This would take us one step closer to making the client more and more stupid, so that much of the game is controlled by the server itself, especially information regarding the game state. Hence, this project consists primarily of four steps:

	~~===Phase I===~~
	1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx, CollisionManager.cxx, Frustum.cxx, Intersect.cxx, LinkManager.cxx, MotionUtils.cxx, PhysicsDriver.cxx, Ray.cxx, ShotManager.cxx and ShotUpdate.cxx. Everything else will be moved to libGameState.
	~~1.2 Phase I refactoring: Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.~~

	~~===Phase II===~~
	2.1 Add code from the bzflag client to libGameState and libGameLogic: Code shall be identified from the bzflag client code (src/bzflag) that can be moved to either libGameLogic (for instance, all the files related to Shots) or libGameState (for instance, files relating to player avatars). As per the logic being migrated, new files will be created in libGameState or libGameLogic and the current ones will be edited if necessary.
	2.2 Phase II refactoring: Once all the game state and logic related code have been migrated to libGameState and libGameLogic, a complete refactoring of the client code will be done so as to ensure that all the files have been hooked properly to the corresponding library/libraries without any change in functionality.

	~~===Phase III===~~
	3.1 Testing: Rigorous testing of the client will be done so as to ensure that the newly made libraries are being effectively used and will also involve squishing any bugs that might have strayed in during the refactoring process.
	~~3.2 Code clean up: This would be the final stage of the project where the entire code will be scrutinised and cleaned up so as to ensure a polished, finished product. :)~~

	~~== Deliverables ==~~

	Upon successful completion of the project, the game state and logic can be distinctly accessed by the client and server applications by making calls to libGameState and libGameLogic respectively. This would in turn allow developers to make further ground on keeping the server authoritative, so that it has more control over the game and will ease the burden of cheat prevention. Hence the objectives for this project would be to:
	~~1. Branch libGame into libGameLogic and libGameState.~~
	~~2. Refactor bzflag, strip it down and migrate the relevant code to libGameState and libGameLogic~~
	~~3. Hook up bzflag to the new libraries.~~

	Furthermore, if time permits, I'll personally see to it that I hook up bzrobots and bzadmin to the new libraries as well and this is a commitment I'll be pledging to even beyond the Google Summer of Code period.


	~~== When? ==~~

	~~Time for the project will be allocated roughly as follows:~~

	~~April 20 – May 01 : Get friendly with the mentors and the BZFlag community.~~

	~~May 02 – May 23 : Understand the code and identify components to refactor.~~

	~~May 24 – May 28 : Phase I; 1.1~~

	~~May 28 - June 7 : Phase I; 1.2~~

	~~June 08 – June 30 : Phase II; 2.1~~

	~~July 01 – July 20 : Phase II; 2.2~~

	~~July 20 – Aug 05 : Phase III; 3.1~~

	~~Aug 06 - Aug 10 : Phase III, 3.2~~

	~~Aug 11 – Aug 20 : Grace time to possibly hook~~ up ~~one more client to libGameState and libGameLogic.~~

	~~== Who? ==~~

	~~I am a third year undergraduate student in Malaviya National Institute of Technology, Jaipur, pursuing a Bachelor's degree in Computer Engineering~~. ~~I have been a hardcore gamer since the age of four, and I have made my mark in popular multiplayer games like Starsiege, Age of Empires, Warcraft III (DotA to be more specific) and Need For Speed~~: ~~Most Wanted. Throughout my journey through the world of games, I have always been attracted to the thought of being a game developer myself.~~

	I have been actively involved with FOSS for close to two years now. I'm the key system administrator of my institute and I've also helped organisations in the city I study in with their server maintenance. Furthermore, I am actively involved in the Open HA Cluster project [4]; I have made code contributions in the form of bug fixes [5] [6] and I am also the lead developer for the HA-Cron project [7] which is a high availability agent for Cron on the Open HA Cluster platform. I have also delivered a talk during Sun Tech Days 2009 [8] on HA-Cron on February 19th as part of the lightning talks in the OpenSolaris track.

	I am well versed with the tools and techniques needed to work on FOSS projects like version control systems (especially Subversion, which BZFlag uses), AutoConf, AutoMake etc. Hence, I can seamlessly adapt to this project and can get started almost immediately. My relevant programming skills as far as this project is concerned are C++ and OpenGL (I am currently going through a full course on Computer Graphics using OpenGL as part of my sixth semester studies and I'm also strong with the mathematics behind graphics programming). Putting together my skill set, my experience with FOSS and my passion for games, you will see that I am an excellent candidate for this project. With my knowledge of C++ and OpenGL, I can be an asset to BZFlag, as I intend to contribute to it over a long term, even after the Google Summer of Code period is over. I sincerely hope that my work during this summer will give me the foundation I need to become the game developer I have always dreamt of being!

	Feel free to browse through my blog [9] where I put up details of my life and my work. You might also want to view my resume [10]. Please do not hesitate to get back to me if you feel there's any clarification to be made regarding this proposal. Thanks for taking your time to consider the same.


	~~== References ==~~

	~~[1] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzflag/playing.cxx~~
	~~[2] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzrobots/botplaying.cxx~~
	~~[3] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/common/~~
	~~[4] http://opensolaris.org/os/community/ha-clusters/ohac/~~
	~~[5] http://opensolaris.org/os/community/ha-clusters/ohac/contribute/CRs-with-Contributor/~~
	~~[6] http://bugs.opensolaris.org/view_bug.do?bug_id=4616225~~
	~~[7] https://hacron.dev.java.net/~~
	~~[8] http://www.sercononline.com/suntechdays09/index.htm~~
	~~[9] http://lalithsuresh.wordpress.com~~
	~~[10] http://lalithsuresh.files.wordpress.com/2008/07/resume.pdf~~

Nightstrike at 17:59, 24 March 2009

2009-03-24T17:59:02Z

← Older revision		Revision as of 17:59, 24 March 2009
Line 1:		Line 1:
	=Modularization of Game Logic and State ~~into libGameState and libGameLogic~~=		=Modularization of Game Logic and State=

	== Synopsis ==		== Synopsis ==

Nightstrike at 17:58, 24 March 2009

2009-03-24T17:58:26Z

← Older revision		Revision as of 17:58, 24 March 2009
Line 1:		Line 1:
	=Modularization of Game Logic and State into LibGame*=		=Modularization of Game Logic and State into libGameState and libGameLogic=

	== Synopsis ==		== Synopsis ==
Line 12:		Line 12:
	A quick glance of the source itself will reveal quite a lot of redundancy. For instance, [1] and [2] have a lot of code which is exactly similiar, like the updateNumPlayers() function definition, which is same all the way down to the last character. Duplication of such an order is only a hindrance to ongoing development. Furthermore, the current implementation of libGame is far from complete and mostly consists of files which were formerly in [3] along with minor changes.		A quick glance of the source itself will reveal quite a lot of redundancy. For instance, [1] and [2] have a lot of code which is exactly similiar, like the updateNumPlayers() function definition, which is same all the way down to the last character. Duplication of such an order is only a hindrance to ongoing development. Furthermore, the current implementation of libGame is far from complete and mostly consists of files which were formerly in [3] along with minor changes.

	Hence, the need of the hour is to refactor existing client code and modularize both the game logic and game state into libGameLogic and libGameState respectively, which I will be collectively referring to as libGame*. This will help:		Hence, the need of the hour is to refactor existing client code and modularize both the game logic and game state into libGameLogic and libGameState respectively. This will help:
	strengthen the game server and keep it more authoritative,
	provide a base for development revolving around cheat prevention and the network testing framework, and		1.strengthen the game server and keep it more authoritative,
	make the modularization of OpenGL code a trivial issue. :)		2. provide a base for development revolving around cheat prevention and the network testing framework, and
			3. make the modularization of OpenGL code a trivial issue. :)


Line 24:		Line 25:
	===Phase I===		===Phase I===
	1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx, CollisionManager.cxx, Frustum.cxx, Intersect.cxx, LinkManager.cxx, MotionUtils.cxx, PhysicsDriver.cxx, Ray.cxx, ShotManager.cxx and ShotUpdate.cxx. Everything else will be moved to libGameState.		1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx, CollisionManager.cxx, Frustum.cxx, Intersect.cxx, LinkManager.cxx, MotionUtils.cxx, PhysicsDriver.cxx, Ray.cxx, ShotManager.cxx and ShotUpdate.cxx. Everything else will be moved to libGameState.
	1.2 Phase I refactoring: ~~libGame will be entirely replaced by libGame*.~~ Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.		1.2 Phase I refactoring: Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.

	===Phase II===		===Phase II===
	2.1 Add code from the bzflag client to libGame: Code shall be identified from the bzflag client code (src/bzflag) that can be moved to either libGameLogic (for instance, all the files related to Shots) or libGameState (for instance, files relating to player avatars). As per the logic being migrated, new files will be created in libGame and the current ones will be edited if necessary.		2.1 Add code from the bzflag client to libGameState and libGameLogic: Code shall be identified from the bzflag client code (src/bzflag) that can be moved to either libGameLogic (for instance, all the files related to Shots) or libGameState (for instance, files relating to player avatars). As per the logic being migrated, new files will be created in libGameState or libGameLogic and the current ones will be edited if necessary.
	2.2 Phase II refactoring: Once all the game state and logic related code have been migrated to libGame*, a complete refactoring of the client code will be done so as to ensure that all the files have been hooked properly to the corresponding library/libraries without any change in functionality.		2.2 Phase II refactoring: Once all the game state and logic related code have been migrated to libGameState and libGameLogic, a complete refactoring of the client code will be done so as to ensure that all the files have been hooked properly to the corresponding library/libraries without any change in functionality.

	===Phase III===		===Phase III===
Line 36:		Line 37:
	== Deliverables ==		== Deliverables ==

	Upon successful completion of the project, the game state and logic can be distinctly accessed by the client and server applications by making calls to libGame*. This would in turn allow developers to make further ground on keeping the server authoritative, so that it has more control over the game and will ease the burden of cheat prevention. Hence the objectives for this project would be to:		Upon successful completion of the project, the game state and logic can be distinctly accessed by the client and server applications by making calls to libGameState and libGameLogic respectively. This would in turn allow developers to make further ground on keeping the server authoritative, so that it has more control over the game and will ease the burden of cheat prevention. Hence the objectives for this project would be to:
	1. Branch libGame into libGameLogic and libGameState.		1. Branch libGame into libGameLogic and libGameState.
	2. Refactor bzflag, strip it down and migrate the relevant code to libGame*		2. Refactor bzflag, strip it down and migrate the relevant code to libGameState and libGameLogic
	3. Hook up bzflag to libGame*.		3. Hook up bzflag to the new libraries.

	Furthermore, if time permits, I'll personally see to it that I hook up bzrobots and bzadmin to libGame* as well and this is a commitment I'll be pledging to even beyond the Google Summer of Code period.		Furthermore, if time permits, I'll personally see to it that I hook up bzrobots and bzadmin to the new libraries as well and this is a commitment I'll be pledging to even beyond the Google Summer of Code period.


Line 64:		Line 65:
	Aug 06 - Aug 10 : Phase III, 3.2		Aug 06 - Aug 10 : Phase III, 3.2

	Aug 11 – Aug 20 : Grace time to possibly hook up one more client to libGame*.		Aug 11 – Aug 20 : Grace time to possibly hook up one more client to libGameState and libGameLogic.

	== Who? ==		== Who? ==

JeffM2501: wiki want double spaces

2009-03-24T17:53:17Z

wiki want double spaces

← Older revision		Revision as of 17:53, 24 March 2009
Line 47:		Line 47:

	Time for the project will be allocated roughly as follows:		Time for the project will be allocated roughly as follows:

	April 20 – May 01 : Get friendly with the mentors and the BZFlag community.		April 20 – May 01 : Get friendly with the mentors and the BZFlag community.

	May 02 – May 23 : Understand the code and identify components to refactor.		May 02 – May 23 : Understand the code and identify components to refactor.

	May 24 – May 28 : Phase I; 1.1		May 24 – May 28 : Phase I; 1.1

	May 28 - June 7 : Phase I; 1.2		May 28 - June 7 : Phase I; 1.2

	June 08 – June 30 : Phase II; 2.1		June 08 – June 30 : Phase II; 2.1

	July 01 – July 20 : Phase II; 2.2		July 01 – July 20 : Phase II; 2.2

	July 20 – Aug 05 : Phase III; 3.1		July 20 – Aug 05 : Phase III; 3.1

	Aug 06 - Aug 10 : Phase III, 3.2		Aug 06 - Aug 10 : Phase III, 3.2

	Aug 11 – Aug 20 : Grace time to possibly hook up one more client to libGame*.		Aug 11 – Aug 20 : Grace time to possibly hook up one more client to libGame*.


	== Who? ==		== Who? ==

Nightstrike at 17:53, 24 March 2009

2009-03-24T17:53:03Z

← Older revision		Revision as of 17:53, 24 March 2009
Line 1:		Line 1:
	=~~LibGameState~~=		=Modularization of Game Logic and State into LibGame*=

	== Synopsis ==		== Synopsis ==

JeffM2501: nesting is good

2009-03-24T17:52:22Z

nesting is good

← Older revision		Revision as of 17:52, 24 March 2009
Line 21:		Line 21:
	The gist of the work would be to strip down client side code to an extent that we get to abstract the logic from the communications, graphics and initialization components of the code. This would take us one step closer to making the client more and more stupid, so that much of the game is controlled by the server itself, especially information regarding the game state. Hence, this project consists primarily of four steps:		The gist of the work would be to strip down client side code to an extent that we get to abstract the logic from the communications, graphics and initialization components of the code. This would take us one step closer to making the client more and more stupid, so that much of the game is controlled by the server itself, especially information regarding the game state. Hence, this project consists primarily of four steps:

	1 Phase I		===Phase I===
	1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx, CollisionManager.cxx, Frustum.cxx, Intersect.cxx, LinkManager.cxx, MotionUtils.cxx, PhysicsDriver.cxx, Ray.cxx, ShotManager.cxx and ShotUpdate.cxx. Everything else will be moved to libGameState.		1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx, CollisionManager.cxx, Frustum.cxx, Intersect.cxx, LinkManager.cxx, MotionUtils.cxx, PhysicsDriver.cxx, Ray.cxx, ShotManager.cxx and ShotUpdate.cxx. Everything else will be moved to libGameState.
	1.2 Phase I refactoring: libGame will be entirely replaced by libGame*. Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.		1.2 Phase I refactoring: libGame will be entirely replaced by libGame*. Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.

	2 Phase II		===Phase II===
	2.1 Add code from the bzflag client to libGame: Code shall be identified from the bzflag client code (src/bzflag) that can be moved to either libGameLogic (for instance, all the files related to Shots) or libGameState (for instance, files relating to player avatars). As per the logic being migrated, new files will be created in libGame and the current ones will be edited if necessary.		2.1 Add code from the bzflag client to libGame: Code shall be identified from the bzflag client code (src/bzflag) that can be moved to either libGameLogic (for instance, all the files related to Shots) or libGameState (for instance, files relating to player avatars). As per the logic being migrated, new files will be created in libGame and the current ones will be edited if necessary.
	2.2 Phase II refactoring: Once all the game state and logic related code have been migrated to libGame*, a complete refactoring of the client code will be done so as to ensure that all the files have been hooked properly to the corresponding library/libraries without any change in functionality.		2.2 Phase II refactoring: Once all the game state and logic related code have been migrated to libGame*, a complete refactoring of the client code will be done so as to ensure that all the files have been hooked properly to the corresponding library/libraries without any change in functionality.

	3 Phase III		===Phase III===
	3.1 Testing: Rigorous testing of the client will be done so as to ensure that the newly made libraries are being effectively used and will also involve squishing any bugs that might have strayed in during the refactoring process.		3.1 Testing: Rigorous testing of the client will be done so as to ensure that the newly made libraries are being effectively used and will also involve squishing any bugs that might have strayed in during the refactoring process.
	3.2 Code clean up: This would be the final stage of the project where the entire code will be scrutinised and cleaned up so as to ensure a polished, finished product. :)		3.2 Code clean up: This would be the final stage of the project where the entire code will be scrutinised and cleaned up so as to ensure a polished, finished product. :)

JeffM2501: put the project in there, so we know what one is being talked about ;)

2009-03-24T17:50:47Z

put the project in there, so we know what one is being talked about ;)

← Older revision		Revision as of 17:50, 24 March 2009
Line 1:		Line 1:
			=LibGameState=
	== Synopsis ==		== Synopsis ==

Nightstrike: /* How? */

2009-03-24T17:49:31Z

How?

← Older revision		Revision as of 17:49, 24 March 2009
Line 1:		Line 1:

	== Synopsis ==		== Synopsis ==

Line 21:		Line 20:
	The gist of the work would be to strip down client side code to an extent that we get to abstract the logic from the communications, graphics and initialization components of the code. This would take us one step closer to making the client more and more stupid, so that much of the game is controlled by the server itself, especially information regarding the game state. Hence, this project consists primarily of four steps:		The gist of the work would be to strip down client side code to an extent that we get to abstract the logic from the communications, graphics and initialization components of the code. This would take us one step closer to making the client more and more stupid, so that much of the game is controlled by the server itself, especially information regarding the game state. Hence, this project consists primarily of four steps:

	1 Phase I		1 Phase I
	1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx, CollisionManager.cxx, Frustum.cxx, Intersect.cxx, LinkManager.cxx, MotionUtils.cxx, PhysicsDriver.cxx, Ray.cxx, ShotManager.cxx and ShotUpdate.cxx. Everything else will be moved to libGameState.		1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx, CollisionManager.cxx, Frustum.cxx, Intersect.cxx, LinkManager.cxx, MotionUtils.cxx, PhysicsDriver.cxx, Ray.cxx, ShotManager.cxx and ShotUpdate.cxx. Everything else will be moved to libGameState.
	1.2 Phase I refactoring: libGame will be entirely replaced by libGame*. Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.		1.2 Phase I refactoring: libGame will be entirely replaced by libGame*. Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.

	~~2 Phase II~~
	2.1 Add code from the bzflag client to libGame: Code shall be identified from the bzflag client code (src/bzflag) that can be moved to either libGameLogic (for instance, all the files related to Shots) or libGameState (for instance, files relating to player avatars). As per the logic being migrated, new files will be created in libGame and the current ones will be edited if necessary.
	2.2 Phase II refactoring: Once all the game state and logic related code have been migrated to libGame*, a complete refactoring of the client code will be done so as to ensure that all the files have been hooked properly to the corresponding library/libraries without any change in functionality.

	3 Phase ~~III~~		2 Phase II
	3.1 ~~Testing~~: ~~Rigorous testing of~~ the client ~~will~~ be ~~done so as~~ to ~~ensure that~~ the ~~newly made libraries are~~ being ~~effectively used and~~ will ~~also involve squishing any bugs that might have strayed~~ in ~~during~~ the ~~refactoring process~~.		2.1 Add code from the bzflag client to libGame: Code shall be identified from the bzflag client code (src/bzflag) that can be moved to either libGameLogic (for instance, all the files related to Shots) or libGameState (for instance, files relating to player avatars). As per the logic being migrated, new files will be created in libGame and the current ones will be edited if necessary.
	3.2 ~~Code clean up~~: ~~This would be~~ the ~~final stage~~ of the ~~project where the entire~~ code will be ~~scrutinised and cleaned up~~ so as to ensure ~~a polished, finished product~~. :)		2.2 Phase II refactoring: Once all the game state and logic related code have been migrated to libGame*, a complete refactoring of the client code will be done so as to ensure that all the files have been hooked properly to the corresponding library/libraries without any change in functionality.

			3 Phase III
			3.1 Testing: Rigorous testing of the client will be done so as to ensure that the newly made libraries are being effectively used and will also involve squishing any bugs that might have strayed in during the refactoring process.
			3.2 Code clean up: This would be the final stage of the project where the entire code will be scrutinised and cleaned up so as to ensure a polished, finished product. :)

	== Deliverables ==		== Deliverables ==

Nightstrike at 17:42, 24 March 2009

2009-03-24T17:42:40Z

← Older revision		Revision as of 17:42, 24 March 2009
Line 1:		Line 1:
	Synopsis
			== Synopsis ==

	Currently, much of BZFlag's game logic is intertwined with it's graphics code and this does not allow components like bzfs or bzrobots to make use of the game logic as and when required. This has lead to a considerable amount of code being duplicated across different portions of the source tree. Furthermore, this goes against the concept of software modularization, the implications of which will lead to slower development in the future as a change in one instance of such code will have to be reflected everywhere else as well.		Currently, much of BZFlag's game logic is intertwined with it's graphics code and this does not allow components like bzfs or bzrobots to make use of the game logic as and when required. This has lead to a considerable amount of code being duplicated across different portions of the source tree. Furthermore, this goes against the concept of software modularization, the implications of which will lead to slower development in the future as a change in one instance of such code will have to be reflected everywhere else as well.

	This project aims to solve the above issue by the modularization of shared game logic into libGameLogic and game state into libGameState. This code can then be accessed with subtle ease by the client and server applications.		This project aims to solve the above issue by the modularization of shared game logic into libGameLogic and game state into libGameState. This code can then be accessed with subtle ease by the client and server applications.

	Why?
			== Why? ==

	A quick glance of the source itself will reveal quite a lot of redundancy. For instance, [1] and [2] have a lot of code which is exactly similiar, like the updateNumPlayers() function definition, which is same all the way down to the last character. Duplication of such an order is only a hindrance to ongoing development. Furthermore, the current implementation of libGame is far from complete and mostly consists of files which were formerly in [3] along with minor changes.		A quick glance of the source itself will reveal quite a lot of redundancy. For instance, [1] and [2] have a lot of code which is exactly similiar, like the updateNumPlayers() function definition, which is same all the way down to the last character. Duplication of such an order is only a hindrance to ongoing development. Furthermore, the current implementation of libGame is far from complete and mostly consists of files which were formerly in [3] along with minor changes.

Line 12:		Line 16:
	make the modularization of OpenGL code a trivial issue. :)		make the modularization of OpenGL code a trivial issue. :)

	How?
			== How? ==

	The gist of the work would be to strip down client side code to an extent that we get to abstract the logic from the communications, graphics and initialization components of the code. This would take us one step closer to making the client more and more stupid, so that much of the game is controlled by the server itself, especially information regarding the game state. Hence, this project consists primarily of four steps:		The gist of the work would be to strip down client side code to an extent that we get to abstract the logic from the communications, graphics and initialization components of the code. This would take us one step closer to making the client more and more stupid, so that much of the game is controlled by the server itself, especially information regarding the game state. Hence, this project consists primarily of four steps:

	1 Phase I		1 Phase I
	1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx		1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx, CollisionManager.cxx, Frustum.cxx, Intersect.cxx, LinkManager.cxx, MotionUtils.cxx, PhysicsDriver.cxx, Ray.cxx, ShotManager.cxx and ShotUpdate.cxx. Everything else will be moved to libGameState.
	, CollisionManager.cxx
	, Frustum.cxx
	, Intersect.cxx
	, LinkManager.cxx
	, MotionUtils.cxx
	, PhysicsDriver.cxx
	, Ray.cxx
	, ShotManager.cxx
	and ShotUpdate.cxx. Everything else will be moved to libGameState.
	1.2 Phase I refactoring: libGame will be entirely replaced by libGame*. Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.		1.2 Phase I refactoring: libGame will be entirely replaced by libGame*. Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.

Line 36:		Line 33:
	3.2 Code clean up: This would be the final stage of the project where the entire code will be scrutinised and cleaned up so as to ensure a polished, finished product. :)		3.2 Code clean up: This would be the final stage of the project where the entire code will be scrutinised and cleaned up so as to ensure a polished, finished product. :)

	Deliverables
			== Deliverables ==

	Upon successful completion of the project, the game state and logic can be distinctly accessed by the client and server applications by making calls to libGame*. This would in turn allow developers to make further ground on keeping the server authoritative, so that it has more control over the game and will ease the burden of cheat prevention. Hence the objectives for this project would be to:		Upon successful completion of the project, the game state and logic can be distinctly accessed by the client and server applications by making calls to libGame*. This would in turn allow developers to make further ground on keeping the server authoritative, so that it has more control over the game and will ease the burden of cheat prevention. Hence the objectives for this project would be to:
	1. Branch libGame into libGameLogic and libGameState.		1. Branch libGame into libGameLogic and libGameState.
Line 44:		Line 43:
	Furthermore, if time permits, I'll personally see to it that I hook up bzrobots and bzadmin to libGame* as well and this is a commitment I'll be pledging to even beyond the Google Summer of Code period.		Furthermore, if time permits, I'll personally see to it that I hook up bzrobots and bzadmin to libGame* as well and this is a commitment I'll be pledging to even beyond the Google Summer of Code period.

	When?
			== When? ==

	Time for the project will be allocated roughly as follows:		Time for the project will be allocated roughly as follows:
	April 20 – May 01 : Get friendly with the mentors and the BZFlag community.		April 20 – May 01 : Get friendly with the mentors and the BZFlag community.
Line 56:		Line 57:
	Aug 11 – Aug 20 : Grace time to possibly hook up one more client to libGame*.		Aug 11 – Aug 20 : Grace time to possibly hook up one more client to libGame*.

	Who?
			== Who? ==

	I am a third year undergraduate student in Malaviya National Institute of Technology, Jaipur, pursuing a Bachelor's degree in Computer Engineering. I have been a hardcore gamer since the age of four, and I have made my mark in popular multiplayer games like Starsiege, Age of Empires, Warcraft III (DotA to be more specific) and Need For Speed: Most Wanted. Throughout my journey through the world of games, I have always been attracted to the thought of being a game developer myself.		I am a third year undergraduate student in Malaviya National Institute of Technology, Jaipur, pursuing a Bachelor's degree in Computer Engineering. I have been a hardcore gamer since the age of four, and I have made my mark in popular multiplayer games like Starsiege, Age of Empires, Warcraft III (DotA to be more specific) and Need For Speed: Most Wanted. Throughout my journey through the world of games, I have always been attracted to the thought of being a game developer myself.

Line 65:		Line 68:
	Feel free to browse through my blog [9] where I put up details of my life and my work. You might also want to view my resume [10]. Please do not hesitate to get back to me if you feel there's any clarification to be made regarding this proposal. Thanks for taking your time to consider the same.		Feel free to browse through my blog [9] where I put up details of my life and my work. You might also want to view my resume [10]. Please do not hesitate to get back to me if you feel there's any clarification to be made regarding this proposal. Thanks for taking your time to consider the same.

	References
			== References ==

	[1] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzflag/playing.cxx		[1] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzflag/playing.cxx
	[2] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzrobots/botplaying.cxx		[2] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzrobots/botplaying.cxx

Nightstrike at 17:38, 24 March 2009

2009-03-24T17:38:49Z

← Older revision		Revision as of 17:38, 24 March 2009
Line 1:		Line 1:
	~~Version~~-2.~~0 coming soon~~ :)		Synopsis
			Currently, much of BZFlag's game logic is intertwined with it's graphics code and this does not allow components like bzfs or bzrobots to make use of the game logic as and when required. This has lead to a considerable amount of code being duplicated across different portions of the source tree. Furthermore, this goes against the concept of software modularization, the implications of which will lead to slower development in the future as a change in one instance of such code will have to be reflected everywhere else as well.

			This project aims to solve the above issue by the modularization of shared game logic into libGameLogic and game state into libGameState. This code can then be accessed with subtle ease by the client and server applications.

			Why?
			A quick glance of the source itself will reveal quite a lot of redundancy. For instance, [1] and [2] have a lot of code which is exactly similiar, like the updateNumPlayers() function definition, which is same all the way down to the last character. Duplication of such an order is only a hindrance to ongoing development. Furthermore, the current implementation of libGame is far from complete and mostly consists of files which were formerly in [3] along with minor changes.

			Hence, the need of the hour is to refactor existing client code and modularize both the game logic and game state into libGameLogic and libGameState respectively, which I will be collectively referring to as libGame*. This will help:
			strengthen the game server and keep it more authoritative,
			provide a base for development revolving around cheat prevention and the network testing framework, and
			make the modularization of OpenGL code a trivial issue. :)

			How?
			The gist of the work would be to strip down client side code to an extent that we get to abstract the logic from the communications, graphics and initialization components of the code. This would take us one step closer to making the client more and more stupid, so that much of the game is controlled by the server itself, especially information regarding the game state. Hence, this project consists primarily of four steps:

			1 Phase I
			1.1 Split libGame into libGameLogic and libGameState: All the files related to shared game logic will go into libGameLogic. These files as per the categorisation are Flag.cxx
			, CollisionManager.cxx
			, Frustum.cxx
			, Intersect.cxx
			, LinkManager.cxx
			, MotionUtils.cxx
			, PhysicsDriver.cxx
			, Ray.cxx
			, ShotManager.cxx
			and ShotUpdate.cxx. Everything else will be moved to libGameState.
			1.2 Phase I refactoring: libGame will be entirely replaced by libGame*. Any calls by the clients to libGame will be replaced by calls to libGameLogic or libGameState respectively. All the necessary makefiles will also be changed accordingly.

			2 Phase II
			2.1 Add code from the bzflag client to libGame: Code shall be identified from the bzflag client code (src/bzflag) that can be moved to either libGameLogic (for instance, all the files related to Shots) or libGameState (for instance, files relating to player avatars). As per the logic being migrated, new files will be created in libGame and the current ones will be edited if necessary.
			2.2 Phase II refactoring: Once all the game state and logic related code have been migrated to libGame*, a complete refactoring of the client code will be done so as to ensure that all the files have been hooked properly to the corresponding library/libraries without any change in functionality.

			3 Phase III
			3.1 Testing: Rigorous testing of the client will be done so as to ensure that the newly made libraries are being effectively used and will also involve squishing any bugs that might have strayed in during the refactoring process.
			3.2 Code clean up: This would be the final stage of the project where the entire code will be scrutinised and cleaned up so as to ensure a polished, finished product. :)

			Deliverables
			Upon successful completion of the project, the game state and logic can be distinctly accessed by the client and server applications by making calls to libGame*. This would in turn allow developers to make further ground on keeping the server authoritative, so that it has more control over the game and will ease the burden of cheat prevention. Hence the objectives for this project would be to:
			1. Branch libGame into libGameLogic and libGameState.
			2. Refactor bzflag, strip it down and migrate the relevant code to libGame*
			3. Hook up bzflag to libGame*.

			Furthermore, if time permits, I'll personally see to it that I hook up bzrobots and bzadmin to libGame* as well and this is a commitment I'll be pledging to even beyond the Google Summer of Code period.

			When?
			Time for the project will be allocated roughly as follows:
			April 20 – May 01 : Get friendly with the mentors and the BZFlag community.
			May 02 – May 23 : Understand the code and identify components to refactor.
			May 24 – May 28 : Phase I; 1.1
			May 28 - June 7 : Phase I; 1.2
			June 08 – June 30 : Phase II; 2.1
			July 01 – July 20 : Phase II; 2.2
			July 20 – Aug 05 : Phase III; 3.1
			Aug 06 - Aug 10 : Phase III, 3.2
			Aug 11 – Aug 20 : Grace time to possibly hook up one more client to libGame*.

			Who?
			I am a third year undergraduate student in Malaviya National Institute of Technology, Jaipur, pursuing a Bachelor's degree in Computer Engineering. I have been a hardcore gamer since the age of four, and I have made my mark in popular multiplayer games like Starsiege, Age of Empires, Warcraft III (DotA to be more specific) and Need For Speed: Most Wanted. Throughout my journey through the world of games, I have always been attracted to the thought of being a game developer myself.

			I have been actively involved with FOSS for close to two years now. I'm the key system administrator of my institute and I've also helped organisations in the city I study in with their server maintenance. Furthermore, I am actively involved in the Open HA Cluster project [4]; I have made code contributions in the form of bug fixes [5] [6] and I am also the lead developer for the HA-Cron project [7] which is a high availability agent for Cron on the Open HA Cluster platform. I have also delivered a talk during Sun Tech Days 2009 [8] on HA-Cron on February 19th as part of the lightning talks in the OpenSolaris track.

			I am well versed with the tools and techniques needed to work on FOSS projects like version control systems (especially Subversion, which BZFlag uses), AutoConf, AutoMake etc. Hence, I can seamlessly adapt to this project and can get started almost immediately. My relevant programming skills as far as this project is concerned are C++ and OpenGL (I am currently going through a full course on Computer Graphics using OpenGL as part of my sixth semester studies and I'm also strong with the mathematics behind graphics programming). Putting together my skill set, my experience with FOSS and my passion for games, you will see that I am an excellent candidate for this project. With my knowledge of C++ and OpenGL, I can be an asset to BZFlag, as I intend to contribute to it over a long term, even after the Google Summer of Code period is over. I sincerely hope that my work during this summer will give me the foundation I need to become the game developer I have always dreamt of being!

			Feel free to browse through my blog [9] where I put up details of my life and my work. You might also want to view my resume [10]. Please do not hesitate to get back to me if you feel there's any clarification to be made regarding this proposal. Thanks for taking your time to consider the same.

			References
			[1] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzflag/playing.cxx
			[2] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzrobots/botplaying.cxx
			[3] http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/common/
			[4] http://opensolaris.org/os/community/ha-clusters/ohac/
			[5] http://opensolaris.org/os/community/ha-clusters/ohac/contribute/CRs-with-Contributor/
			[6] http://bugs.opensolaris.org/view_bug.do?bug_id=4616225
			[7] https://hacron.dev.java.net/
			[8] http://www.sercononline.com/suntechdays09/index.htm
			[9] http://lalithsuresh.wordpress.com
			[10] http://lalithsuresh.files.wordpress.com/2008/07/resume.pdf