Unvanquished - User contributions [en-gb]

Feature proposals

2012-08-13T06:48:53Z

TheCamper: wiki syntax fix

This is a page to list and elaborate on engine features to implement in the future. As with the [[Game_design_proposals|gameplay proposals]] page, it is not the place to argue or otherwise discuss the validity or merit of these ideas; just to list them and build upon their description. Do not delete any idea for any reason, spam and trolling excepted (but if an idea has been rejected, mark it as deleted and add text describing why). If you would like to discuss any proposed feature or idea, do so in the associated talk page for this page.

==Ragdoll death animations==

===Trapper===

The trapper (and likely other alien structures, in future) poses an interesting problem in that it remains attached to the ceiling when it dies, but one would expect its tail to fall down and flop about realistically. As it stands now, the death animation only looks correct when it is built on the floor. A simple Newtonian particle physics system with springs should do to procedurally calculate positions of the tail bones.

==GUI controls to adjust game balance==

A config tree could be added, where each node is one of
* Tree (has more subnodes)
* Boolean
* Integer
* Float
* String

This would allow to access and adjust every configurable number in the following way:

game.buildings.reactor.health = ...
game.classes.dretch.weight = ...
network.port = ...
client.width = ...

Everyone who has seen about:config in Firefox knows how such options can be edited.

==Random idle animations==

Play a different idle animation every so often for buildable and player models.

==Detailed build animations==

Detailed build animations ala StarCraft II would be a lovely feature.

===Human buildings===

Human buildings when building might show geometry that would not otherwise be shown. For this reason, an entirely separate model and animation with this detail may be deemed necessary (depending on how much geometry is hidden, and how many buildables can be expected to be on screen at one time).

Feature proposals

2012-08-13T06:48:13Z

TheCamper: /* GUI controls to adjust game balance */

This is a page to list and elaborate on engine features to implement in the future. As with the [[Game_design_proposals|gameplay proposals]] page, it is not the place to argue or otherwise discuss the validity or merit of these ideas; just to list them and build upon their description. Do not delete any idea for any reason, spam and trolling excepted (but if an idea has been rejected, mark it as deleted and add text describing why). If you would like to discuss any proposed feature or idea, do so in the associated talk page for this page.

==Ragdoll death animations==

===Trapper===

The trapper (and likely other alien structures, in future) poses an interesting problem in that it remains attached to the ceiling when it dies, but one would expect its tail to fall down and flop about realistically. As it stands now, the death animation only looks correct when it is built on the floor. A simple Newtonian particle physics system with springs should do to procedurally calculate positions of the tail bones.

==GUI controls to adjust game balance==

A config tree could be added, where each node is one of
* Tree (has more subnodes)
* Boolean
* Integer
* Float
* String

This would allow to access and adjust every configurable number in the following way:
game.buildings.reactor.health = ...
game.classes.dretch.weight = ...
network.port = ...
client.width = ...

Everyone who has seen about:config in Firefox knows how such options can be edited.

==Random idle animations==

Play a different idle animation every so often for buildable and player models.

==Detailed build animations==

Detailed build animations ala StarCraft II would be a lovely feature.

===Human buildings===

Human buildings when building might show geometry that would not otherwise be shown. For this reason, an entirely separate model and animation with this detail may be deemed necessary (depending on how much geometry is hidden, and how many buildables can be expected to be on screen at one time).

Feature proposals

2012-08-13T06:47:32Z

TheCamper: added config tree idea

This is a page to list and elaborate on engine features to implement in the future. As with the [[Game_design_proposals|gameplay proposals]] page, it is not the place to argue or otherwise discuss the validity or merit of these ideas; just to list them and build upon their description. Do not delete any idea for any reason, spam and trolling excepted (but if an idea has been rejected, mark it as deleted and add text describing why). If you would like to discuss any proposed feature or idea, do so in the associated talk page for this page.

==Ragdoll death animations==

===Trapper===

The trapper (and likely other alien structures, in future) poses an interesting problem in that it remains attached to the ceiling when it dies, but one would expect its tail to fall down and flop about realistically. As it stands now, the death animation only looks correct when it is built on the floor. A simple Newtonian particle physics system with springs should do to procedurally calculate positions of the tail bones.

