Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Bisqwit wrote:
LagDotCom wrote:
(...) I'll elaborate: a Bomberman bot needs to exercise many algorithmic challenges, most notably involving path finding.
I think simpler rule-based bots could have decent emergent intelligence...
(e.g. "if bomb in same lane, get out of lane", "if enemy nearby, drop bomb", etc (OK it'll require some more decent design decisions ofc :P))
edit: I'm not sure but intuitively I'd say the path finding shouldn't be that complicated, considering the bomberman world are 'only' 4-connected squares)
For bomberman, maybe a "skeleton" script could be created that players could then plug in various bots -- ie create a function that gets called every frame for each player -- that way bots could battle each other.
Something like:
--start game
function update()
player1setinput()
player2setinput()
...
end
gui.register(update)
while true do
FCEU.frameadvance()
end
Players would provide just the function player1setinput etc
Same idea could be used for any multiplayer game... Urban Champion anyone :P?
Same idea could be used for any multiplayer game... Urban Champion anyone :P?
That sounds a bit simple. Probably all of the bots will achieve the same AI level after a while.
On the other hand, fighting games sound great; I'd love to see some Mortal Kombat II bots fighting each other. :D
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Alden: even simpler: have the function just return the player's input, and then the "overseer" function applies that input to the game. That makes it easier to enforce a "read-only" rule for the functions -- they shouldn't be allowed to update the game state, only read from it.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Hmm... Bomberman 2 has up to 3 players simultaneous... the SNES ones allow 4 or 5.
MKII or SFII would be neat.
We could also just have a set of 5 to 10 challenges suggested by people and have people do any/all they can.
For example, write TASvideos.org in Tetris :D
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok, so there is enough interest, let's focus on some ground rules and other ground work. What else do we need for this to work? Deadlines for instance, who decides what.
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Derakon wrote:
Alden: even simpler: have the function just return the player's input, and then the "overseer" function applies that input to the game. That makes it easier to enforce a "read-only" rule for the functions -- they shouldn't be allowed to update the game state, only read from it.
I agree that the player's functions should only return input and the arbiter-script should apply it. How's about limits computational power? just stay within reasonable domains? (e.g. everybody's script should be able to run for four players simultaneously in real time)
any rules as to what memory can be read? can pixel-colors be read? or should the arbiter-script be the only one reading memory and putting it in some global fields?
deadlines imo are to be determined by the person that will organize it all, i'm not sure but I'd say a month is reasonable? could be horribly wrong in both directions though :D
edit: oh, it's very important that everybody is using the same emu (and plugins?).. so the organizer/judges should make the settings very very clear
maybe some bomberman specific rules would involve the requirement of non-passiveness (cant have 2 players waiting for eachother to take initiative forever).... although i guess the ingame timer is a form of this
edit2: maybe obvious... but imo every contestant's script should be made public after the tournament (and should not be forced to do so before the deadline)
any rules as to what memory can be read? can pixel-colors be read? or should the arbiter-script be the only one reading memory and putting it in some global fields?
I think any memory can be read. Pixels should be able to be read too, although if FCEUX returns the color and not the palette index, you have a problem (not everybody uses the same palette). Unfortunately, it seems to return the raw R, G, and B values instead of the index.
One thing to consider is that players will not always be constant. This is important when considering memory addresses (obviously), as changing joypad.set(2,...) doesn't make it read the correct variables for the player it's currently playing as :)
First of all let's pick one of the many Bomberman games and fetch a list of useful memory addresses, hmm? Then we can worry about implementation later. :)
Tengen's version of Ms. Pac-Man might be interesting too, since it has 2-player-simultaneous modes.
Besides trying to maximize points, the two bots could share tasks and try to survive as long as possible in the co-op mode, or try to kill each other in the competitive mode... :p
As for Bomberman, I'd say go with Super Bomberman 5 on SNES...it's all kinds of awesome. :D
Xkeeper wrote:
although if FCEUX returns the color and not the palette index, you have a problem (not everybody uses the same palette). Unfortunately, it seems to return the raw R, G, and B values instead of the index.
Is it possible to read the PPU memory from a script? Maybe that could be used to get the index of a color...
My favorite is by far Super Bomberman 3 (also released as Mega Bomberman for the Genesis and Bomberman '94 for PCE, well, I think they're very similar anyway), but I don't mind using any of the others.
We already have nitsuja's TASes of the first 2 games, with very long submission texts, so maybe we should pick one of these two if there's some useful information in there.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Just for technical notes, Lua does allow for some pretty powerful sandboxing. Two scripts can each expose a function to be run. The arbitrator script can give each function its own set of global variables. You can give access to the memory.read functions and any other limited access functions you want. Number of CPU cycles is already enforced by the emulator using lua's "hook" functions. Just override them (you lose run-away script protection though) and you can kill any function that tries to run more than a certain number of CPU cycles.
And so on and so forth.
We don't have any Pokemon game on systems with Lua support.
Also, Pokemon sucks. :P
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Technically, you can. Open the rom as file and read the appropriate byte from it :) (But point taken :)
Ideally it could be done though the emulator.
Not only that, but as far as I can tell, there's no way to get the name and location of the current ROM from the emulator :)
Lua World Championships 1990.
Then we could find someone with photoshopping skills to change "Nintendo" to "Lua" on this image, and then use it as our logo:
If we can find someone with even better PS skills, we could update it to "Lua World Championships 2008" or something.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
If we can find someone with even better PS skills, we could update it to "Lua World Championships 2008" or something.
