The server could be even on another computer.įrom there, it kind of naturally evolved into a multiplayer game. So I thought, maybe I could write a "sandbox" roguelike for bots like that? Then I thought that a client-server architecture would be perfect for this: your bot would be a custom-written client that can talk with the server over a specific protocol. I think the concept is really interesting: you have a bot trying to play a game that is pretty difficult for humans, and involves imperfect information and a lot of risk assessment. There are also many projects for NetHack. Famously, Angband has its Angband Borg, which also serves as an automated test of sorts, and can be even used as a screensaver. I can't find the source for that, but I remember reading that in every new version, the Rogue authors tried to include a feature that broke Rog-O-Matic – and then Rog-O-Matic authors tried to keep up. There is a fascinating story of Rog-O-Matic, a bot written to play (and win!) Rogue. Making Grass, part 3: Scene graph and performance.Also, not all info is equally important, so we'd probably want Depth (for example) displayed prominently.Part of a series about Grass, a real-time roguelike engine with pretty graphics. And we'll need to display what *band(s) this monster is found in. But I know that professionals in image manipulation could do it in an hour or less. But I don't know off-hand how to take the big image of all the tiles and turn it into one image for each tile and name it appropriately. For example, if we're legally allowed we could put Shockbolt's icon up there. If anyone has ideas how to liven up that template, that'd be awesome. It would be handy, I think, to have identically named monsters from similar *bands share a page as well, but that's undecided. I think we'll want a little drop-down menu to display statblocks from different versions but I haven't gotten that far. Then people can edit all around the statblock - tips and tricks, Tolkien history, whatever - and when the data changes I can replace the statblock and leave everything else untouched. My current idea is to generate a new page for each monster and fill that "statblock" table with the data. I created a really basic page on the wiki here: I don't think I have Wiki database access yet to add it to the new wiki. I've written a Perl script that parses monster.txt and monster_base.txt. I propose that most of us focus on getting data online for V as proof of concept and we can post our angband -> SQL statement parsers for rodent or quirk to tweak for their variants although I don't think either of them is likely to like SQL very much. I think monster lists are a good place to start, even though V makes this complicated by having base types we'll need to display eg resistances and vulns inherited from on the page. Given the plurality of variants we will probably want a single page for a green icky thing rather than having green icky thing pages for every version and variant. There are lots of details to hash out in part 2. We do not want to parse an entire r_info.txt every time we serve a page. Part 2 is extending our wiki with PHP which gathers this info from the databse where we've put it. This isn't going to be an exhaustive list of info and will be a different process for different variants. The plan is to add lots and lots of tables full of info populated with values read from the.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |