Developer Onboarding Guide
From LSWiki
| Revision as of 11:13, 6 December 2017 (edit) Marcosy (Talk | contribs) ← Previous diff |
Current revision (11:13, 6 December 2017) (edit) Marcosy (Talk | contribs) |
Current revision
------------------------------------------------------------------------------
Developer Process Guide an attempt at a developer onboarding process
Marcosy 2017-08-02
------------------------------------------------------------------------------
Contents |
Introduction
If you are reading this document, you are either a new Lost Souls developer, or someone interested in the tasks and responsibilities of such a person. In the interest of brevity, this guide will assume the reader is a new developer, to avoid awkward or repetitive phrasing.
Welcome to the development staff of Lost Souls. As a new developer, you will generally have only a very limited set of abilities and permissions, but even the most basic tools can cause great damage if not used carefully. It is your responsibility to utilize your tools and commands safely, to create and maintain backups of important files before modifying them, and to work with other developers to produce and maintain content. It is especially important that you use the 'eval' command (and related tools such as tracers) with great care and discretion -- avoid attempting to modify objects or data that you would not normally have access to modify. Disregard for this rule will have swift and unpleasant consequences, up to and including deletion of your atman.
A number of additional resources exist to help you ease into development on Lost Souls. It is recommended that you read the Developer Primer, as well as the articles in Category:Development. There are a very large number of man files and help files that can provide additional information, most of which are unorganized or not centrally managed, but digging around in /txt/doc/ and its subdirectories are a good place to start. Developers should also pay very special attention to the contents of man developer and help mud politics, and generally do their best not to act like complete fucking assholes.
Once you have read as much of the above material as you feel you can usefully absorb, you should begin working on your first tasks, defined below.
Why do I have to do all this stuff?
The requirement to complete a fixed set of tasks before being allowed to work on content of your choice often seems arbitrary or overly restrictive to new developers. A common question that is asked follows the pattern of "I just want to code guild powers, why am I being asked to create rooms/items/NPCs?".
The truth is that a robust mastery of room, character, and item objects and their constituent properties is critical to being able to write any code which affects these objects. If you want to code a guild power that sets someone on fire, you will need to be capable of understanding how character objects combust and how that may affect flammable items on their person or nearby in the current environment.
First Tasks: Workroom and Custom Item
Your first task will be to configure and personalize your workroom, a location unique to you where you will spend most of your time. A template, copied from /obj/examples/workroom.c, will be placed in your /w/ directory for you to use as a starting point. Your workroom doesn't have to be perfect or fancy, but a good faith effort at doing your best to create a unique and interesting workroom will show your commitment and seriousness at this endeavour. Make sure that your workroom is pleasing to you and organized in a manner you find easy to navigate, as you will be modifying it often; the primary purpose of a workroom is to test different types of room-oriented code.
Once you have configured your workroom to your satisfaction, your next task will be the creation of a new item. It is recommended that you use an item you can hold or wear, such as a sword or an amulet, as a template. Make a copy of an item in the /obj directory and place it in your /w/ directory, then modify the item to alter its appearance, materials, and other attributes until you have something unique and pleasing to you. Then add special abilities and powers (drawing from examples in the /obj/magic directory and other items you may be familiar with) as desired to learn about the various functions items may possess. Most developers keep their first item around and use it as a personal tool for testing item-based functions. In some circumstances, a new item may be suitable for a new artifact that can be published to the live world; design your first item with your desired purpose in mind.
Content Design: Setpieces and Your First Area
After completing your first room and item, you should begin work on your first setpiece. This is usually an item/room/autonomon trifecta where an autonomon resides in a room (usually a new room to be added to an existing project) and is equipped with items that you create. This exercise serves as a test of your ability to come up with a cohesive design and implement it over a series of steps, as well as a chance to begin learning about NPC code and exits and working with external resources (such as the header files of projects you do not control). Your setpiece does not have to be restricted to a single room, item, or autonomon, and it is in fact encouraged that you should attempt to build a small area composed of multiple connected rooms. A typical first concept for a setpiece consists of a shop or service provider, such as an NPC which casts healing spells in return for gold. It is generally considered wise to ensure that your setpiece meets the balance goals set forth in man balancing before asking for review.
Finally, you should begin work on your first area. This will be your first experience interacting with the project setup process ('perform project setup') and the various daemons and daemon extensions which control an area project, such as the map daemon and the populace daemon. This process is complex and involved, and you would be well advised to review the following topics: Map_Extension, Terrains, and Area_Mapping, as well as examining existing areas for examples and inspiration. Creating an area is the final test of one's dedication as a new developer, so you should approach the project with a realistic understanding of its importance and difficulty level. Expect to have your area undergo multiple QC passes and probably require at least one complete reworking -- new areas have a very high quality standard and require an understanding of many disparate systems in order to have them function properly. It is also a very good idea to vet your area proposals with senior staff before starting, to avoid creating a meticulously crafted area which will never be published for thematic or contextual reasons.
Completion of a successfully published area will result in the granting of the read_sensitive privilege, designating you a Veteran developer.
Affiliations and Beyond
After successfully completing and publishing an area, you may work on any of the other aspects of Lost Souls, including code residing in Affiliations (such as Associations, Guilds, and Faculties) and supplemental systems such as extensions, daemons, planes, languages, and beyond. Developers who show consistent efforts at quality, stability, and responsibility may be granted write privileges to various areas of the system, allowing them to maintain live production components; be advised that this is *not* a license to bypass QC. Write privileges are to be used to update and maintain content, fix bugs, and keep existing code compliant with evolving standards; extension or expansion of a project's domain should be considered with care and probably signed off on by a senior or elder developer, even if you have the privileges to publish it yourself. Use your best judgment and discretion at all times.
