Jump to content
  • entries
    15
  • comments
    50
  • views
    25,703

Einlanders Halloween devlog


Einlander

3,456 views

 Share

Sorry this is so long and may seem like rambling. I've been working on so many things relating to Leadwerks in game and tool-wise that this doesn't even begin to cover it.

 

When I started my Halloween contest entry, I had a very simple idea: You have arrived in area/town/location x, you need to get out. As I started to fill in the blanks I realized that this project would never be done before Halloween arrived. I started using Articy:Draft in detail to bring all the overflowing ideas back to manageable levels.

 

Now what I have most of the plot fleshed out I had to start on something that few of us bother worry/care about: Standards. Most games, at least Source and Unreal, have standard practice dimensions for most things. Doors, windows, walls. floors. Before making one single asset I will need to know what should be the same everywhere and what problems I will run into.

 

What do we know about Leadwerks?

 

Leadwerks now uses a cm grid that goes by powers of 2 so you will need to stop thinking in 10's

 

*these are measure to the ALMOST literal limit. so anything larger is safe

NavMesh Generation

*NOTE* There are many edge cases/exceptions to some of these measurements

Shortest navigable covered area = 213cm

Smallest navigable squared area = 206cm^2 x,z * edge-case if the centrer of the nav area is (0,0,0) you can get it even smaller [its a bug]

highest navigable step = 50cm y * there are some edge cases

narrowest navigable corridor = 116cm

 

*the character controller is prone to even the slightest floating point error

*so some of the measurements are adjusted to fall safely short of some

FPS Limits:

Shortest navigable covered area: 184cm * no jumping room

Narrowest corridor = 76cm *lots of Jittering, if you make it 1-6cm smaller you will begin to noclip and the fps player will die

step height = 57cm

Slope = 45degrees

While Crouching toggled

shortest covered area = 120cm y

Narrowest corridor =80cm width[adjusted ]*hella floating point issues

step height = 8 cm *SERIOUSLY!?

slope angle = 45degrees *FLOATING POINT ISSUES AHOY. You will have issues the further away from origin (0,0,0) you are

*note if you start from flat ground while crouching and go up a slope while crouching , you will slide back once you stop going forward [bug]

 

Now that we have learned some things about Leadwerks what do we do with it? Interpret, Extrapolate, Interpolate , and Implement!

 

I think we have all seen the guidelines that recommend a 256x256cm wall is a perfect fit. Its completely fine if your game doesn't have any jumping in it or it is severely restricted. I know that the player will be climbing over things indoors so 256cm will simply not be enough. The solution I have come up with is 320cm tall walls, with 8cm walls and 8cm ceilings. This gives us a 384cm tall block that fits perfectly in the 128cm^3 grid spacing. Now with a wall that high you can I have set the doors to be 128cm wide and 256cm tall. Because we know the problem Leadwerks has with crouching and step heights we know we need to come up with a solution be it putting ramps (visible or not) in the door or adjust the fps controller by code to check for ledges while crouched.

 

Keeping the default fpsplayer height of 1.8meters (5foot, 9inches) I have set the counter and tables to be 80cm tall. Windows are 80cm from the floor and have a height of 176cm. The heigt allows you to easily jump out the window while crouched without encountering weird physics behaviour.

 

With these standards set I can make assets that can be swapped in and out with very little issues.

 

Nice pretty tabular format smile.png :

 

vNhtUtq.png

  • Upvote 4
 Share

6 Comments


Recommended Comments

The character controller example map demonstrates the step height and slope values, and doesn't have any issues:

http://www.leadwerks.com/werkspace/page/tutorials/_/fps-character-controller-r23

 

In both cases, a slight padding value is used to make sure the exact limit always works. If you have a map that demonstrates a problem I can definitely take a look at it.

 

Regarding navmesh dimensions, you will never get a measurement that is 100% perfect in all situations. The navmesh system works by voxelling polygonal geometry and calculating navigation data from that. There will always be some loss of precision due to the alignment of the polygon geometry when it is converted to voxels. Fortunately, you can easily visualize the navmesh in the editor, so if there is a part that needs adjusting it's easy to do so.

Link to comment

The character controller example map demonstrates the step height and slope values, and doesn't have any issues:

http://www.leadwerks.com/werkspace/page/tutorials/_/fps-character-controller-r23

 

In both cases, a slight padding value is used to make sure the exact limit always works. If you have a map that demonstrates a problem I can definitely take a look at it.

 

Regarding navmesh dimensions, you will never get a measurement that is 100% perfect in all situations. The navmesh system works by voxelling polygonal geometry and calculating navigation data from that. There will always be some loss of precision due to the alignment of the polygon geometry when it is converted to voxels. Fortunately, you can easily visualize the navmesh in the editor, so if there is a part that needs adjusting it's easy to do so.

 

The real issue is when you are crouched. Other than walking it doesn't properly work. Steps act like walls, unless you approach them from a certain angle at a certain speed and glitch on top. Slopes, if you move at all on one while crouched, you will slide down it.

Link to comment

Crouching is not presently supported. The implementation is incomplete. It was actually a mistake that the documentation includes this, because it's just written in for future compatibility. I've corrected the command page.

Link to comment

Just from the documentation, meaning "don't rely on it". The behavior is not being changed, but you may see some changes in the future. Sorry for the confusion.

 

The thing that's missing is a volume intersection test to make sure the character only stands up when nothing is blocking it from doing so. And there will be more testing before it is finalized.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...