User:PowerfulBacon
| 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, a list of things that I have learnt and a list of things that I think I could have done better.
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, 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.
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.
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.
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)
