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..
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
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.
