Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Reelya]

But you weren't arguing that before, and you are now. You brought up a whole slew of technical objections completely unrelated to "fun" in any sense, now you're shifting the goalposts after I brought up relevant counterpoints to your points. And I did in fact lay out the whole technical side of it right from the start.

I'd also argue that it might be bullshit that humans can tune physics setting for "fun" any more than a machine can. With automated learning you can control exactly how sensitive the controls are and the chance of success/failure, along with measuring how engaged the player is with the controls. If the player is just holding the same button down all the time, then you can rate the level of engagement necessary as being lower than an equivalent game where you need to change controls. e.g. a racing game where you hold the accelerator down 100% of the time is less engaging than one where you need to ease off on tight corners. And this is something you can in fact quantify. in fact, a human might suck more at this process than an algorithm, since the human can only tune it against their own level of skill, rather than tuning it against a range of possible inputs.

Given the existing parts of the game, I really doubt human "gut feeling" is actually going to be much better than that.

[wierd]

What you are trying to assert, is that qualia cannot be judged by an impartial algorithm.  I will disagree with that assertion. It will just reach different conclusions than that of humans at the worst case, or will reach the same conclusions in a different way at the best.

The requirement is that it reaches the same conclusion, not how it does it.

[Reelya]

@Ispil, But you then stated unrelated objections to a variety of things I said, which is a clear case of goalpost shifting. If, whenever you make a point, someone objects to each point based on entirely unrelated things, which are non sequiters, then it's clearly a case of objecting merely for the sake of objecting, by that point.

Like you were objecting based on the idea that I needed to come up with equations for the underlying processes, which isn't a valid point because that's nothing to do with how machine learning even works. The entire point of machine learning is that it's used to optimize something when you lack the knowledge of the equation you're trying to solve. GAs and NNs are expressly for cases when you don't know the equation, so you want to approximate the solution iteratively.

Co-evolution is for cases when you don't even know what question to ask, so you have one GA optimizing itself to win, and the other GA optimizing to beat that GA. This was the case I suggested could be used to both train a "controller" to do a jump, but the "system" to optimize the difficulty of the jump (in terms of how precise you need to be to make the jump).

then you were saying the GA would take to long to run. Which, come on, is a pretty silly objection since GAs are a very well established technology, and that argument has nothing to do with anything else, and since GAs are fundamentally a parallel algorithm, you can be running thousands of trials at once, so the time to produce one trial is effectively moot. Take a look at those genetic algorithm car game websites that were popular on bay12 a while ago. Those start with completely random cars and within a small number of generations only "good" cars are left running. And the generation time is far more than 5-10 seconds.

None of those objections had any connection to your main point, they were merely objections for sake of objecting.

[kilakan]

Not that I've read your discussion at all, but I now want a machine I can hook up to my body to measure body, chemical and neurological responses indicative of engagement and satisfaction.  Just so I can get a definitive feedback of how much fun I am having at any one time. 

This is realistically just a PTW though.

[Starver]

At my new work, they spend a lot of time fine-tuning this particular physics simulation in this game, by hand, and this has to be re-done whenever they change any of the related settings, so I wondered whether some sort of AI could actually optimize that sort of thing for you, they scoffed and explained "you can't optimize for fun". but isn't this just another example of people thinking that their job can't be automated?

If by "fun" you try to ensure that the inclusion of the Osmium Billhook into the higher-tier equipment lists majorly disadvantages every other choice of weapon, or failing to adjust the Three-Handed Nunchuck mechanics means that it is effectively nerfed against anybody capable of stockpiling the Potion Of Indeterminacy (that one readjusted in the light of adding the Visor Of LaForge), then it might well be useful to pre-screen such changes to ensure any intended Rock/Paper/Scissors(/Lizard/Spock) equivalence of dominance is still there, so as not to misbalance the playing styles.

And obviously simulating all combinations of a complex system is time-consuming, even as a developer with all the at hand.

