New starting position options - Page 2

New starting position options

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: New starting position options

Post by Google_Frog »

ZK has something like this implemented in lua. It is not exactly what you want but it could be a good example of how to deal with start positions and spawning.

You can send any information from the lobby to the game via modoptions. A lobby could let users enter values for modoptions and display them differently to the list that we have at the moment. For example a lobby could let people enter some modoption parameters by drawing on the map and then display them as rectangles. It would be possible to reimplement the current startboxes in lua so we don't need to request more ways to communicate between lobby and game.
klapmongool
Posts: 843
Joined: 13 Aug 2007, 13:19

Re: New starting position options

Post by klapmongool »

Silentwings wrote:Hmm; I would rather have a good algorithm than have settings per map, an algorithm is much easier to maintain. But I agree with Pica.
Pica's method is unexplored and difficult and for what? How many FFA maps are played? How many are played 2v2v2? Much easier to take what exists (if nixa ever sees this thread :p) and add the few maps that need adding.
MajBoredom
Posts: 17
Joined: 24 Nov 2013, 09:14

Re: New starting position options

Post by MajBoredom »

A few thoughts:
PicassoCT wrote:The problem is to break it down into strategic value of a start position.

I think you need to estimate
- closeness of ressources
- space to build,
- narrow entrances to defend
- routes to allys and enemys
- and expanding options (really difficult too estimate)

You evaluate those all, weight them, and find the config that sucks the least..
Evaluating all of them is a bit too expensive: in a map with e.g. 16 start spots there 16! = ~2.09 x 10^13 permutations.
smoth wrote:Doing it in c++ is forcing it on all spring projects keep your game specific requests in Lua please!
I don't think this is cause for concern. Since it is an option like the others (random, choose position, use map settings) you can simply elect not to use it. Content authors are still free to implement their own TeamFFA algorithm at the mod or map level. I gather that there is some common desire to have Team FFA in BA, Tech A, NOTA, XTA, ZK, etc. The concept of a start position is universal throughout all the spring games. In my own opinion, the algorithm would also be tedious to write and to read/understand in Lua.
smoth wrote:Why not both?
I think that this is the best option. I can imagine some team ffa "theme" maps which deliberately put players on the same team farther apart than what a generic algorithm would choose. Also, some maps are made with the precise player configuration in mind (i.e.: 2v2v2). In these settings, either the map author would provide numbered starting positions, or the mod author may provide their own algorithm, or the players may set their own boxes. We get the best of all worlds this way.

FLOZi wrote:I would say go all game side lua but the situation is massively complicated by drawing start-boxes, so some engine/lobby support is required.

It would be nice to allow white/black listing of start position methods via engineoptions.lua or such. e.g. MCL should only ever be played with fixed / random positions, never boxes.
The idea is that the algorithm starts with randomized positions that are then "fixed up" by an optimization step to make them better. This means that there is no need for start boxes in this mode. However, the initial random step also means that two games with the same player configuration might yield different starts. There's some gray area here -- although the algorithm might start with an initial random configuration, the optimization step might always converge to the same solution for some maps. This means that on certain "free-form maps" (eg: dworld acidic) you might get fairly different and diverse starting positions each time, while on more uniform maps (eg: delta siege 8 way) the algorithm might only be satisfied with one or two configurations that always turn out to be far superior to alternatives.

I think that the final result will be satisfactory to most people who play ffa and team games regularly, but these sorts of details can be resolved by a real implementation and testing.
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: New starting position options

Post by Google_Frog »

There are two large advantages to lua here:
  • It is easier to get started in lua. This is because level of control that lua has is well matched to what you want to do.
  • The release cycle for lua is very rapid compared to the engine. It will take a lot of tweaking to get this right and you only get to test your changes on many players a few times a year.
This lua would run at the start of the game so you would barely have to worry about performance. If your code is good it will likely to incorporated into many games. These games will probably have slightly different requirements so if you use lua they will be able to tweak it to their needs. If it is a hardcoded engine feature they will be unable to use it if it behaves slightly incorrectly (this has happened to a lot of engine features).
Post Reply

Return to “Engine”