Difference between revisions of "BZWGen revisited"

Latest revision as of 08:06, 10 February 2013

This page contains a design document for an possible enhancement or feature. It is a work of collaborative design and has not been accepted as a development goal at this time. The final implmented feature if any may differ from the information on this page. If you are not part of the development or design group, please post comments and suggestions on the talk page and not in the middle of the design.

This is a two part project that aims to address two main issues of BZWGen, accessibility and universality.

Accessibility has been probably the main reason that BZWGen didn't get much attention -- using the program required downloading a separate program and compiling it's sources, then running it and setting it up to work with bzfs. On the other side, getting the program to produce different results requires the knowledge of a language that however documented is not straightforward for the user.

Universality addresses the fact that BZWGen would more accurately be called now a City Generator, despite the fact that the underlying engine could do much more. Furthermore, some of the ideas I initially had for 2007 were never even touched. The second (bigger) part of this years project would be to present an accessible way for the program to generate a broad choice of outputs.

Deliverables[edit]

The aim of the project is to provide a revised version of BZWGen that will work both as a standalone app and a plugin to bzfs. As a side effect, a common protocol will be presented for handling world-generating plugins.

The generator itself will be severely enhanced to provide a much wider array of output, and to allow a first time user to do much customization without the need of reading much documentation. Additionally textures and data files for the extended generator capabilities will be provided as well.

Streamlining[edit]

To pluginize BZWGen a common interface for generators will be established, which will take care of supplying the generator with necessary data. In case of bzfs data will be read from a config file. The existing map generator will then also be pluginized, an in the future, replaced by a config file for BZWGen that ideally mimics it's behavior.

Documentation update[edit]

As the system currently is somewhat mysterious to people, I'd like to provide better documentation on the L-system generator, including an illustrated tutorial on writing your own rules.

Config file layer[edit]

L-systems are hardly transparent for someone not used to them. However I didn't intend them as the main modification tool. Above the low-level L-system layer there should be a lot more readable "template" file layer, that decides what will be generated on a given map zone. What now is treated as command line parameters for BZWG will then be placed in the template file, along with the ability to use different texture sets, and load custom L-system sets.

Generation zones[edit]

The L-system based approach that BZWG uses now is just one of the features I intended for it. To smoothly blend multiple generation tools a system of splitting the map into zones is needed. Each zone will have generation parameters supplied via config files. Zones will be not limited to rectangles as is the case now, but any arbitrary polygon.

Road placement algorithm rewrite[edit]

The current subdivision method will be left intact as an option, but thanks to the custom shaped generation zones, the original intent of the L-system based road placement generator will be implemented. Apart for generating roads it will be able to do a custom territory split of a given map.

Extensions[edit]

Some of the planned extensions to the generator itself are listed below:

• scatter algorithms -- expands on the existing bzfs map generator to allow a finer control on scattering, like the control of scattered objects, control over where objects may be scattered, and control over their size and orientation. Higher level example -- scattering of L-system generated buildings.

• template based building -- a way to control the placement of other generation algorithms -- constructs the map out of a predefined template, where the template parts will be filled with the given generation result, or a preprepared map-tile.

• block-connected building -- the map is build out of pre-prepared chunks of geometry that follow the defined rules for connection. This is the way that map generation works in contemporary 3d RPG games -- dungeons are constructed from preprepared components randomly connected. The approach is suitable for overland structures as well.

• procedural objects -- as time will allow BZWG will be equipped with procedural generators for various real-world objects, for example trees and foliage. Priority is set on items that can be used in the scatter algorithm.

Project schedule[edit]

The existing blog ( http://bzflag.chaosforge.org/ ) will be used to report progress. Posts will be made at least twice weekly during the main program timeframe. Having the experience of last year, I hope to organize my time a lot better this year, and get a lot more accomplished.

Phase 1 -- May 26 - July 1[edit]

May 26 - June 15[edit]

• bzwgen compiles and works as a plugin for bzfs
• bzwgen's existing codebase is cleaned up
• a detailed schedule and plan for the rest of GSoC is prepared and accepted
• design for the template layer and other promised features
• reevaluation of bzflags collision code
• alternative ruleset/textureset to show the current capabilities

June 16 - June 28[edit]

• implementation of double-linked graph based network for usage for both the road network algorithm and the new zoning algorithm
• implementation of an alternative ad-hoc non-orthogonal road layout generator and making it work with the existing grammar (especially rewriting zones to be non-quad)

June 30 - July 6[edit]

• scatter generator
• primitives and custom mesh consolidation
• procedural meshes (extension of grammar if needed)
• reconstructing the existing generator as a compile option

Phase 2 -- July 6 - August 11[edit]

July 6 - July 14[edit]

• setting up a test server, promotion on the forum, and outside
• refining the road layout algorithm to be less chaotic, and more realistic
• config file layer

July 14 - July 20[edit]

• extentending the config file layer with full templating capabilities
• documentation and tutorial for the existing config/template system
• sample interesting template/config files, more media

July 21 - July 27[edit]

• extension of the grammar system to allow more Mueller-quality buildings (I think I found a solution for that)

July 28 - August 3[edit]

• block-connected building system based on the mesh import feature
• sample data for both "internal" and "external" effects
• additional template files, and documentation for this and previous weeks features

July 4 - August 11[edit]

• bringing it all together, and merging with BZFlag core as much as the devs allow

Phase 3 -- August 11+[edit]

Cleanup time for the GSoC finalization. Once that is done, I hope that there will be some RFE's from the community that I will be happy to implement.