(As a basic example, I give you this little conundrum, atop this other base, against all possible opponents then further complicated by the economies of supply and demand, which I can attest is a problem that does not quietly suffer a full brute force solution even in the middle tiers. For me, it was just an intellectual exercise, that outlived my actual interest in the game by many months, finding a less memory-intensive and nuanced bracketting system that yet sought out 'joker' combinations that stood out from the obvious crowd...)

But if you can run many of your game universes in parallel (and at full throttle), for the sake of suitably exploratory agents to 'play' in parallel against all PvE and PvP encounters and ensure that there are no hulking big blind-spots where fun-sinks occur (and also, along the way, tune your hard-coded NPC opponents to not be too hard or too easy against a particular standard of PC adventurer/whatever). It's probably a worthwhile exercise.

Depends on how much you can emulate a player, though.  Through a whole lot of real Skinner's Pigeons, players may well discover that a step back and to the left actually does convey a disproportionate attack advantage for the next three strikes. There's another web-game I play where counting to a certain number between initiated attacks, in a usually non-time-sensitive situation, seems to get one a succession of successes that one would not normally expect, and I have the impression that I'm exploiting cycles of periodic local maxima (or perhaps avoiding the minima, or maybe just sufficient  threshold-breaking in whatever direction) in the PRNG algorithm behind the scenes.


...erm. In short, you probably could take the players out of the equation, if you could get your virtual testers to be as tenacious and adaptable as your human ones before you then got them to run at hyperspeed across many parallel games, 24/7 to accomplish the work faster.  But, for that, you'd need to get a separate skillset in someone who could create your Virtual Testers for you, with at least a decent playing history as well.  (There's this kind of thing...)

[Starver]

Or is it just plopping the car on a ramp in whatever physics simulation and seeing whether they can make it or not?

Probably double-posting, I didn't realiae how far back I was when I made the last response, probably out of date (if this one isn't).

For the car on the ramp, take Hill Climb Racing as a perfect example. A jump in the game is possible if there exists for all practical vehicles¹ an opportunity to make the jump (or get up the hill, or make the distance between on fuelcan and the next).  But if there is just one possible way of doing this (you must have landed correctly from the prior jump, to give exactly enough run-up to scrape over the gap without also hitting your head on the ceiling obstruction), then it's a chore, especially if it's a chore that needs to be accomplished in order to endure the next chore...

What makes it "fun" is to encourage finessing (e.g. make it interesting to initiate a vehicle flip, on departure from the initial ramp, the spinning vehicle gaining more coins/buffering wheels-first against the roof/just looking more fun when you end up landing the right way up again) which means a range of speeds and take-off-point acc(/dec)elerations and subtle combinations of suspension compressions from the immediately prior landings on bumpy ground should still give you your successful jump, and if the player is fed up of face-planting (neck-flipping) continually when attempting a double forward somersault over a gap, then they ought to be able to remember that immediately after that particular wobbly bridge (or balanced girder, or whatever) they might want to only risk the one somersault, then retard their spin (unless they feel like chancing it!). But there should always be a not knife-sharp ridge of possibility. Hit/release the gas/brake peddle just too late/early, or with anything but exactly the right run-up profile and it should be touch-and-go, but not doomed to failure, and it should still be recoverable (with quick wits) so that the follow-up section of track isn't absolutely impossible.

But emulating every single nuance of vehicle control (especially if that involves finding the microsecond-perfect drum-beat upon the peddles necessary to turn a near neck-flip into a triumphant interception of the necessary refuelling icon pick-up) is impractical and does nothing to increase the "fun". Ensure that there's a 'corridor' of success, that merely narrows (multidimensionally) the further along the generated/painted track, by whatever means you (as developer) do it.


¹ And possibly for a certain minimum combination of vehicle upgrades, scaling higher further along the track, but ideally never exceeding the maximum upgrades.  Noting that some higher-spec upgrades can make "dumb flat-out driving" less 'safe' than when at a lower level of upgrade.

