![]() Creating a nice looking and fun-to-play map by hand, however, is a non-trivial task too. The reason is simple - the primitive scattering algorithm implemented in BZF's random map generation is, well, simple and limited. Random Procedural World Generator Kornel Kisielewicz (Epyon) Īlthough BZFlag implements a poor man's random map generator as default, most players prefer to play on user made maps. Additionally, to encompass a larger user base, it will be developed using cross-platform toolkits, allowing it to be easily ported between operating systems and ideally support the same target operating systems as BZFlag itself. To support this need, the proposed work aims to implement such an editor that should allow users to quickly create worlds in a visual manner, provide a GUI to easily manipulate all features of BZW, provide intuitive and interactive visualizations of all map data, and allow for easy extendibility to ensure future BZW compatibility. This is problematic to the BZFlag community in that it hinders less technically-inclined users from developing worlds. While some existing editors come very close, it is usually the case that they do not fully support advanced map features, require the users to have a programmer's understanding of the file format, are not well documented, are very platform-specific, or are outright obsolete. That is to say that while there have been many over the years, they all fall into obsolescence or are less than ideal due to other constraints upon their use). Graphical BZFlag Map Editor Jude Nelson (jude-) īZFlag does not yet have a sufficient graphical world map editor. The projects that were accepted are as follows: Students were expected to interact on the #bzflag IRC channel on the Freenode network, abide by the DEVINFO rules, agree to the development requirements, and focus on providing a clean maintainable implementation. While there's never any guarantee that work on any code will be integrated, this is very much the desire and intention of our participation in the Summer of Code. Particular notice was made of students that were responsive to questions and readily interactive in the IRC channel. In the end, submissions were selected according to the overall long-term impact that accepting the proposal could make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, and overall interest in having such modifications made to BZFlag. We thank everyone that submitted a proposal and hope to still see some of you become involved in our software development. Every application was read multiple times and reviewed in detail. It was really hard to narrow down the submissions but in the end we did have only so many slots to work with and the line eventually had to be drawn. There were about 20 really good proposals overall, making the selection process very competitive and difficult. Of those applications, only four could be selected to work on BZFlag. We received a total of 45 proposals for the 2007 program that were then reviewed, evaluated, and critiqued. Their ability to perform the task is outright presumed, so they are supposed to propose a task that they are comfortable and knowledgeable with performing. ![]() Students were asked to propose what they actually want to work on, how they intend to work on it, what they intend to DO, what they know about that task, some details about themselves, etc. Submitting closer to the deadline wasn't a negative consideration as all submissions were be predominantly judged on their merit, but submitting and discussing early was an advantage for submissions that were similar to other submissions. ![]() If you talked with us on IRC about your SoC proposal, you were supposed to include your IRC nickname somewhere in your proposal.Įarly proposal submission was encouraged as it gave us more time to review your proposal in detail, comment on them, and potentially ask for additional input. Students that just submitted the summaries contained below did not do very well. C/C++ proposals were preferred though others were considered. They were supposed to state specifically what they intend to deliver and any implementation details they felt relevant such as what language they intend to use. There was no specific format to applications, but they were told that they should be detailed in their approach and background information about themselves. 3.12 Cross server communications system *.3.11 Network Testing and Simulation Environment.3.8 Enhanced cross-platform multiple display support.3.6 World file layout and editing application *.3.3 Headless Artificial Intelligence Agent *.3.1 Dead Reckoning and other Networking Enhancements.2.4 Programmable Computer Player Client. ![]()
0 Comments
Leave a Reply. |