Joined: 4/25/2004
Posts: 615
Location: The Netherlands
And you can still have a bot that relies on heuristics. Lua has it's own rng so you don't have to implement one. Also, I'd love to see a neural bot! Seriously!
qfox.nl
Active player (354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
DarkKobold wrote:
DaTeL237 wrote:
(...)
So wait... no neural network bots?
if you think a neural network will work then sure, but I'd say the training phase will have to be done in your time (not during a 'match') ... after that a NN will run realtime without trouble
TASes: [URL=http://tasvideos.org/Movies-298up-Obs.html]Mr. Nutz (SNES), Young Merlin 100% (SNES), Animaniacs 100% (SNES)[/URL]
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I see that problem, however you can train it and initialize the node values and edge weigths by the script's init function.
qfox.nl
Active player (354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
qFox wrote:
I see that problem, however you can train it and initialize the node values and edge weigths by the script's init function.
ok yes it's theoretically possible... but my (limited) experience with NNs says that (A) you'd need a lot of computational power, far more than any reasonable limit in this contest and (B) you'd always have to check manually whether the training yielded a feasible result? don't get me wrong btw... I'd also be very pleased to see one work :P
TASes: [URL=http://tasvideos.org/Movies-298up-Obs.html]Mr. Nutz (SNES), Young Merlin 100% (SNES), Animaniacs 100% (SNES)[/URL]
Banned User, Former player
Joined: 12/23/2004
Posts: 1850
I don't see why you don't just use a ruleset that disallows savestates and readaheads. That way, you could simply call "player_game(controller)", and have that controller return a table with what buttons to set based only on current and previous frames. As I said previously, allowing the usage of savestates turns into another problem entirely; namely, how far ahead can it search to find random input that works?
Perma-banned
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I don't see that problem really. As the framework shows, there is a number of allowed operations (equal to everybody). The framework will create its own savestate prior to calling both bots to ensure they both get a "clean" state and the second call is to make sure the bot gets a proper chance of supplying input (in case computations exceed the given max). I don't really care how far ahead a bot wants to look, trial and error or whatever. All bots have the same restriction/options so I don't see this as unfair in any way? However, if everybody feels savestates should be out then that's what we'll do, obviously. But as far as implementation goes, I don't see the problem. Optionally we can make savestates more expensive (note that savestates are already implicitly limited by the max number of operations per frame).
qfox.nl
Banned User, Former player
Joined: 12/23/2004
Posts: 1850
... hm. "local maxops = 2000;" What is an operation? Is it any command? If so, how can this possibly be enforced? There is no strict unit of meaurement, unless you actually want to claim that it can only perform 2000 unique commands? (For example, if you count "if" statements, my Pinball Lua bot runs at about ~50-300 operations per frame. Consider it only does immediate hitbox checking with a tiny bit of prediction.) What is stopping a bot from counting, say, progressing a frame as an operation, meaning it can run 33sec ahead of the rest? Or even just flat-out ignoring the maximum operations counter? ... My specific problem with allowing look-ahead is that it turns from a game of "be smarter than the opponent" to "have decent intelligence and make sure no gameover is coming in the next x frames." To demonstrate this point, Bomberman. A poorly written bot would wait several seconds and see if it is killed within that time period, and if it is, try moving somewhere else and then wait more. Repeat ad nauseam. Compare to a bot that cannot implement seeing into the future, where it would actually have to figure out if it was in immediate danger. Case in point, I added "operations = operations + 1;" after almost every line of code in my script. "if" statements with mulitple conditions got more assigned depending on how many, and multiple if-then-then statements were cumulative (e.g. 1, 1 + 3, 1 + 3 + 2, etc). You need to choose a value wisely, or else you might as well be choking complex bots or just simply disregarding it.
Perma-banned
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
No, a function will be programmed in C to kill a function after x operations have been executed. I'm not sure yet on the specs of what constitutes an operation, but you can be certain that it can't be avoided or ignored. :) This way everybody will have EXACTLY the same constraints as everybody else, and better yet, can test this on any computer (since the operations limit is time independent). This allows contestants to test their bots at home and be sure that the bot will function properly on the (possibly slower) computer of a judge. If the constraint was time, a coder on a fast computer would have to anticipate the speed of the computer of the judge and adjust the bot to a guessed time constraint.... And to repeat, the fceux.run(function, ops) will execute a function and kill it if it crosses the given number of operations. Killed by C, so it cannot be influenced by Lua (nor the bot). It's like you can't prevent yourself from dying, eventually, but "god" can ;) But you can take your own life, like the bot function can just return :) The exact number of operations will have to be found by trial and error. I have no idea at the moment.
qfox.nl
Banned User, Former player
Joined: 12/23/2004
Posts: 1850
Then I certainly hope you decide to provide a method of determining just how many operations have been consumed or else you risk having some very, very annoyed progammers as they try to figure out just where they are at. Moreso if, say, setting a variable increments it by one.
Perma-banned
Editor, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
For something like Bomberman, is it permitted for a robot to use magical precognition read the RAM to see immediately where the actual bonuses and exits are located, instead of trying to guess?
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Xkeeper: I'll ask, should be possible... Bisqwit: I see no problem with that, every bot can read it so there's no advantage. It's a matter of strategy.
qfox.nl
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok so I'm thinking of a short trial contest to get things straight. After some discussion with Xkeeper we'll try it without a limit. That means you're responsible for your own constraints. However, be warned that I'll knife yer bot if it takes too long. You can do the math for yourself. If it takes 2 seconds for each frame to finish computation, it takes too long. I've put two example scripts on the site to play with ( http://cbc.qfox.nl/news ). Unfortunately FCEUX seems to be bugged at the moment (for me anyways) and won't accept player 2 input when you set player 1. Kinda weird that nobody reported this so far. Anyways, I think we should start with a short compo, say two weeks, with an easy game. Just to see if things work out properly. So I'd like a simple game that doesn't take a lot of work. Probably a two player game like tetris, boxing or something like that. Something that doesn't take a whole lot of time :)
qfox.nl
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
The Lua input bug has been fixed. You can get the latest interim build (which also has this bug fixed) here: http://fceux.com/zip This does not include that limiting run function (since we won't use it for now).
qfox.nl
Moderator, Senior Ambassador, Experienced player (900)
Joined: 9/14/2008
Posts: 1007
qFox wrote:
The Lua input bug has been fixed. You can get the latest interim build (which also has this bug fixed) here: http://fceux.com/zip This does not include that limiting run function (since we won't use it for now).
Ahh, good - I found the "only one player's input is accepted per frame" issue with my item finder script (now at http://lua.pastey.net/97912) but I didn't really say much about it - sorry about that. Thanks to those who fixed it! A.C. ******
I was laid off in May 2023 and could use support via Patreon or onetime donations as I work on TASBot Re: and TASBot HD. I'm dwangoAC, part of the senior staff of TASVideos as the Senior Ambassador and BDFL of the TASBot community; I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok I've spent most of this day finishing up the website for this contest. You can find it at http://cbc.qfox.nl where you can signup and whatever. I've created a submission system where you can post wips that anyone can see or submissions that only judges can see. The current contest page will list all the files uploaded for that contest (whether you can actually view the contest depends on whether it was uploaded as wip, or on you being a judge :) What needs to be done now is to have the general rules and regulation texts set up properly (for as far as it's not fine this way). We need to pick a simple game to start with (for the 2 week trial contest) and set up a goal for it. Last but not least a startup lua script has to be created for it. Anyone wanna help here?
qfox.nl
Editor, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
qFox wrote:
I see no problem with that, every bot can read it so there's no advantage. It's a matter of strategy.
Well, how about ― is a bot allowed to WRITE to the game's RAM when it performs a look-ahead (but not when it's actually submitting a frame of input)?
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Yes. The masterscript makes a savestate before handing over control to each of the bots. Uppon return, the state is loaded again. So it doesn't matter what the bot does then. Hm, maybe I should remove that rule altogether since the masterscript will determine input anyways. -- I've edited the rules. I've removed the rules about manual input, savestates and memory writing and added two rules about not messing with the master script and not being slow.
qfox.nl
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I've started the pilot compo with Tennis for the NES. You can find the topic here: http://tasvideos.org/forum/viewtopic.php?p=182277
qfox.nl