BZFlagWiki - User contributions [en]

GSoC: BZWGen revisited

2008-07-04T14:37:02Z

Epyon: /* = July 14 - July 20 */

{{DesignDocument}}

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 ==

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 ===

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 ===

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 ===

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 ===

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 ===

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 ===

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 ==

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 ===

==== May 26 - June 15 ====
* 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 ====
* 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 ====
* 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 ===

==== July 6 - July 14 ====
* 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 ====
* 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 ====
* extension of the grammar system to allow more Mueller-quality buildings (I think I found a solution for that)

==== July 28 - August 3 ====
* 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 ====
* bringing it all together, and merging with BZFlag core as much as the devs allow

=== Phase 3 -- August 11+ ===

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.

GSoC: BZWGen revisited

2008-07-04T14:33:06Z

Epyon: /* Project schedule */

{{DesignDocument}}

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 ==

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 ===

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 ===

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 ===

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 ===

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 ===

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 ===

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 ==

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 ===

==== May 26 - June 15 ====
* 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 ====
* 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 ====
* 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 ===

==== July 6 - July 14 ====
* 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 ===
* 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 ====
* extension of the grammar system to allow more Mueller-quality buildings (I think I found a solution for that)

==== July 28 - August 3 ====
* 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 ====
* bringing it all together, and merging with BZFlag core as much as the devs allow

=== Phase 3 -- August 11+ ===

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.

GSoC: BZWGen revisited

2008-06-11T00:09:03Z

Epyon: Timeline expanded with more details

{{DesignDocument}}

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 ==

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 ===

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 ===

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 ===

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 ===

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 ===

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 ===

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 ==

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 ===

==== May 26 - June 15 ====
* 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 22 ====
* 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 22 - June 29 ====
* scatter generator
* primitives and custom mesh consolidation
* procedural meshes (extension of grammar if needed)
* reconstructing the existing generator as a compile option

=== Phase 2 -- June 30 - August 11 ===

==== June 30 - July 6 ====
* 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 6 - July 14 ====
* 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 14 - July 20 ====
* extension of the grammar system to allow more Mueller-quality buildings (I think I found a solution for that)

==== July 21 - July 27 ====
* 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 28 - August 3 ====
* bringing it all together, and merging with BZFlag core as much as the devs allow

==== July 4 - August 11 ====
* buffer safety time -- cleanup, possible RFE implementations

=== Phase 3 -- August 11+ ===

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.

GSoC: BZWGen revisited

2008-05-25T15:19:08Z

Epyon: Initial creation and wikification

{{DesignDocument}}

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 ==

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 ===

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 ===

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 ===

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 ===

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 ===

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 ===

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 ==

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.

=== Pre-phase ===

All research needs to be done in this time period, including the design of the plugin interfaces. I'll also try to get some community feedback on what they'd like to see in a generator, however it may be hard without having BZWG easily accessible.

The planned documentation extension for the existing ruleset system will also be done in this timeframe, as it is not a coding related task. I'd also like to provide BZWGen with a completely new alternative rule and texture set.

After all research is done, a much more detailed timeline will be presented before May 26.

=== Phase 1 -- May 26 - July 1 ===

BZWG will be rewritten following the designed interface, and will be modified to work smoothly with and bzfs. The standard generator will be rewritten into the form of a plugin. Once that is done (probably before June 15), BZWG will be extended with the generation zones, and the new template layer.

=== Phase 2 -- July 1 - August 11 ===

BZWGen will be extended with the additional generation tools -- scatter generators, template based building, block-connected building and as time allows other less-important features. About the end of this time period I count on having a BZWGen server running, and getting some community feedback.

=== Phase 3 -- August 11+ ===

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.

World units

2007-07-07T14:48:08Z

Epyon:

A world unit is the basic unit of measure when dealing with BZFlag. World units have no real-world counterpart, as they are a purely virtual concept, they can be though of to be equivalent to about 1 meter in length if you assume a roughly real world sized [[tank]].

