User:PowerfulBacon/Guide to head developer
| HEAD STAFF | |
  Head Developer |
Access: Everything Difficulty: Extremely Hard Supervisors: Project Lead/Host Duties: Manage design direction, recruit maintainers, make sure the GitHub is running smoothly. Guides: Non-Admin Staff Conduct Quote: Who the coded this like this. |
Guide to being the Head-Developer, this is kind of where I try to right down things I learnt from experience in a guide, however I have to say almost everything learnt is through experience and is hard to convey in a document written in a few hours.
If you don't read any of this, then remember this: Do not create a negative environment for coders, avoid grudges at all cost even if someone writes code that causes lots of bugs. Give them pointers for how to improve, if something doesn't fit into the game then say in the PR that it doesn't fit in the game and don't just leave it for 4 months with no review until the coder gives up and goes somewhere else..
For some reason in Space Station 13, the Head-Developer usually is the person in charge of design and that will typically be more important than development for you, so you must be ready to take on the heavy workload and mental torment that comes with understanding the design of Space Station 13. Once you reach the point where you realise that nothing in the game works at a design level, and that all of the jobs encourage isolationism; then you are at the point where you are starting to truly understand SS13 design.
The true role of the head-developer is to make themselves entirely expendible. If you were to leave at any moment, then if you are doing a good job that should have very little impact on the codebase.
Design
You are in charge of setting out the design precidents that will lead the server in the right direction. You aren't setting the direction that the server should go in, and shouldn't be trying to change that; the direction of the server overall is something that needs to be agreed on by all the project heads.
Design Principles
Here are a few things that you should try to keep in mind when designing for SS13:
- Every single change has positives and negatives. Even trivial changes that seem universally good can have long term consequences and slow mentality shifts over time which lead to undesirable states. For example, completely solving powergaming would also completely kill any form of improvisation for antagonists; completely removing all forms of cheap ways to kill people may make it more challenging for new players to play as an antagonist.
- The Head-Admins and Head-Developers are solving the same problem. They should both be talking about what the other party is doing and the Head-Developer should give input into, and understand, the rules.
- Good rules go hand-in-hand with the mechanics of the game. Bad rules go against what the mechanics encourage you to do. If there is a rule, or a proposed rule, that goes against how the players are being encouraged to play then something probably needs changing to emphasise the rule in the game. I like to think of this as the rules being 'diagetic', part of the game-world as players shouldn't be caught off-guard when they do something wrong; the rules exist to remove the bad-actors from the game, if there is something that people are regularly doing despite not being bad actors then perhaps something needs to change.
- Try to play like a normal player would and try to keep the mentality of a normal player. Don't design everything around the requirement that everyone using a system must be a perfect player who always roleplays no-matter what.
- The server wants to be a roleplay server. This doesn't mean roleplay is the only thing that you should care about, gameplay and fun are also very important and without variation and some amount of chaos in what happens in the round, there are no events that are actually worth roleplaying.
- Changes in the game will have slow psychological effects on the playerbase, which may not have an immediate impact but may cause a shift in player mentality over time.
- Everyone who actively participates in the forums/discord will be an experienced player, remember to consider the experience of the newer player as well when it comes to balancing/changing things.
- If you are making a poll, text answers are by far the most useful fo getting any meaningful data out. If you are trying to analyse a testmerge, most of the time its better to just observe players and see how they are playing rather than to use a poll however.
- On that note, make sure you observe and watch people frequently! When you play, you may feel that something is unfair but are heavily biased and will not consider how the other player was feeling. You ```must``` observe players regularly and watch them die to things that seem unfair, when you see this happening, then you know that changes might need to be made in that area. It is specifically useful when you are watching inexperienced antagonists who get their round ruined by a player who was unprepared simply because that player had experienced with some obscure or novel mechanic.
- Learn how to communicate that your change is good. If you think/know a change will be good for the game, explain why it will be good for the game so that someone who has absolutely no understanding about that feature will also think it is good. Some people will be biased against certain changes and always hate on them, but still make sure to look out for genuine feedback.
- Players may not be good designers, however they know when there is something that they don't like in the game. If people do not like a certain feature, it isn't because they don't understand it, it is because it is poorly designed. Solutions may be suggested that may have obvious flaws, however the simple act of someone suggesting a solution to something indicates that there is a problem with the underlying mechanic that they are referencing. Don't ignore people if they have valid concerns about a particular system.
GitHub
- There isn't really much to say here tbh.
- Don't upset Crossed or the other heads, don't do anything that would impact them as a host/headmin without their knowledge.
Coding
As the Head-Developer, you may find yourself coding significantly less than prior to being the Head-Developer. This is natural since you have other responsibilities that are far more important, and naturally should be trying to organise other developers in the right direction rather than doing everything yourself.
Tips
- Don't worry if another maintainer is coding more than you. It is not a competition and your job isn't to be the most active coder on GitHub. Coding is the least important part of the role.
- Don't ignore #github. Look at every single merged change when you wake up in the morning and constantly keep an idea about the state of the game.
- Many changes have extremely indirect consequences that are almost impossible to see, even with experience. Make sure to keep tabs on what is and what isn't improving the game.
Unsorted.dm
Things from experience
- The bi-weekly developer meetings are pretty cool, although they should have been 50/50 talking about what we want from the design, and contrbutors having a chance to give input into the design.
Things that I think Beestation should aim towards in the future
- Easier and more consistent ways to get back into the round. This will lessen the annoyance of being dead and will allow us to have a more relaxed community view on traitors who kill players.
- In-character goals (Antagonists acting antagonistically out of their nature) instead of Out-of-character goals (Strict objectives that must be completed no matter what, limiting roleplay variance)
- More control over what antagonists are allowed to do in-character, progressive traitors/a reputation system is a good step, although try to avoid the very gamey approach that progressive traitors encourage (If completing objectives is the way to make money, players will optimise completing objectives as much as possible and have a gamey approach. Try to make it so that the focus of antagonists is something relating to their character).
Other things that I think
- Everyone talks about economy (insert any major system) changes that magically fix the game, however you need to think: How will this actually impact the game. If the economy isn't tied into literally every part of the game, then making a good economy is literally useless. Remember why you are making a change and keep that in mind when you are designing something: You want to make changes that have an impact on how people player the game, not changes that are just a good isolated system.
