|
|
| (4 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| =LibGameState=
| | 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, 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:
| |
| | |
| ===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.
| |
| | |
| ===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.
| |
| | |
| ===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
| |
Next version coming up soon. :)