== Some useful measures ==
<div align="center">
{| cellpadding="0" cellspacing="0" border="1" width="60%"
|-
|width="70%"|Doable jump height
|width="10%"|17.0
|-
|Jump height limit (next to impossible)
|19.0
|-
|Tank length
|8.04
|-
|Tank width
|2.8
|-
|Tank height
|2.08
|-
|Barrel height
|1.6
|-
|}
</div>

[[Category:Map Making]]
[[Category:Concepts]]

Meshbox

2007-07-06T21:05:28Z

Epyon: /* Appearance */

The meshbox is the 2.0 update to the original [[box]] object in BZFlag 1.0. The main difference between the [[box]] and the Meshbox is that the meshbox supports new features in BZFlag 2.0, such as physics drivers and textures.

==Code==
A very basic meshbox will include:
{|
|
meshbox
position 0 0 0 # x-pos, y-pos, height
rotation 0 # rotation in degrees
size 10 10 10 # x-len, y-len, height
end
|}

As with the [[box]] object, position defines where the meshbox should be located. Rotation defines the angle it should be rotated to (about the Z-axis), and size defines how big or small the object should be. Now, if you're looking for something a little fancier, you can try code similar to this:

{|
|
meshbox
position 0 0 0
rotation 0
size 10 10 10
outside matref my_cool_wall
top matref my_cool_roof
phydrv example_physics
obstacle
end
|}

So what's the difference here? Well, this object will be treated as an obstacle. The outside walls (as opposed to inside, top, or bottom) will appear with the "my_cool_wall" [[material]], and the roof (top) will have "my_cool_roof." Of course, if you want a [[material]] on all sides of the object, you can simply omit the "top" specification at the start of the line, and simply have: "matref my_cool_material." Also, you can specify a [[Physics | physics driver]] to the object, to influence tank behavior a bit.

==Appearance==
By default, a meshbox will have red brick walls, and a grey stone roof. However, if a [[material]] is specified by the map creator, the appearance depends on the designer's choosing. Contrary to a [[Box]], a height 0 meshbox at ground level ''is not'' visible.

==History==
The meshbox was added in [[BZFlag 2.0.0]].

==Editor Support==
The meshbox IS supported by [[iBZEdit]], [[pyBZEdit]], [[Blender]] with the [[BZWTools]] plugin, and the [[BZW Exporter for Wings3D]]. The meshbox is NOT supported by [[BZEdit]] or [[BZFed]].

[[Category:Map Making]]
[[Category:Map_Objects]]

Box

2007-07-06T21:03:56Z

Epyon: /* Appearance */

A Box is a [[BZW]] map structure that defines a rectilinear parellepiped in the world.

==Code==
[[Image:BoxeAppearance.png|frame|right|Default boxes]]
The code for a box object is as follows
{|
|
box
position 10 20 30
rotation 45
size 1 2 3
end
|}
Valid parameters for a box are
<properties>
position=defines the center of the box in X and Y and the bottom of the box in Z.
rotation=defines a rotation around the Z axis for the box, in degrees.
size=defines the distance from the center to the side of the box in X and Y, and the total height of the box in Z.
</properties>

Boxes do not support [[Material]], [[Texture Matrix]], or [[Physics Drivers]]. The [[Meshbox]] object replaces the box object and supports these features.

==Appearance==
Box objects by default have a red brick texture on the vertical sides, and a white plaster texture on the top and bottom. A box of height 0 on ground level ''is'' visible.

==History==
The box is one of the original objects supported by BZFlag and has been a mainstay of maps since the very beginning. Boxes are heavily used by the software when generating random maps. In [[BZFlag 2.0.0|v2.0.0]] the box was replaced with the [[meshbox]] object to support [[Material|Materials]] and [[Physics Drivers]]. The original box definition was left unchanged, in order to maintain functional compatibility for older maps.

==Editor Support==
The box object is supported by all known editors.

[[Category:Map Making]]
[[Category:Map Objects]]