The Wizard

[keronshb]

The fabled wizard document.

This still won't unfreeze Wizards, Spells, or Actions but it's to give people a more solid idea of the plans for Wizard and goes over some of the finer details.

Relevant urls -
space-wizards/space-station-14#40983
https://forum.spacestation14.com/t/remove-wizard-roundstart-antag/24764

[ArtisticRoomba]

Thanks a bunch for sitting down and writing the document despite the recent weeks. Since nobody has reviewed this yet I decided to sit down and take a look.

After reading the design document, I have some point concerns and general concerns. The biggest one of them being that this reads very much like a post-mortem implementation document that simply describes what is currently implemented and lightly clarifies some points about the Wizard. A lot of the information reads as if it was a bit scattered around and it isn't concurrent. In a sense, it reads like a FAQ rather than a design document whose intent is to lead future development and design direction, which is most important.

At the end of the day, contributors and players want to see a vision. A design cannot be implemented or understood by future contributors and/or maintainers if a design is not laid out, after all. I can't read your thoughts (though I wish I could read Vera's.)

[ArtisticRoomba]

For future ref, if you're going to line break for readability, be sure to do so between sentences.

Suggested change

	This is for The Wizard antagonist - which is to help answer any frequently asked questions for the Wizard and to help
	others understand what the Wizard is about. The Wizard in short is a highly disruptive/chaotic antagonist that does
	anything to their whim. A lot about the Wizard is that it doesn't conform to standard rules so it very much is the
	embodiment of "a wizard did it." Players will be encouraged to come up with their own gimmick, while still being an
	antagonist to the station.
	This is for The Wizard antagonist - which is to help answer any frequently asked questions for the Wizard and to help others understand what the Wizard is about.
	The Wizard in short is a highly disruptive/chaotic antagonist that does anything to their whim.
	A lot about the Wizard is that it doesn't conform to standard rules so it very much is the
	embodiment of "a wizard did it."
	Players will be encouraged to come up with their own gimmick, while still being an antagonist to the station.

[keronshb]

It was more for in-code readability but this makes sense too, good deal!

[ArtisticRoomba]

The document should be explaining the Wizard in the perspective of a person that has never seen or experienced the Wizard before. Relying on the reader's experiences is bad, as these experiences vary across players and can change over time, so it becomes necessary to document the reasoning at the time of writing that went into the Wizard and its design.

All-in-all, this background section is very short and very brief compared to a document like the Pursuer which outlines:

• What the antagonist is.
• Where it's derived from (whether it be a certain game or SS13 server).
• Why the antagonist exists.

Right now this section doesn't really state much of anything.

[ArtisticRoomba]

Something I also forgot to mention about this document that is really important:

The Wizard is an antagonist that has existed on SS13 for a very long time, yet this design document makes no reference to it at all, which is a pretty big misstep IMO. Ideally this design document references the SS13 Wizard and its implementation(s), what features it had, what problems it faced during its lifetime, and how the SS14 wizard plans to overcome the previous problems.

[ArtisticRoomba]

This section is very brief and simply lists a technical TODO of desirable features, and not how these features are used as the Wizard actions throughout the round. This document should treat the Wizard as if it was not implemented and avoid pretending like the user knows about the Wizard and its current mechanics - this knowledge can change and vary from person to person and must be written down so that it can be properly referenced and understood at the time of writing.

For example, it would be like if I had removed the section on atmospherics devices respecting basic fundamental laws of physics, because all of our devices respect this as of right now, so there's no need to reference it exactly. This can lead to situations where we may have to explain to someone that it's generally not a good idea to violate the laws of physics (without good reason), which is a waste of contributor and maintainer time when it can be easily referenced.

You can contrast this section to the end of the Features to be added section of the Pursuer document, which states:

