User:Will07c5

BZWorkbench Enhancement (summer of code 2009 proposal)

Project Proposal

The BZWorkbench map editor is currently in an unusable stage with some backend features missing and the UI needing major improvement to be usable. The aim of this project is to bring the editor to a fully usable stage where one can make a complete map without resorting to outside tools or editing the map file by hand. This project will not include adding fancy features, such as multiple view ports, to the UI or backend. Thorough testing of the backend and UI will be done continuously throughout the process so there will be no explicit testing phase. This proposal is organized in chronological order with the tasks being ordered by dependence, meaning the later tasks may require the earlier tasks in order to be implemented and/or tested properly.

Backend

The first stage will be bringing the backend to a usable stage. This is the first priority since a usable backend is needed before the UI can be fixed and tested properly. The backend is primarily responsible for the loading and saving of map files. The backend currently has incomplete support for the object types mesh, texture matrix and dynamic color, finishing the support for these types is the first priority. The second task is to fix any bug(s) that are preventing the backend from being usable, the only one known at this time is a bug that causes the editor to fail loading obj files, giving a message about failing to load the necessary plugin. Otherwise the backend is basically complete so this stage should take the least amount of time.

User Interface

After the backend is usable the UI must then be brought to a usable state. Much of the way the interface is currently laid out will stay the same. Menu items may be moved around if it is beneficial to do so and dialogs will be added or modified to allow for accessing currently inaccessible features. The current objects palette will be expanded to include all the objects. Buttons will be added along the bottom for features that need to be quickly accessible such as changing the snap to grid size.

Implementing the missing functionality in the menus and dialogs is the first priority since that is the biggest reason why the editor is unusable. Currently the add object buttons for meshbox, meshpyr, sphere, arc, mesh, tetrahedron, torus and zone do not do anything. These will all be hooked up first since the functionality will have been implemented in the previous stage, and being able to add these objects will be useful for testing the dialogs. “Save selection” and “Paste saved selection” are also non-functional and will be removed because “Save selection” can be replicated by saving a different copy of the file with the unwanted objects removed and “Paste saved selection” can be replicated using copy and paste.

Completing the object configuration dialog will be the next task. The widgets for adding and removing transforms will be implemented. Buttons for moving the transforms up and down in the list and editing transforms will be added. A dialog for adding and editing transforms will also be added. Dialogs for options specific to certain objects will be the next step. These dialogs will be accessible by pressing a button on the main dialog. The final step pertaining to object configuration is the list of materials associated with an object must be implemented as well as the list of physics drivers.

Material and physics editors need to be added. They will be accessible through the “Scene” menu. Each will consist of a dialog with a list of all the materials/physics drivers in the map. There will also be buttons to add, remove and edit materials/physics drivers. Pushing the add or edit button will bring up a dialog with all the editable properties for the selected physics driver or material. The dynamic color editor will be placed inside the material editor, with a list of dynamic colors which can edited in the same way as the materials list. The “Define world weapon” menu item will be moved to the “Objects” menu since it will help avoid confusion. World weapon will use the same dialog as other objects except with any inapplicable properties disabled. Since world weapons lack a geometrical representation, they will be given a representation which could be as simple as the weapon effect itself if that is suitable.

The menu items, “Select All” and “Unselect All” should be implemented. Clicking on a spot in the view port where no object is located should deselect the currently selected object. Ctrl + clicking should add that object to the current selection and ctrl + clicking a second time should remove that object from the selection. The object configuration dialogs should be disabled when more than one object is selected, as the object manipulation widgets should be sufficient for now. Selected objects will be represented by a bounding box around each object that is selected, this is instead of a single large bounding box because that would make it unclear whether or not an object between two other objects was selected or not.

Widgets will be added for rotating and scaling objects within the view port. The widget will be modified so that it is placed at the mid-point between the objects when more than one is selected. When more than one object is selected, rotating and scaling will be done around each object individually since performing these manipulations around the mid-point between the objects is more complicated and unnecessary for now. Snap to grid will be implemented for moving, rotating and scaling an object. Two buttons will be added to the aforementioned location at the bottom of the view port; they will increase and decrease the grid snap size. The final tasks are populating the objects palette with every object and adding dragging and dropping objects from the objects palette to the view port as a method of adding objects.

Beyond Google Summer of Code

Although this project, if successful, will result in a fully working editor, the UI may still be weak and unintuitive in some areas. The first thing I plan to do is ask the bzflag community what they think the UI did right and what it did wrong. This is because in UI design it is the user's opinion that matters most. After this the next course of action will depend on the community response.

Timeline

• April 20th: Community Bonding Period: Spend some time making several bzw maps by hand to familiarize myself with the process. Also spend time playing the game on different modes and maps to get a feel for common design concepts and ideas. (thanks DTRemenak) Further familiarize myself with the code. Learn FLTK and Open Scene Graph by writing a few test applications. Bond with the community. :)

• May 23rd: Summer of Code Begins (Week 1): Start work on backend.

• May 30th: Week 2: Finish work on backend. Start work on menus in UI

• June 6th: Week 3: Finish work on menus. Start work on object config dialog.

• June 20th: Week 5: Finish work on object config dialog. Start work on material and physics editors.

• July 11th: Week 8: Finish work on material and physics editors. Start work on selection tools.

• July 18th: Week 9: Finish work on selection tools. Start work on widgets and snap to grid.

• August 1st: Week 11: Add all objects to the palette.

• August 10th: Suggested 'pencils down' date: All new code should be finished. Clean up anything that needs to be cleaned up, test anything that needs to be tested, etc.

• August 17th: End of GSoC: Everything should be done.

Bio

I am a 19 year old Electrical Engineering student at the University of Illinois in Urbana-Champaign and will graduate in 2012. I have a strong interest in game programming as well as programming in general. I have been programming regularly in C++ for about a year now but I have been programming in various other languages for 9 years. I have been gaming both on consoles and PCs for more than half my life. While far from a hardcore gamer, I am definitely not a casual gamer and I enjoy games from many genres including FPSs, RPGs, and music games such as DDR or Audiosurf. This has lead to a strong interest in game programming, often I find myself speculating about how part of a game could have been implemented. I am currently working on a game as part of a student organization (ACM SIGGRAPH); one of my tasks incidentally is creating the editor for this game. While I have had plenty of programming experience I am new to both bzflag and open source development in general, and see GSoC as a great opportunity to really get into an open source project. I have been interested in getting involved in open source for a long time but never had sufficient motivation to get involved. If I am selected I will consider this project my summer job and therefore will have full time availability. If I am not selected I will have to find another job and will have much less time available but I may still be interested in doing some minor work on bzflag.