|
On November 28 2012 02:59 marvellosity wrote:Show nested quote +On November 27 2012 10:50 Keirathi wrote:I think the most common way is for the scum to specify the person to carry out the NK, then in absense of them specifying, it is randomed. Like you said, one person has to carry out the kill or things like town Roleblocker are pretty useless. Then, it doesn't matter what role carries out the kills. Some hosts don't allow scum with an active ability to carry out the kill and use their action in the same night, though, and some do. It's just host preference stuff again  For the RB thing: If you're handling all roleblocks simultaneously, then no, the kill would not go through. That's why I chose to give scum roleblocks priority in Mario. yeah it depends on the game. definitely it's usually carried out by a player. but for example in GMarsh's games I think the KP is factional, as the roles present are doctor and no jailkeeper/town rber.
I know Ace's DFM2 had factional KP (of course, that could not be called normal by any stretch of the meaning). Also, I seem to remember a game in which roleblockers blocked only 1 ability, so a scum framer tasked with framing and shooting, but being roleblocked, would only get his frame roleblocked, while the kill would still happen. No clue whether that was in a normal or themed game, though.
Even normal games have a large variety of this kind of specifics, as we discussed on Skype. I think you can believe Marv when he says that most hosts would rather host the game by hand then have such specifics set in stone. Just take it step by step. Make the "most normal" things doable and slowly expand. Even if that means some code needs to be rewritten later, it is by far the easiest way of designing software that does something, rather than a half-finished software that would do everything if it were ever completed 
|
Not sure how I missed this thread. Just read through things and I'd like to post my thoughts.
The design you have for roles isn't flexible enough. If we want to allow for themed games, we need to allow for a wide range of possible roles. I'd like to suggest a different paradigm for handing actions:
An "action" is a function that takes a list of players and returns a new list of players.
So what is a player? A player could be a "class" (or potentially a dictionary depending on the langauge we're doing this in-- I'd highly recommend using a scripting langauge for handling "layer 4") with the fields: health, target, DTreturn, actionPriority, information (which is a list), alignment, willAct (possibly)
So when multiple actions are performed at once, we create a list of players sorted by actionPriority. Then we iterate through each player in the list and call action() or whatever it's called. Here are examples for what action would do for certain roles (italics means it's getting a variable):
Medic: Get target that person in the player database, add 1 HP to the person, return the player list with that person's health increased
Framer: take target's DTreturn variable and change it. Return the new list of players
Detective: look at target's DTreturn variable. then take its own name, and append the results of the check into self's information.
Bus Driver: look through everyone's targets, and switch relevant ones.
Roleblocker: this is where things get tricky. There are two ways I can think of at the moment to solve this:
- Give everyone a willAct variable that is checked in the action() function. If it's set to false, return the list of players unchanged
- Allow action() to access the action list (discussed above) and let it remove entries.
Mafia Kills: this is the only one I'm not sure how to handle. We could have the kills come from a certain member of the red alignment, or we could have an "invisible" player in the action list that has no "alignment" per se but carries out the kills.
---------------------
Another thing we should do is focus on how the layers will work. Getting a bot enabled serverside is very unlikely but it's not necessary-- everything can be done clientside through scraping. I wouldn't mind getting to work on this part but we need to plan things out:
- How will the layers communicate information to each other? Do we use XMLRPC sockets? Files?
- What language will layer 4 be written in? Most of you guys are talking about compiled langauges (C++, C#, etc.) but IMO the ideal would be a scripting language like Python or Lua. That's because it allows us to be very flexible when defining certain behaviors and doesn't require a recompile to change.
- How will hosts create games? This has been discussed a bit. A GUI might be a good idea but I think the best way would be to let the host talk to a developer. I'm assuming this will be open-source so we shouldn't have to worry about a single developer disappearing.
---
There's probably more stuff I'd like to add but can't think of, and I have to go now... I think this is a great idea and I'd like to help in any way I can.
-Nisani
|
Anybody using lua for anything other than what it was originally intended for (it's terrible for writing software from the ground up) is batshit insane. It is also about as bad or worse than perl in terms of maintenance of the code.
Python is good. PHP if you plan on making it web-based.
|
I like the suggestion for the players and actions. However, it still won't capture everthing possible in themed games. Anything with items will be hard. Inventors even worse.
|
you guys should sign up and post in gonzaws mafia bot forum section we have at omgus. Hes the only one posting there and hes posting walls and walls of conversations with himself about this shit. Its starting to creep out some of the omgus regulars.
http://www.omgus.net/forum/viewforum.php?f=51
|
On November 28 2012 03:40 Acrofales wrote:
I like the suggestion for the players and actions. However, it still won't capture everthing possible in themed games. Anything with items will be hard. Inventors even worse.
Items are definitely possible. They can have a "priority" and be just like normal actions. Each player could have a list of items that represents their inventory.
An inventor would require the use of a scripting language and a developer on duty to code up the items. If it becomes too complicated we could always have a human host handle it.
|
On November 28 2012 04:01 Coagulation wrote:you guys should sign up and post in gonzaws mafia bot forum section we have at omgus. Hes the only one posting there and hes posting walls and walls of conversations with himself about this shit. Its starting to creep out some of the omgus regulars. http://www.omgus.net/forum/viewforum.php?f=51
lol
|
Nisani, that thing doesn't seem to take certain things into account, or it'd be very complicated to maintain if you do.
For instance:
Once the cycle is over, how to you "undo" those actions? Remember a RBer RBs someone for 1 night, a medic gives "1 extra HP" for 1 night, and a framer sets "DTReturn" only for one night as well.
When every "action" is done, and you iterate the list of players, how do you know a "DTReturn" is part of that role or was modified by a framer?
Do you keep a log file and undo that action? What about actions like "You can frame someone for 2 nights straight" for instance? How does that work out?
In my paradigm it's easy, add a "Time to live = 2 cycles" attribute to the created passive ability, and once 2 cycles pass, a controller "deletes" all abilities with TTL=0.
Also DT and cop checks are easy. It either checks the players alignment or the players role (attribute "name" from the role), it doesn't need a "DTReturn" attribute, since it changes depending on whether it's an alignment or role cop, and the info is already there, and there's no need to make it redundant.
I think the system is too complex to handle it that way.
On November 28 2012 03:24 Acrofales wrote:Show nested quote +On November 28 2012 02:59 marvellosity wrote:On November 27 2012 10:50 Keirathi wrote:I think the most common way is for the scum to specify the person to carry out the NK, then in absense of them specifying, it is randomed. Like you said, one person has to carry out the kill or things like town Roleblocker are pretty useless. Then, it doesn't matter what role carries out the kills. Some hosts don't allow scum with an active ability to carry out the kill and use their action in the same night, though, and some do. It's just host preference stuff again For the RB thing: If you're handling all roleblocks simultaneously, then no, the kill would not go through. That's why I chose to give scum roleblocks priority in Mario. yeah it depends on the game. definitely it's usually carried out by a player. but for example in GMarsh's games I think the KP is factional, as the roles present are doctor and no jailkeeper/town rber. I know Ace's DFM2 had factional KP (of course, that could not be called normal by any stretch of the meaning). Also, I seem to remember a game in which roleblockers blocked only 1 ability, so a scum framer tasked with framing and shooting, but being roleblocked, would only get his frame roleblocked, while the kill would still happen. No clue whether that was in a normal or themed game, though. Even normal games have a large variety of this kind of specifics, as we discussed on Skype. I think you can believe Marv when he says that most hosts would rather host the game by hand then have such specifics set in stone. Just take it step by step. Make the "most normal" things doable and slowly expand. Even if that means some code needs to be rewritten later, it is by far the easiest way of designing software that does something, rather than a half-finished software that would do everything if it were ever completed
I want the "core mechanics" set.
Of course I won't let a host add a "Framer who can bus drive the roleblocker who medic protects a guy who shoots him if he DT checks him" role, because that'd need more stuff to take into consideration, but I want the core stuff to be there.
Like the "Passive/Active ability" stuff, or the "Status" one, or the "Result" one, etc.
Yeah don't know much about Python/Lua, but seems to me that those languages aren't that good for maintainability, or reusing code, or making the code easy to understand, add new features every once and then, etc.
Why would you think those languages would be better? (I'm curious).
|
About the Layers:
I dunno, I thought a simple "Import jar" configuration would be done and the layers would perfectly call methods from each other wouldn't they? (if we use java).
Each "layer" (or rather module like Acro corrected me ) is inside the same host as far as I know, since there's no need to make it distributed...so I don't see why there's a problem in them communicating.
(EDIT: Of course if we try to make an "elegant" deployment we might face some problems...maybe)
Don't know what a XMLRP socket is lol.
How will hosts create games? This has been discussed a bit. A GUI might be a good idea but I think the best way would be to let the host talk to a developer. I'm assuming this will be open-source so we shouldn't have to worry about a single developer disappearing.
Ideally yes. A host would open a GUI somehow and put everything in.
Even more ideally the forum itself would have the GUI embedded in it so the host doesn't need to use an external source.
However in this first iteration I think having the host PM the bot with the info about the game would be easier/faster/less prone to errors.
Because of that the creation of a game must be as simple as possible in this 1st iteration.
I still don't know about how the bot would work though (I already said I know 0% stuff about bots). It can only be clientside? Who "hosts" it?
|
I envision the bot working like this: the bot obtains the URL for the game thread, and parses the HTML of the thread every 5 minutes or so to update votecounts/whatever it needs to monitor. If it needs to make a post or edit a post, it does that by clicking its way to whatever form it needs to get to.
It could run on any dedicated/always-on box. I have access to one that could be used with pretty good reliability.
HTML parsing isn't the *best* option and getting the bot installed serverside would be ideal for a number of reasons. Unfortunately I doubt the TL admins will let us do that. It could probably be done on OMGUS though.
--
"Undoing" actions or fields isn't necessary. Fields could be set in two categories: temporary and permanent. Temporary fields would reset to a default value.
A scripting language would be incredibly useful for something like this because:
- Dynamic typing lets us implement custom fields that can have different types
- No need for recompiling which will likely happen a lot for this project as things will constantly be added
- Hard-coding in certain behaviors or values that could potentially change is always a bad idea. When programs don't have much need for this, a compiled language is ideal. The mafia bot is the exact opposite because there are tons of potential behaviors that could be defined that we don't know during development. It's sort of hard to explain but if you do end up trying to do everything in Java or C++ you'll see why it isn't a good idea.
---
XMLRPC is mainly for transmitting information across processes and across different langauges and I don't think it's built for this (I probably shouldn't have suggested that). I mean that, since layer 1 will need to have different implementations depending on its environment (TL.net, OMGUS, wherever else it could potentially be deployed). There needs to be a standardized format for it to send to the game-related modules so that the game modules don't have to worry about what forum it's running on.
If everything is in a single langauge in one single project then it wont require much planning. But if a lot of people are working at once and in potentially different languages (which isn't necessarily a bad thing) then there will need to be a defined mechanism for how the game modules will receive information from the forum modules.
|
On November 28 2012 10:03 Nisani201 wrote:
I envision the bot working like this: the bot obtains the URL for the game thread, and parses the HTML of the thread every 5 minutes or so to update votecounts/whatever it needs to monitor. If it needs to make a post or edit a post, it does that by clicking its way to whatever form it needs to get to.
Yeah that's what I envisioned it doing "clientside" as well.
I thought that "ideally" it could access the forum's database himself, but yeah I guess that can only be done in OMGUS for now.
Also I take it it'd make posts and the like just like any bot would do. If there is a TL "library" to do something like that then better (or we just copy the code from what other bots here do, like Zona's one).
It could run on any dedicated/always-on box. I have access to one that could be used with pretty good reliability.
Oh good, because I don't really have the means to set up/maintain an "always on" end system to handle it.
-
"Undoing" actions or fields isn't necessary. Fields could be set in two categories: temporary and permanent. Temporary fields would reset to a default value.
It still doesn't seem to "represent" reality. Again, do you set a "timer" for each temporary field? Like having 1 Framer frame someone for 1 night but another framer framing him for 2 nights for instance?
And even though I have it all "nice and tidy" with this OO design, there are still things that are pretty complex and hard to do (like dealing with the whole bus driver/RB/different night actions that depend on other night actions and stuff) that I think would be equally or even more complex in that design.
Plus it doesn't really add more functionality. Like if we wanted to add items, or add Day Powers (a Day Vigilante for instance, which is pretty common in PYP and that kind of "restricted" themed games), etc.
I'm not too convinced with it. Unless it can implement a OO paradigm as well, or has a better one that represents reality (a role/subject oriented one perhaps? Although I don't really know much about those).
A scripting language would be incredibly useful for something like this because:
Dynamic typing lets us implement custom fields that can have different types
No need for recompiling which will likely happen a lot for this project as things will constantly be added
Hard-coding in certain behaviors or values that could potentially change is always a bad idea. When programs don't have much need for this, a compiled language is ideal. The mafia bot is the exact opposite because there are tons of potential behaviors that could be defined that we don't know during development. It's sort of hard to explain but if you do end up trying to do everything in Java or C++ you'll see why it isn't a good idea.
But how do you use the scripting language to define these "potential behaviors" and deal with them as they come along?
And how do you use dynamic typing in this specific project?
I did think that some stuff being hardcoded wouldn't work that much. For instance in those crazy themed setups where hosts create wild setups, and theoretically should be able to create them on the fly without needing to compile the system again.
But that's not really just a problem with the language itself, which can "create new code" on the fly so it could technically handle that. For instance the Java Assist API let's you create new .class files to load, or dynamically compile new code.
The problem is with the design. How do you design the system so it takes care of that?
If the system design can't be done it doesn't matter if you use java or python I think
XMLRPC is mainly for transmitting information across processes and across different langauges and I don't think it's built for this (I probably shouldn't have suggested that). I mean that, since layer 1 will need to have different implementations depending on its environment (TL.net, OMGUS, wherever else it could potentially be deployed). There needs to be a standardized format for it to send to the game-related modules so that the game modules don't have to worry about what forum it's running on.
Hmm, yeah that's the only way I can see that as a problem.
I think there are some stuff that "bridge" these languages though. I just googled a bit and there are some protocols that bridge Java and php for instance.
At worst it can use web services over SOAP/REST in the same host.
EDIT: Even in an even worse case, we can just create sockets and send XML data over network.
|
Okay, I made a list of all possible roles that a host can choose from when creating a game.
+ Show Spoiler +Possible Roles to choose from: CopSanity: Sane, Insane, Paranoid, Naive Amount of power: 1-shot or infinite Check: Alignment check, Role check Medic:Veteran:Vanilla Townie:Vigilante:Mason:Type: C9++ Mason or "Can PM one dude on N1" Mason Tracker:Watcher:Town Roleblocker:Jailkeeper:Miller:Type: Self-Aware or not-self-aware Mafia Goon:Mafia Godfather:Checks: Alignment check, or choose role to appear to (default is Vanilla Townie) Mafia Framer:Mafia Roleblocker:Serial Killer:Type: C9++ one (choose immunity on D1, etc), or a "normal" one So yeah, every role will already be "set" and can't be customized. Only the Cop can, since he can either be alignment/role cop, has a sanity, and can be a 1-shot cop for C9++ setups. Maybe those could all be different roles, but it seems like too much, since all are "Cops".
Did I miss any? I think normal C9++ setups can be played with these.
Also no "role creation" for now so we don't overcomplicate things.
Also, when creating a game the host will choose ONLY this:
- Name of the game
- Type of game (Normal or Newbie)
- Plurality or Mayority lynch
- Roles
And that's it.
For each role, the host can give it a name (if not the default one for the role is used), amount of that role in the game, the type and options (like above).
That should be simple enough to even send a PM to a bot I think and create a fully functional game. The host of the game is taken from the guy that sent the PM so that's redundant info.
Everything else will be set to a default and can't be changed for simplicity's sake.
I.e all deadlines are 48 hour day cycle and 24 hour night ones, everybody is notified of being RBed, Scum RB takes precedence over town RBer/jailer, and all that stuff we've been talking about.
Again to make it simple. Later we can deal with the other shit I guess.
Would this be alright? At least with you guys that didn't want me to complicate things
EDIT: Host can choose if players can vote for NL or not
|
Looks ok, a few questions:
Is there an input for number of players?
Do you have notifications for healing?
Do you have an input for the deadline or is it just from when the game starts?
Can people vote for themselves?
And is this ready to go?
|
On November 28 2012 11:14 gonzaw wrote:
EDIT: Even in an even worse case, we can just create sockets and send XML data over network.
That's essentially what XMLRPC is.
Foolishness made a thread about a what constitutes a "normal game" a few months back, if you're want to know what roles to include. Linky.
A while back, Zona had a bot called ZBot that would count votes and (IIRC) do night actions. I tried contacting him a while back when I had a similar idea to make a bot, but he never answered me. Not sure what happened to him but he might be able to help if someone could get a hold of him.
|
On November 28 2012 11:44 GreYMisT wrote:
Looks ok, a few questions:
Is there an input for number of players?
Done automatically when you put all roles and how many of each role there is.
If you do something like this for instance:
VT - 7
Cop - 1
Medic - 1
Goon - 1
RBer - 1
GF - 1
Then it's obvious that there are 12 players, 9 townies and 3 scum, no need to input it yourself.
If you input it yourself you can fuck up (i.e put a different number of players as roles you specified) and it's more cumbersome to be checking if those 2 are correct and shit.
Do you have notifications for healing?
Nah
Do you have an input for the deadline or is it just from when the game starts?
This is the process of creating/running the game:
1-Host PMs the above info to the bot, bot says if it's okay or has any problems
2-If it's okay, then host makes the game thread, gives URL to bot. Bot PMs confirmation back
3-Bot starts constantly checking the signup thread for "/in" s or "/join" s (the host must make sure the players type correctly >_> ).
4-Once all signups are filled, the bot PMs the signup list to the host
5-The host can confirm it, or replace players (just in case). Bot confirms back
6-Whenever he's ready, the host PMs the bot and the game starts. At this point the deadline starts running, and the host creates the Day 1 Post.
7-After this every deadline (in the system) is automatic.
Can people vote for themselves?
Yeah I don't see why they shouldn't? Only times I've seen it has any significance is with voting mechanics from themed games.
Oh yeah I guess I forgot the "can people vote for a No lynch?" option. Meh I'll add it.
And is this ready to go?
Wut
No, it's ready to start, which is already a huge improvement with what we had like 2 weeks ago
I have tests/exams these few months so can't do everything.
I also need a little help designing some little stuff (like the tier of action resolution "Roleblock->Protection->Kill" stuff). After that we need to do the formal shit and create a developing team and all that shit.
Also figuring out how the fuck to use a bot lol (I still don't know).
On November 28 2012 11:47 Nisani201 wrote:Show nested quote +On November 28 2012 11:14 gonzaw wrote:
EDIT: Even in an even worse case, we can just create sockets and send XML data over network. That's essentially what XMLRPC is. Foolishness made a thread about a what constitutes a "normal game" a few months back, if you're want to know what roles to include. Linky.
Great I forgot about that thread lol.
....ehmm yeah, some stuff in there I kind of forgot about but I think I'll add it in a later date.
Like Mad Hatters, scum choosing their own roles, scum medic/mason, nosy neighbor (which is easy to do actually).
Oh yeah, I forgot about:
-Mayors & Bodyguard election (and maybe Pardoner election)
-Pardoner role
-Parity Cop
-Alignment+Check cop
-Traitor
I knew I was forgetting about something lol! Of course I forgot half the roles in the game
Right now I think we can play easy simple "Cop+Medic vs Scum cs SK" games so it'd be fine.
I'll see if we can add these "uncommon normal" roles later
A while back, Zona had a bot called ZBot that would count votes and (IIRC) do night actions. I tried contacting him a while back when I had a similar idea to make a bot, but he never answered me. Not sure what happened to him but he might be able to help if someone could get a hold of him.
Yeah I PMed him when I started this and no response.
Do you know someone else who did something similar? Or at least someone who knows how to program TL bots?
|
If you just want to make a first iteration to get a base system down, why not just limit it to c9++ roles and have the bot roll everyone's roles/etc?
|
Also I'm an idiot I forgot to include Veteran
|
On November 28 2012 12:20 Keirathi wrote:
If you just want to make a first iteration to get a base system down, why not just limit it to c9++ roles and have the bot roll everyone's roles/etc?
C9+ roles kind of vary, and hosts will start with the "I want to customize my c9++ setup!" thing and things may get complicated.
I think a simple C9++ game can be played with what we have now, so make it simple like this (host chooses the roles himself).
EDIT: Ehmm, I think the "people can vote for a NL" thing may get complicated.
If it gets needlessly complicated I might even scratch it.
It's not like players always end up voting for NL anyways
|
I can start working on a TL scraper in python if you want. I don't really like using python for something like this (I'd think it would be much more effective for the game module) but all the good scraping libraries are for python so I'll do that.
I will report back when I have something substantial.
|
I'd prefer help planning the mayor system to be honest (help designing it mostly, specially object-oriented), but anything helps.
What's a "TL scraper" though?
If you can PM me or post in OMGUS what it does and why you use python and all that jazz then the better I think (since it's details and stuff)
|
|
|
|
|
|
EPT