A key feature of the Pursuer’s balance is its speed. The initial speed of the Pursuer should be slow enough that the target will have little difficulty running away, putting the onus on the Pursuer to facilitate coming closer to the target. This can be done by destroying walls, smashing windows or relying on other station issues to slow the target down or force them into a dead end. These destructive acts, along with the overarching goal, should force other crewmembers into acting by attacking the Pursuer (the Pursuer may even encourage this by attacking crew directly, though note that being distant from the target will make the punches weaker). Once the Pursuer takes damage it will gradually become faster and faster, first reaching a speed at which it can pressure the target better, and as damage increases it will become oppressively fast. When near death the Pursuer should be able to easily catch up to the target, though at that point being injured much further will cause death.

In this paragraph, we list:

• One of the limiting balancing mechanics of the Pursuer
• Why we limit them like this, and what we want the player to do as a consequence of this limit
• How this mechanic changes over the course of the round
• How the player is supposed to respond to these changes over the course of the round
• What the rising action and climax look like for the Pursuer.

For the Wizard antagonist, the only thing that is listed are just technical features and what spells may look like. It does not describe the effects they are supposed to have on the player. Note that any effect written down here can be valid - if the response is to obliterate the player, go ahead, put that down. But simply writing down what needs to be done is suboptimal - we should be asking why.

[ArtisticRoomba]

The pillars that the antagonist violates should be enumerated. This is something that should be explained and elaborated on instead of briefly mentioned in passing.

[ArtisticRoomba]

It should be elaborated as to why these are being done, in some form.

[ArtisticRoomba]

It should probably be clarified that no game-winning purely meta combo should emerge that players pick every single round in order to guarantee a "win" (even though the Wizard has no defined win condition).

[keronshb]

I feel I already state that with this blurb.

[ArtisticRoomba]

Friendly wizards is defined but we do not define why this is good or bad. If it's good, what are we doing to promote it? If it's bad, what are we doing (or what are we GOING TO DO, rather) to prevent it, mechanically? If we want a mix, what is the mix, and what are we doing to mix it up? Something I forgot to say initially: you define that friendly Wizards are bad in the later section, but it should be defined up here, and the why should be included.

[keronshb]

As I stated the doc there's not much we can do reasonably mechanically to prevent someone from playing as a friendly wizard. There are certain things you can add to encourage more antagonistic behavior and doing things such as buying optional challenge runs, etc, but it's an impossible ask to mechanically limit a players behavior.

Using a Traitor for example, if someone 100% helped out the station every time they rolled one ... how do you mechanically enforce that outside of rolebanning that person?

[keronshb]

I also don't feel like I need to explain why a friendly 100% crew aligned wizard is bad because we have that sort of definition in the antagonist doc. It's not just something that applies to the Wizard, so I feel that explaining what is and isn't friendly wizard is good because a lot of people have a misconception on what a friendly wizard is.

[ArtisticRoomba]

In any sense, it is a goal of the antagonist pillars, so we should at least try to enforce it mechanically:

Antags should be discouraged from simply playing as crew, or being friendly/assisting the crew.

The game needs less admin workload, after all.

Using a Traitor for example, if someone 100% helped out the station every time they rolled one ... how do you mechanically enforce that outside of rolebanning that person?

Traitor is of course a different circumstance, however there are ways to mechanically motivate Traitors to do their objectives (and they honestly need some motivation right now). For example:

• Traitor objectives can be on a time limit to encourage traitors actively seeking out their objectives instead of playing incredibly passive for the entire shift or ignoring them.
• If all objectives fail due to the time limit expiring, the traitor is excommunicado - their store is locked and they are marked for death, with another traitor on station given a target to hunt them down and kill them.

This promotes players mechanically playing their antag rounds - if they fail to complete their objectives, they are hunted. It's also fairly fitting for a killer contractor corporation like the Syndicate.

[keronshb]

• Traitor objectives can be on a time limit to encourage traitors actively seeking out their objectives instead of playing incredibly passive for the entire shift or ignoring them.