==GUI controls to adjust game balance==

A config tree could be added, where each node is one of
- Tree (has more subnodes)
- Boolean
- Integer
- Float
- String

This would allow to access and adjust every configurable number in the following way:
game.buildings.reactor.health = ...
game.classes.dretch.weight = ...
network.port = ...
client.width = ...

Everyone who has seen about:config in Firefox knows how such options can be edited.

==Random idle animations==

Play a different idle animation every so often for buildable and player models.

==Detailed build animations==

Detailed build animations ala StarCraft II would be a lovely feature.

===Human buildings===

Human buildings when building might show geometry that would not otherwise be shown. For this reason, an entirely separate model and animation with this detail may be deemed necessary (depending on how much geometry is hidden, and how many buildables can be expected to be on screen at one time).

Formats/Navigation mesh

2012-08-12T15:35:15Z

TheCamper:

The Daemon engine supports automatic navigation mesh generation from bsp map files. This navigation mesh (or "navmesh" for short) is used by the bots to navigate throughout the world.

==Generating a Navigation Mesh==

The -nav parameter to OWMap will generate a navigation mesh from a bsp file.
Use it like so:

===Windows===

OWMap.exe -game tremulous -nav mapname.map

===Linux===

./daemonmap.x86(_64) -game tremulous -nav mapname.map

===Optional Parameters===

The navigation mesh generation process is conservative by default. This means some areas (particularly, small ledges) that should be walkable may instead create a break in the navmesh which bots interpret as "I am unable to go past there." The following optional parameters give the map maker some control over navmesh generation to help with this.

<ul>
<li><code>-cellsize</code>

''Default'': 8

This value (along with <code>cellheight</code>) determines the accuracy of navigation mesh generation. A lower value will increase mesh generation accuracy at the cost of generation time and mesh size; conversely, a higher value will decrease generation time and mesh size at the cost of accuracy.

If you see gaps in the navigation mesh on "grating" floors where the grating parts, try using a higher value.
</li>
<li><code>-cellheight</code>

A lower cellheight will increase mesh generation accuracy at the cost of generation time and mesh size.

If there are gaps in the navigation mesh even though a player can easily just walk to get through, you can decrease the value to help.
</li>
<li><code>-median</code>

Applies a median filter to the walkable areas of the mesh to help contain any "noise."

See [http://digestingduck.blogspot.com/2010/07/recast-area-types-per-triangle.html this article] for more information.
</li>
<li><code>-optimistic</code>

Attempts to compensate for cellsize inaccuracy by increasing the stepheight navigation mesh generation parameter based on the current samplesize. It is recommended to be used with a lower than default cellsize to help avoid over optimistic assumptions (i.e., saying some areas are walkable that really aren't). Useful for fixing breaks in the mesh caused by some small ledges.

This produces bad results depending on how big your <code>cellsize</code> parameter is, but generating the mesh in this way will be faster than simply decreasing the <code>cellheight</code>.
</li>
</ul>

==Using a Navigation Mesh==

Navigation mesh files go in the <code>maps/</code> directory either in the folder specified by the <code>fs_game</code> cvar, or in the maps folder inside a map's <code>.pk3</code> file.

==Testing the Mesh==

<ol>
<li>Start a local server by starting Unvanquished and typing

\devmap testmap

into the console.

You may then enable drawing the navigation mesh by setting the <code>cg_bot_nav</code> cvar to <code>1</code>.


</li>
<li>Add bots with the <code>bot</code> command and spectate the game.
</li>
</ol>

==Editing the Navigation Mesh==
Unfortunately, automatic navigation mesh generation that fully supports all of the map features and player abilities in Unvanquished is increadibly difficult.
Automatic generation will usually produce a very satisfactory base mesh, but some areas may need further tweaking

===Adding Jump Links===
===Adding Ladder Links===
===Adding Pounce Links===
===Adding Drop off Links===
===Adding Walk Links===
[[Category:Bots]]