monster creation

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Post Reply
Message
Author
User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

monster creation

#1 Post by Cjkjvfnby »

Note: patch not compatible with my prev patches.

I simplify monster generator code. It should work in same way as previos.

In python instances of class inherited form object can be keys in dictionary.
I call .spawn_limit() once for each, and then decrease value untill it zero.
Remove cycle, just make some filter on possible plans.

Question:
Why we choose random plan based on number of plans?
for example: we have two plans:
plan1 (spawnrate = 0.3), plan2 (spawn rate = 0.7)
Chance to select plan1 is 50% , but I expect it should be 30%.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: monster creation

#2 Post by Dilvish »

Cjkjvfnby wrote:Question: Why we choose random plan based on number of plans?
for example: we have two plans:
plan1 (spawnrate = 0.3), plan2 (spawn rate = 0.7)
Chance to select plan1 is 50% , but I expect it should be 30%.
You might consider it to be akin to using an unbiased move proposal distribution in monte carlo sampling (emphasis on 'akin'). Suppose we have 200 systems, and they are all valid locations for both of these fleetplans. In the current scheme we would expect that over a series of such games, on average plan1 would be selected for consideration with respect to 100 of the systemsand and would actually be spawned, on average, at thirty of them. Plan2 would also be selected for consideration at 100 systems on average, and would actually be spawned at 70 of those on average. So our expected relative distribution is 3:7, consistent with a face value understanding of the relative spawn rates.

Suppose we instead selected the plans for consideration according to their spawn rate (and still did the separate spawnrate check); then plan1 would be selected at an average of 60 systems and actually spawn at an average of 18 systems, while plan2 would be selected on average at 140 systems and actually spawn on average at 98 systems, giving us an expected relative distribution of 18:98, or about 3:16 -- i.e., the relative distributions would be proportional to the respective spawnrate squared. That might also be a valid way to choose to do things, but it makes the interpretation of spawnrate and relative spawnrates more complicated.

If one gave up the second check, and just spawned the fleetplans at all 60 and 140 respectively, then we would have maintained our 3:7 relative distribution, but we would have spawned monster fleets at every single system, which is not really desired.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: monster creation

#3 Post by Cjkjvfnby »

Dilvish wrote:
Cjkjvfnby wrote:Question: Why we choose random plan based on number of plans?
for example: we have two plans:
plan1 (spawnrate = 0.3), plan2 (spawn rate = 0.7)
Chance to select plan1 is 50% , but I expect it should be 30%.
You might consider it to be akin to using an unbiased move proposal distribution in monte carlo sampling (emphasis on 'akin'). Suppose we have 200 systems, and they are all valid locations for both of these fleetplans. In the current scheme we would expect that over a series of such games, on average plan1 would be selected for consideration with respect to 100 of the systemsand and would actually be spawned, on average, at thirty of them. Plan2 would also be selected for consideration at 100 systems on average, and would actually be spawned at 70 of those on average. So our expected relative distribution is 3:7, consistent with a face value understanding of the relative spawn rates.

Suppose we instead selected the plans for consideration according to their spawn rate (and still did the separate spawnrate check); then plan1 would be selected at an average of 60 systems and actually spawn at an average of 18 systems, while plan2 would be selected on average at 140 systems and actually spawn on average at 98 systems, giving us an expected relative distribution of 18:98, or about 3:16 -- i.e., the relative distributions would be proportional to the respective spawnrate squared. That might also be a valid way to choose to do things, but it makes the interpretation of spawnrate and relative spawnrates more complicated.

If one gave up the second check, and just spawned the fleetplans at all 60 and 140 respectively, then we would have maintained our 3:7 relative distribution, but we would have spawned monster fleets at every single system, which is not really desired.
Thanks for answer.
PS. Is forum allow to make any notification about post moving? It make me little nervous when I did not find post where I leave it.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: monster creation

#4 Post by Geoff the Medio »

Cjkjvfnby wrote:PS. Is forum allow to make any notification about post moving? It make me little nervous when I did not find post where I leave it.
Posts are often moved to different subforums when they seem misplaced.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: monster creation

#5 Post by Vezzra »

Cjkjvfnby wrote:I simplify monster generator code. It should work in same way as previos.
I've committed a edited version of your patch, rev 7289.
In python instances of class inherited form object can be keys in dictionary.
Yeah, I know that, but I wasn't sure if that still applies when the object instance contains members that are mutable objects. But obviously that works.
Remove cycle, just make some filter on possible plans.
Yep, that's of course the simpler solution, but I was hesitant to take that approach because the location condition evaluation can be a very expensive function (depending on the complexity of the location condition defined in the content script). So I wanted to avoid calling this function for each monster fleet plan for each system. However, at universe generation that's probably not so much a problem, so I went with your suggestion.
Why we choose random plan based on number of plans?
for example: we have two plans:
plan1 (spawnrate = 0.3), plan2 (spawn rate = 0.7)
Chance to select plan1 is 50% , but I expect it should be 30%.
Dilvish already answered that, I just want to add that I more or less copied the behaviour of the original C++ function (made only one change to the implementation), so what you see here is what has been in the C++ code.

Post Reply