Wednesday, April 24, 2013

pom decision frequencies + html5

POM3 Results (Showing POM3A and POM3B):

10 even width bins between min and max
min <= val < bin1
bin1 <= val < bin2
...
etc





HTML5

Popular Buzz Word of recent; very powerful (cool and fast) with Javascript + jquery + CSS3.
(initially opened in 2011, updates in 2012, became a WC3 recommendation Dec 2012.)

- Some stuff that's new with HTML5: http://net.tutsplus.com/tutorials/html-css-techniques/25-html5-features-tips-and-techniques-you-must-know/
- HTML5 is the way to go today.

Tools:

http://craftyjs.com/ - a game library set of tools for javascript to make html5 games
(one of many, there's also game engines and interface-only designers not-for-free)

http://html5games.com/ - popular web site to submit your games and gain audiences/revenue
(there are several other sites, as well)

My Fun-box site & Test of HTML5

fun.unbox.org/testgame

IBEA vs NSGAII for large feature models

10 runs for 2000sec each. pop=300, xover=0.05, mut=0.001, 5 obj

      IBEA With Rule Fixing
FM Features Rules %correct TimeToAnyC TimeTo50C TimeTo100C
toybox 544 1020 40.4% 28.4 NA NA
axTLS 684 2155 99.6% 45.2 187 224
ecos 1244 3146 100% 93.2 115 223
freebsd 1396 62183 98% 315 501 NA
fiasco 1638 5228 99.6% 170 656 810
uClinux 1850 2468 38% 75 NA NA
busybox 6796 17836 1.98% 1350 NA NA

      NSGA-II With Rule Fixing
FM Features Rules %correct TimeToAnyC TimeTo50C TimeTo100C
toybox 544 1020    
axTLS 684 2155    
ecos 1244 3146 0% NA NA NA
freebsd 1396 62183 0% NA NA NA
fiasco 1638 5228 2% 61 NA NA
uClinux 1850 2468 3.33% 26 NA NA
busybox 6796 17836 1.17% 1110 NA NA

Wednesday, April 17, 2013

DIMACS feature models

IBEA With Rule Fixing NSGA-II With Rule Fixing
FM Features Rules %correct TimeToAnyC TimeTo50C TimeTo100C %correct TimeToAnyC  TimeTo50C TimeTo100C
toybox 544 1020 25% 23.2 NA NA 12.4%
axTLS 684 2155 100% 43.8 333 NA
ecos 1244 3146 100% 87.8 129 NA
freebsd 1396 62183 98% 377 717 NA
fiasco 1638 5228 100% 104 444 NA
uClinux 1850 2468 32% 47.8 229 NA
busybox 6796 17836 18% 1190 NA NA

Wednesday, April 10, 2013

GALE + PCG

Updates to GALE:

What if while recursing in RRSL clustering method, we only go down 1 level (split only a single time)?   Previously, we were going down  4 levels (because rstop = square root(mu=100)).

NOTE: We tested below on a really small sample for quick results, using rho=0.005.  That means we were running GALE for a -long- time, and still get results under <30 numEval.  With rho=0.10, the numEval would be ~ 4-5.







Introducing SBSE into game design in two ways:

1) "Outer Loop"

decisions = {all the features used to build the game} *these are categories and non-numeric*
evaluate = the player plays the game, and rates it 0-5 stars across categories
objectives = the player rating (aesthetic, story, gameplay, replay, overall)

A designer builds the game (a supply of the decisions).  Then, a player plays it (evaluates it across objectives).  The evaluation is human feedback, which is subject to human error and bias.  It takes a long time for a player to play the game.  It takes a long time to get the feedback.  And the feedback may not even be correct.  SBSE can be theoretically used, but it would take decades.

GALE can speed this up, tremendously.  But there's still the risk of human error in the feedback.  The method of evaluation is subjective here.  And the decisions may not be easily modelled at all.

2) "Inner Loop"

There are many "inner loops" that complete the single "outer loop" for the whole game.

decisions = {parameters that define one feature of the game} *introducing PCG*
evaluate = the player plays the game, and is scored on his/her performance w/ respect to that feature
objectives = the player score (points, accuracy%, evade%, time taken, etc)

A designer builds the game.  The game supplies the decisions to a PCG module in the game; i.e. the generation of random AI (speed, strength, defense) enemies.  The player plays the stage in the game for which these enemies are met.  After completion of the stage (or failure to), the player is graded across objectives: for example, points, accuracy of hitting the enemies, evasion rate of avoiding enemies, time taken before death or completion, etc.

The inner loop provides SBSE a way to search on the fly while the gamer is playing.  It avoids the issue of human bias/error.  A single stage can be rapid, and there is no overhead of feedback.  The game attunes itself according the players that play it, and searches for optimal PCG that can provide entertainment on the assumption that when players score well, they are having fun.  With GALE, a user only needs to play ~2-8 games before seeing decent results, and after 20 results, the optimality should be superb.