[Max™]

I imagine they would stick a max time on the damn thing. Which is what I'm asking for.

Who is sticking me where? The ™ is pronounced "Thyme" since it's how I sign my name.

[Reelya]

(As a basic example, I give you this little conundrum, atop this other base, against all possible opponents then further complicated by the economies of supply and demand, which I can attest is a problem that does not quietly suffer a full brute force solution even in the middle tiers. For me, it was just an intellectual exercise, that outlived my actual interest in the game by many months, finding a less memory-intensive and nuanced bracketting system that yet sought out 'joker' combinations that stood out from the obvious crowd...)

Actually that looks fairly trivial compared to stuff they did a long time ago.

Google Eurisko. Basically, back in the pen and paper days they had a competition to design and play space battles using Traveller rules.
http://aliciapatterson.org/stories/eurisko-computer-mind-its-own

On the July 4 weekend of 1981, while many Americans were preoccupied with barbecues or fireworks displays, players of an immensely complex, futuristic war game called Traveller gathered in San Mateo, California, to pick a national champion. Guided by hundreds of pages of design rules and equipment specifications, players calculate how to build a fleet of ships that will defeat all enemies without exceeding an imaginary defense budget of one trillion credits.

To design just one vessel, some fifty factors must be taken into account: how thick to make the armor, how much fuel to carry, what type of weapons, engines, and computer guidance system to use. Each decision is a tradeoff: a powerful engine will make a ship faster, but it might require carrying more fuel; increased armor provides protection but adds weight and reduces maneuverability.

Since a fleet may have as many as 100 ships -exactly how many is one more question to decide -the number of ways that variables can be juxtaposed is overwhelming, even for a digital computer. Mechanically generating and testing every possible fleet configuration might, of course, eventually produce a winner, but most of the computer's time would be spent blindly considering designs that are nonsense. Exploring Traveller's vast "search space," as mathematicians call it, require the ability to learn from experience, developing heuristics -rules of thumb -about which paths are most likely to yield reasonable solutions.

In 1981, Eurisko, a computer program that arguably displays the rudiments of such skills, easily won the Traveller tournament, becoming the top-ranked player in the United States and an honorary Admiral in the Traveller navy. Eurisko had designed its fleet according to principles it discovered itself -with some help from its inventor, Douglas B. Lenat, an assistant professor in Stanford University's artificial-intelligence program.

"I never did actually play Traveller by hand," Lenat said, three years later. "I don't think I even watched anybody play it. I simply talked to people about it and then had the program go off and design a fleet. When I went into the tournament that was the first time that I had ever played the game."

Eurisko's fleet was so obviously superior to those of its human opponents that most of them surrendered after the first few minutes of battle; one resigned without firing a shot.

...



"They changed the rules significantly and didn't announce the final new set of rules until a week or so before the next tournament," Lenat said. "The first year that would have not been enough time for me to run the program to converge on a winning fleet design." But Eurisko had learned heuristics that were general and powerful enough that they could be applied to new versions of the game.

"We won again and they were very unhappy and they basically asked us not to compete again. They said that if we entered and won in 1983 they would discontinue the tournaments. And I had no desire to see that happen." So Eurisko retired undefeated.

Yeah, we'll I'd say if you're having a problem now with optimizing against some ruleset it's not the fault of the tools ... people were using modified genetic algorithms to solve similar problems almost 40 years ago. And remember this guy never even played the game, he just coded a genetic algorithm to try and devise some design rules via evolutionary means. Basically he tweaked things by having the system work on the meta-design level. e.g. it would code rules such as "adding more guns is a good idea", then when it needed to redesign the ships it would pick rules at random, and if those rules were correlated with improvements, they'd get a higher weight on the next round. It's not really rocket science.

[Reelya]

My main point is that the idea of "fun" might be a red herring. We can quantify things such as difficulty and how much you need to engage to complete a task. At least for twitch-based games.

