[V or 'Tex]

You ought to redo part of the node system, because if you think about it, for a straight path you have way too many nodes.

I think that Realbot should consider two types of positions, and that nodes should be placed accordingly.


When walking in a straight line, a 'moving node' is created. As you walk further, the degree of change from the starting node decreases. Allow me to explain.

If I walk 10 feet in a straight line, and walk 3 foot left. That should cause the new node to be placed -where I started the change in direction-.

However, if I walk 10 feet and only drift by... say, a half a foot. Then I am OK and I can continue walking forward.

If I walk ~80 feet and make a tiny movement, it should automatically add a new node because of the high distance.

So, what needs to be done is that nodes can change after they are created based on movement patterns. If five nodes are created in nearly straight line, they should be replaced by two nodes with one large connection.

Next, nodes should no longer be -1 if you are not directly on, or near, a node. Connections should allow the bot to sense it is on a line between a node, or near one. So that a bot may move along that line to a node. So if a node is near a node, it may decide where to go next. But if a bot is between nodes and in a connection, then it should realize that it is going from one node to another, instead of getting stuck because it no longer detects a node nearby.

Next, nodes need to be created automatically whenever two connections cross, so that when large connections are made, they can be connected later.


So, ultimately that would reduce the number of nodes being created (many paths can be reduced to two waypoints, while Realbot prefers to create dozens or even hundreds of nodes).

Another thing that ought to be done is that you should be able to specify 'supernodes'. A supernode is an important area specified as a group of nodes. To create a supernode you would type:

realbot supernode create [name]

This would create a single node with the specification of [name]. Then, you would be able to go somewhere and specify various things. For example, you could specify aim-to nodes, attached nodes (similar nodes which should be strafed or moved back and forth between) and other things.

The variety of supernodes should be simple: bombsite, sniping, camping, spawn area.

A supernode shouldn't be a single node, but instead it should be defined as a rectangular region specified as the area between 4 (or if you take the time to code it, more) nodes.

One of the problems I have had is that bots often move about chaotically near the spawn point, resulting in over a 100 nodes in a very tight area around the spawnpoint. Obviously, the bot will think about moving to each one and it increases the latency at startup because each bot has to eventually leave the spawn. They usually do fairly quickly, but not without a bit of aimless wandering between nodes.

So specify a supernode of the category 'ctspawn' via something like this:

realbot supernode create ctspawn

Then, walk to the corners of the spawn area and specify:

realbot supernode vertexadd [type of supernode] [name of new supernode]

Use ctspawn for the type, and ct1 for name.

To simplify it even further, the vertices specified could be limited to 2, one for a max xy and one for a min xy.

Supernodes would also be extremely useful for specifying large areas where lots of nodes would otherwise be needed. Instead, the tunnel in de_dust would consist of a large supernode, such as this:

realbot supernode create hotspot [name]

The specified supernode then has three addable properties. One, you should specify camping/hiding spots, two, you should specify aiming spots, and three, where to go from the supernode.

If you put the effort into overhauling your current node system, so that it supports regions and nodes (nodes being more accurate, but usually the game will create tons of these) and supernodes being more flexible entities with more properties... A big map could use a few supernodes and replace hundreds of other nodes, while adding the flexibility that would be hard to apply with nodes.

If I'm right, the reason you haven't added aim-to and camp-at nodes is because the more bits you add to each node, the more data. If you specified that each node had two possible aim-to locations, then each node would be 24 bits bigger. With 4096 possible nodes, that sums to 96KB. A region would not only remove unnecessary nodes and reduce the number of excess connections, but allow you to specify that a group of nodes had similar properties!

I think you should take this into serious consideration.