im coding this in c (which i am Most experienced with) so first i set up a struct that basically just defined the attributes a specific ability needs
weâre allowed but like
youâd have to organize it
I was meaning âpossible to start an automated one with Zugbot wheneverâ
2 Likes
(this tends to fail badly)
1 Like
I wanted to tell the teacher some bad words, but ya know the whole academic standing thing is important
Im supposed to be kind to everyone :)
2 Likes
the ability struct does NOT, however, have an attribute for actual effects. that is what the ability variable is for in the first place, you check the specific ability youâre using and then do something based on that
BUT it does have fields for things like base usages, name description id, type (day/night/passive) and priority
1 Like
then my real stroke of genius was setting up a struct for a role variable
basically, you have basic things like name id description as well, and also a default alignment setting
but the kicker is that the main thing a role does is actually just contain an array of basic abilities. your role is basically just subdivided into a lot of abilities that sum up to make the role.
to further abstract things, certain abilities would be converted into other, more basic abilities while processing
for example, if i jailkept player A, the program would take my input and treat it as if i was inputting âdoctor a, roleblock aâ
similarly, attributes like âroleblock immunityâ are not applied to the role, and are instead applied to abilities. this means that you could, using the example above, make it so that if the jailkeeper does that on A, but B roleblocks the jailkeeper, the doctor ability is roleblocked but the roleblock part isnât
this works pretty well to simplify a lot of shit and make it more flexible.
ive heard that the issue with making games like town of salem is that the role processing is terrible since you ~basically need to change fucking everything whenever you make a single change, since everything needs to be individually defined and given a priority andâŚ
so abstracting things like this helps a lot
4 Likes
Im so shocked. This is Willow?!?!?!? Ive never seen you talk about programming before
this is more like designing virtuous to me tbh
2 Likes
programming is the real evil that corrupts people you think your friend is a calm chill person until boom, they start talking about github, c++ and thigh high socks
4 Likes
nyaaaaaaaaaa I find this pretty interesting tbh
Iâve had a very different approach when designing Zugbot, though Iâm going to be additionally adding something sorta similar to what youâre discussing here to help with writing more complex games
3 Likes
I would never bother with this and try to account for mech kills but otherwise have it be literally random among non-PRs (assume PRs will claim and are believed)
2 Likes
generally Most Actions you can take in an FM game (that have an actual effect, fruit vendors n neighborizers n shit donât count) can be put into 1 of 4 categories
manipulative (or what tol calls offensive)
protective
killing
investigative
(you can also use that order for night action orders like botc does)
so, instead of making a longass line of things while processing to check Every Possibility, you can instead simplify it to a layer of basic abilities, and then you can check less things for those basic abilities
this doesnât really work with investigatives that well
but i have figured out that you can use a âtracker-ish formulaâ to check visit based abilities
tl;dr is at certain points during the night, the game would update a list of âcurrent visitsâ for every player (and keep a record of the original ones too, but i donât think it would be necessary to track in-between points).
for example, after roleblocks have been resolved, it updates. same with redirects (though redirects probably wonât be present for a very long time)
then, when you need to do things like âtrack a playerâ the game can reference the current visits list and check (with a tracker) who a person has on their current visits list, then tell that to the tracker
this is especially useful when you are trying things like Watchers. instead of checking who a specific person has on their list, the watcher would iterate through every player and check if they visited the watcherâs target. if they do, they are added to the seen list; if they arenât, they arenât added.
then, the watcher gets told whoâs on the seen list.
you can also extrapolate that to things like rolestoppers; instead of learning whoâs on the seen list, the rolestopper roleblocks everyone on the seen list
1 Like
yeye this is probably needlessly complicated for vanilla-ish games
1 Like
The hard part is recognizing mech greens and reds.
2 Likes
Zugbot is intended to be able to support more complicated games eventually, which is why I need to put another system on top of what I currently have
1 Like
the entire goal of a program like this would be scalability. makes it easier to add new roles and abilities and balance existing ones n shit. (atm it would function by spitting out feedback but thatâs just because i literally donât know how anything UI works and would have to delegate that to someone who does)
but if youâre doing mostly vanilla-ish roles, you donât particularly care. it only becomes useful when you start doing tos-like games with more complicated abilities and more roles
1 Like
fair
1 Like
Coders when seeing virtuous Minstrel
1 Like
yea virtuous has a lot of. shockingly unqiue effects tbh
Ok, new plan: create a bot to solve all those BotC riddles that benguined keeps throwing into the QBCord BotC server.
2 Likes