Then we can in fact optimize things so that outcomes are clustered near the success/failure point, which I'd argue, is where the "fun" of physical twitch-based challenges lie: the tipping point between success and failure. And with a genetic algorithm feeding "player controls" in we can simulate variation in input simply via the GA mutation rate in the inputs, which would give a metric on how difficult the task is (i.e. how exact or sloppy you can be and still win).

So you could tune a challenge such as jumping over a pit, so that you need to be about 60% accurate with your controls, and you have about a 70% chance of making the jump at that level of accuracy. And you also keep metrics such as how many "close calls" there are, and you rate physics simulation / level design settings which maximize those close calls as the highest. So in a limited context such as arcade games, I'd argue you can totally automate metrics for fun.

[Reelya]

Ok back on the tech track ... more info showing what a lovely example of corporate culture Uber is:
https://news.slashdot.org/story/17/04/13/1452215/ubers-hell-program-tracked-and-targeted-lyft-drivers

According to The Information, the ride-hailing company's covert software-based program called "Hell" spied on its staunchest competitor's drivers from 2014 to early 2016. It's called Hell, because it served as the counterpart to "God View" or "Heaven," Uber's in-company app that tracked its own drivers and passengers. Unlike God View, which was widely available to corporate employees, only top executives along with select data scientists and personnel knew about Hell. The program apparently started when Uber decided to create fake Lyft rider accounts and fooled its rival's system into thinking they were in various locations around the city. Those fake riders were positioned in a grid to give Uber the entire view of a city and all of Lyft's drivers within it. As a result, the company can see info on up to eight of its competitor's nearest drivers per fake rider.

[Starver]

(As a basic example, I give you this little conundrum, atop this other base, against all possible opponents then further complicated by the economies of supply and demand, which I can attest is a problem that does not quietly suffer a full brute force solution even in the middle tiers. For me, it was just an intellectual exercise, that outlived my actual interest in the game by many months, finding a less memory-intensive and nuanced bracketting system that yet sought out 'joker' combinations that stood out from the obvious crowd...)

Actually that looks fairly trivial compared to stuff they did a long time ago.

With an intelligent solution, it's not bad, but I mentioned Brute Force.

Let us imagine we're only interested in Blue vehicles (top of the Green<Blue middling tier, and capable of using Yellow/Green/Blue mods and weapons) so willing to assume that sub-blue vehicles aren't worth bothering with, with their generally inferior stats and ability, whilst staying away from the Red+ tier that gets darned expensive).

