User talk:IneQuation.pl

Couple things, 1) tone down the ego. it's good to be proud of yourself and your accomplishments, but it comes of as being a bit too "much" if you understand the meaning.

2) The proposal seems to include 2 projects in one, and is a significant departure from the existing codebase. I have doubts that this level of change could be done in the timefreame, cleanly. I would recommend focusing on a single aspect, ether game logic or graphics systems, not both, even tho they are indeed related in may way. I would recommend that you submit 2 proposals one for each. This way we have the option of choosing 2 students to work on the aspects of the project for more manpower on what is to no doubt be a complex task.

3)I do not agree with how you would split up the game logic into a single dll. I understand that your experience in modding ID based games sends you in that direction, but I do not feel that the monotilthic "game dll" is the right way. Personally I'd like to see bzflag's game system broken into 2 separate sections, a "State" library, and a Game logic class.

The state library would be a set of classes that had the ability to simulate the entire game world with all tanks and shots. This lib would be able to do all collision detection and object movement, but would not contain any drawing code, or any "game" related logic such as "Score" or what flag a player has. This state library would have an API for updating the state, and providing input to the various entities ( players turning, moving, etc..). It should also provide a set of callbacks that can be called when various events happen (tank hits wall, shot hits tank, etc..)

The game logic class would contain the rules for the actual game of bzflag, ie. scores, flag effects, shot paths, etc... This class would have event logic for anything that could happen in the game, and be used to set values in the state. This library should be implemented as a class that could be overridden so that we can have multiple game logic classes that simply deal with how the game is played, and do not need to worry about the tiresome job of maintaining the players states, etc..

An eventual graphics engine could then simply read the 3d view from the current state and not really worry about the game logic (hud and user UI would of course have to have some knowledge of the game logic).

This split makes it very easy to use these components in a mix/match type situation, where the server can use the state and logic libs to keep the same state as the clients, but simply not have a graphcis system. BZAdmin can have a Logic lib to track scores, but does not need a state lib since it does not deal with tanks or shots. BZRobots could also use the state and logic systems for robot input. The main client would use all the libs and additional hooks into the event system for things such as sounds and other effects.

To me this is a cleaner breakout of the code that allows for more flexibility. It leaves the client and server applications only simple thin shells that contain platform specific code to handle input and networking and provides a powerful set of tools for project to use. --JeffM2501 12:42, 23 March 2009 (EDT)

Thanks!

Well, I wasn't really able to get an answer on how far I could go in the IRC channel, so I figured I'll post what was on my mind and ask for commentary, so thanks a lot for it. :) I'm sorry if I made it sound overconfident, I didn't mean to. If it's the "the man" section that made such an impression on you, that's possibly because I didn't want to go into detail, but perhaps I'll find a way to keep it short and make it sound more modest.

Thanks for the commentary again! --IneQuation.pl 17:06, 23 March 2009 (EDT)