• If all objectives fail due to the time limit expiring, the traitor is excommunicado - their store is locked and they are marked for death, with another traitor on station given a target to hunt them down and kill them.

This dives more back into the optional contractor buy that we're likely going to add. Not an exact 1:1 but also having it as the main mode isn't great either because now you start to introduce the inverse: Traitors rush their objs at the start of the round ASAP (or just one) to tick the box off and then either roll over too hard or stomp too fast.

Which is why I think implementing something similar for the wizard - optional contract buy to do rituals (which has overlap with cults and heretics but different ™️ ) can be encouraging, but the main mode should still be relatively freeform.

Like we could add objectives to the wizard like traitors, which would relatively be fluff in comparison, but I know we're also floating the idea to either hide or remove greentext as well from Traitors which would just end up being the same situation.

[ArtisticRoomba]

This does not consider or acknowledge any roundflow issues like beginning-of-round or end-of-round round stalling, which is a concern that was raised in feedback thread.

[keronshb]

Please explain what beginning of round or end of round stalling is in this context or summarize it.

Edit: If End of round stalling is a Wizard not calling the shuttle or crew not calling the shuttle, that's not something this document should be handling. If a mechanic isn't introduced for it already, an unrecallable shuttle should be automatically called if a majority % of crew are dead.

[ArtisticRoomba]

Please explain what beginning of round or end of round stalling is in this context or summarize it.

Beginning of round stalling is when the Wizard intentionally does not visit the station or tries to stay as far away as possible, leading to an effective greenshift for the crew. This can be anything from staying in their Den or hiding in space. It should be noted that, due to Dynamic not existing, it is ideal that chaos ramps over time, or at least arrives to the station at a reasonable time. Nukies have this very same problem where they can just stall in space and arrive whenever they please, so they just arrive at the one hour mark where all of security cryo'd or everyone is bored. And then everyone malds.

End of round stalling is when the Wizard intentionally tries to delay the calling of the shuttle, whether it be making the caller inoperable or killing everyone on the station so nobody can call. In any sense, yes, this is something that should be handled, at least partially, by the design document - nuclear operatives have two natural end states, they either all die and the shuttle gets called, or the nuke blows up and the round ends.

Wizard doesn't have any EOR stalling prevention and it leads to piss poor experiences where ghosts have to vote to restart the round (if this is happening persistently, the game is not good).

[ArtisticRoomba]

This section does not elaborate on how the Wizard will scale its power to the current round population, which is a problem that was raised in the feedback thread.

[keronshb]

It's not going to scale power based on round population. While that was feedback from some players, that's not going to be implemented.

Some spells will be adjusted accordingly, but it won't be based on population.

For example, Rod is obviously busted based on some bugs and because it deletes. Once the backend on that changes, the Rod will be changed accordingly so it's exceedingly more fair.

Another is Fireball, which is meant to be high-ish power and dangerous to use at close range, which is just going to be balanced a little better.

[ArtisticRoomba]

In this case, it would be good to elaborate as to why it isn't going to be implemented, just so that those reading the document can know and understand why.

[ArtisticRoomba]

You should add a Current Problems subsection that details problems raised by admins in the feedback thread and how you plan to address them. A person looking outwards on this document does not know concretely what event spells are, why free agents are involved, and why it makes it a headache for the Admin team.

[keronshb]

All ready for another review.

[EthanQix]

I think teleporting the Wizard to the station if they try to fire an event spell while in space is a bit too strong and disorienting. Just not firing the spell with an explanation popup ("too far from station!") would be sufficient, and leave more agency to the player.

[keronshb]

I think teleporting the Wizard to the station if they try to fire an event spell while in space is a bit too strong and disorienting. Just not firing the spell with an explanation popup ("too far from station!") would be sufficient, and leave more agency to the player.

Event spells are being changed to use game rules so it will be doing it every time it fires. So they can't just go off into space after using it.