User:Nightstrike

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, make the modularization of OpenGL code a trivial issue, and make a giant stride towards releasing version 3.0 of BZFlag. :)

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: Branch the existing libGame code into libGameState and libGameLogic. Refactor existing code in the bzflag client application. Migrate code relating to game state from bzflag to libGameState. Migrate code relating to game logic from bzflag to libGameLogic.

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: branch libGame into libGameLogic and libGameState. refactor bzflag, strip it down and migrate the relevant code to libGame*. 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 – June 07 : Divide existing libGame into libGameLogic and libGameState. June 08 – June 30 : First phase of bzflag refactoring and code migration. July 01 – July 20 : Second phase of bzflag refactoring and code migration. July 20 – Aug 05 : Hook up bzflag completely to libGame*. Aug 06 - Aug 10 : Code clean up. 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've been a hard core gamer since the age of four, and I've 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've always been attracted to the thought of being a game developer myself.

I've 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'm actively involved in the Open HA Cluster project [4]; I've made code contributions in the form of bug fixes [5] [6] and I'm 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've 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'm 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'm 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'm 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've 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