From the Chopper with 6 slots to the the tractor has 15 slots of capacity, you can try to fit in 36 different mods (the 12 blue ones are the best, but they take up two slots, so you can't ignore the Y/G ones), and any slots you don't want to fill with Mods you might want to (or need to, due to the mods you have chosen) put Y/G/B weapons (15 possible types, but can be simplified to the three*(slots filled) combined Attack plus Defence scores you need to "denullify", and any remainder Attack+Defence you  can just make subvariants with all overflow bonus as attack through to all overflow bonus as defence, then when you try to 'build' your vehicle you can choose which combination of the five Blue weapons does what you need, but you can ignore that for now.  And for cargo-carrying (or highway robbery) purposes, you need at least one capacity kept spare to do anything useful, so not-totally-filled-slots combos are important.

Take the Tractor. 15 capacity, fully Brute Forced you'd permute a 15-bit bitstream. You can actually do some intelligent jumping based on capacity overloading prohibiting many of the permutations, so it isn't 2¹⁵ combinations. You can also do some intelligent pruning by keeping note of other deficit (sub-zero) stats, not just the Cap, and comparing to the available 'buying power' from the rest of the bitstream yet-to-be-decided. But it's still a bit intensive.

Thus you get all possible vehicles. To save time later, store the 'template' of this valid (but yet to be tested) vehicle 'build' as a record of some kind.  Vehicle ID (of five, so three bits maximum, but that's only if you're cutting the bitwise footprint of the record to the bone), plus which mods (15 bits) plus what (surplus) Attack and or Defence you have (or derivable), plus untouched capacity value. You might as well just store all the resulting buffed/nerfed stats (which you have ensured do not fall below zero) on the record, to avoid having to recalculate each time you pull it. If you value storage space over CPU cycles you can asking for recalculation, each time, but you'll be calling those calculations a lot.

I can't remember exactly how many 'valid vehicle combinations' there were, but ISTR that (in a non-combative, recordless dry-run) my counter tallied up a figure was in the trillions, and that may well have been the long-measure trillions that I like to use, not the short-measure one I'd be using in conversation with others.


So, now, if you're looking for an optimal vehicle, you need to 'send it out' against opponents. Potential trading vehicles (defensively) against prospective Highwaymen (offensively) we already have on record, Highwaymen (aggressively) against (passive) Traders and Highwaymen vs Guards in offensive vs offensive battle.  So for each vehicle you add to the stack, you need to pit it against all vehicles already on the stack in all combinations of combat (though you could ignore trying a vehicle as a Trader that had zero capacity left, unless you just wanted to send out 'spoiler' vehicles) and keep a tally of win/lose/draw totals in each capacity, within that vehicle's record (with the corresponding result increment in the opponent's tally, already having been previously tried against its predecessor permutations, now needing to remember how well it does against its successor ones).
A trillion-or-so successors fighting each other (and themselves, I suppose). Factorial of a trillion or more.  Doesn't really bare thinking about (long or short trillions!).

So that idea is clearly out, and I didn't even try it.  (It can be done for Yellow-tierers, as that was my proof of concept, but forget a full Blue vs Blue (every possible valid combination) matchup tournament.)

The way I optimised it was to use "ziggurated batches". Some arbitrary number of vehicles (at a time) would be "zeroth level" matched, every vehicle from this subset against every vehicle from this subset, enough to contain (say) twenty different vehicles per 'role' per vehicle types represented. Once I hit that limit, I culled off all vehicles combos that were not in the top ten (of any particular role for any particular vehicle), and put them into the newly-created 1st level, emptying the zeroth level cohort and rezeroing the promoted vehicles' win/lose/draw statistics, and restarting filling the zeroth from the next permutation. Except that when the first-level cohort numbered more than twice the zeroth one limit, I matched all first-levelers so accumulated against each other and (by the same top-ten-in-anything measure) bumped the ones that I needed up to the second-level tier (clearing their w/l/d stats and the first-level 'waitlist').  Etc.  The second-level tier had three times the base capacity (really, the multiple was level#+1 from a zero-base...  It could have been straight level# from a 1-base, but that' s how I coded it.) Until the very last permutations passed into the zeroth level, when promotion and re-fighting happened straight off at each level to get the (worthy) stragglers competing with each other until the "ten best FOOs" lists got generated at the top. Not actually proven every-combo-vs-every-combo, but the test at Yellow and Green level complexities (against the raw results of the more brutal of brute force run-throughs) indicated something of a reasonable match between the results of the two methods.

Again, can't quite remember the limits I applied, but with the (increasingly generous capacities of each new layer of the ziggurat, even given the much larger amount of culling/non-promotion) I think it topped out at Level 8 or perhaps 9 in the "final all vs all" competition, after a very long continuous run.  (I truly regret not having put a SIGINT catcher into the code, to sanely dump all existing data to file, ready to be picked up again on the next start-up, perhaps even to let me move it onto new hardware. But once the latest version of it was running, it was running, and I didn't like to stop it.)


How to do it less brute-forcedly?  Assign a number (100? 1000?) separate, or at least faux-concurrent, agents a vehicle. Let them pick and choose a mod to add, and check it for viability (no sub-zero stats), and let them choose another mod (or combination of weapon buffs) if necessary to bring it back into validity.  Take the best (by 'top-ten'ness, maybe twenty...), split and multiply across the 'design teams' for another adjustment (add, remove, change - plus further changes that might be needed to make this variant also valid). Rinse, repeat.  Noting that this random walk may well miss out on huge areas of evolutionary landscape where a true 'killer' combination actually resides, that intelligent study might well have discovered.

Maybe I'll try that, though, and compare it to whatever results I can still pick up from my prior experiment.  (But I aint running that again... Not without the abort/continue safety net, at least. )


((And this is before working out the 'genetic algorithm' bit, I know, but my point was on the brutalist approach.))

[Reelya]

Actually a better way might be to work out what the average cost of each type of upgrade point is, then use a genetic algorithm to work out what your optimal point-spread would be based on average costs, fight these entirely generic "cars" against each other, then run a separate GA to try and find car combos that match that optimal design as close as possible. And/or taking a leaf out of the book written by Eurisko, you run tournaments of randomly designed cars. You then adjust the "score" of every part based on how well the overall car did. After enough rounds then some parts will have higher scores than overs. To get even cleverer, you cross-reference parts by pairs, e.g. if two parts together positively correlate to performance (as an average over lots of cars) then you can give those an additional factor when they're in the same car.

However, your main point was that rock-paper-scissors type relations need to be preserved by any automated balancing. Sure, but you can in fact specify that as a design criteria going into the system. e.g. "cars with high attack items should beat cars with high defense", and you can have the system work within that constraint. Also, running genetic car tournaments as described above would ensure the balance exists as desired. Hand crafting a bunch of weapon tables on the assumption that there won't be any game-breaking exploits actually sounds less promising here. If a computer can merely try out billions of combos and that's not enough to rule out exploits, then how can you rate humans highly at detecting exploits? Humans shouldn't delude themselves about their ability to permutate all possible combinations of a numerical system. Humans tend to design things by simple rules of thumb and to mentally disregard "unlikely" sounding combos automatically. So human's abilities in this regard give them a quicker route to some answers at the expense of pruning large sections of the tree without considering them.

[Starver]

The cost of upgrades is most simply "loss of spare cargo capacity". At least as far as taking up the Trader of Highwayman professions, is concerned.  There's the fluctuating costs (directly, or in buying/renting the mines from which you become the first owner of any items) of in-game currency needed to obtain the equipment (and bolts to attach it all!), but the markets could be fickle, so I left the weighting of that factor at barely significant.

And there's the difficulty of both multiple parallel metrics¹ and a round-robin dominance strategy², which complicates the topography of which combo is 'better'.

And did I forget to mention Gadgets, that give time-limited bonuses, that I didn't even bother to try to model (as possessed by oneself or one's hypothetical opponent), and Meld Boosts to the Armour values (which could easily de-negate an armour-negative Mod, like the missile turret, even making an invalid build opetate validly again) are another thing you might wish to consider adding (at least to the representative foe-setup) as a variant value, even if you plugged your own current value into the combat simulator.

You see why I stuck with the problem longer than I did the game it applied to, though.


¹ Trader setup (that must have at least one cargo slot) which does well against Highwaymen of all kinds; Highwayman setup (that probably ought to have cargo space for spoils) which dominates against Traders and holds its own against Guards; Guards (which can 'liberate' stolen items from Highwaymen, but probably just needs to cause them problems) who have to work against the top Highwaymen.

² Dodge beats Offence, Offence beats Defence, Defence beats Attack, Attack beats Dodge. Though as Offence only helps non-Traders, this might be a useful polarising point in the incomplete circle of dominance.

[Max™]

Well you know me, as a curmudgeon I am obligated to take part in any opportunity to shout to the world "FUCK YOUR ADS, GET OFF MY LAWN" and proudly do so.

Hah, I'm such an ass that like 90% of those can't even be set because I refuse to let the type of cookie necessary on my browser.

[wierd]

I must be incurably cynical.

To me, all these advert firms will do when given the finger like this, is wonder why people dont want their amazing services, then go out of their way to target the people who opted out. Kinda like the whole "do not track" flag.