Difference between revisions of "Coding"

From Space Station 13 Wiki
Jump to navigation Jump to search
(Replace most of this article with a link)
 
(15 intermediate revisions by 6 users not shown)
Line 1: Line 1:
<span style="font-size:250%">
'''To Run, Host, Compile, And Develop on SS13 Go To  [https://hackmd.io/@goonstation/docs/%2F%40goonstation%2Fdev The Goonstation Development Guide]


==So you want to learn how to code for SS13?==
'''Be sure to follow it exactly!'''


Well you've come to the right place. This page is dedicated to helping you learn the ins and outs of writing SS13 code. I'll assume you have an above average knowledge of computers. If you ever need help with any of this, feel free to visit the #imcoder channel in the goonstation discord! There's a bunch of helpful people in there who would love to help you learn or help you with any errors you're getting <3
'''Discord is the place to talk to fellow players, admins, and devs in realtime. There's plenty of friendly people there, capable of answering most of your questions. Join at [https://discord.gg/zd8t6pY This Invite Link]'''
'''If you have problems with the above guide, visit ##imcoder'''
</span>


----
All of these links and more can be found at https://github.com/goonstation/goonstation


===Setting Up Your Local Goonstation Branch===
You can also take a look at DM by Example guide here: [https://spacestation13.github.io/DMByExample/]
<b>This guide is for terminal git! There might be more guides coming soon for other git interfaces, or you can ask for help in #imcoder regarding other git interfaces, setting them up, and using them!</b>


# You're going to need git, so download and install it from [https://git-scm.com/download/win here]
==Introduction to DM as a language==
# Once you've installed that, open command prompt (win+r, type 'cmd', enter)
DM is a high-level programming language, meaning, effectively, that its use does not require much understanding of computer hardware. Its purpose is the creation of games, and so tricky things like memory management are smoothed over for the coder's convenience. This is done by way of a process virtual machine: .DM source code is compiled not into machine language, but into a binary format designed specifically for BYOND. For a Dream Maker Binary (.DMB) to run it must be hosted by Dream Daemon, one of BYOND's four executables (Dream Seeker, the program used to play BYOND games, can also host them, but it is not recommended for Space Station 13).  
# In that terminal type <syntaxhighlight line='none' enclose='none'>cd %UserProfile%\Desktop</syntaxhighlight> to move to your desktop (then enter)
# Then in that terminal type <syntaxhighlight line='none' enclose='none'>git clone https://github.com/goonstation/goonstation-2016</syntaxhighlight> and press enter
# The code should begin to download, and you should see a new folder on your desktop called "goonstation-2016"
# Now you'll want to get the terminal open in that folder (either by right clicking inside of the folder and clicking the "open terminal here" option, or using the cd command in the terminal to navigate to that directory).
# Next, you'll probably want to make a new branch for your feature that you're coding (or your map/setpiece that you're making, or your clothes you're spriting). You'll want to make sure you're on the master branch. If you're not, type <syntaxhighlight line='none' enclose='none'>git checkout master</syntaxhighlight> to get there. I suggest using prefixes for the different type of stuff you're working on, like feature/, map/ or  sprite/, and using either dashes "-" or underscores "_" to seperate words, <i>but not both!</i> This'll make it easier to sort and switch branches without having as much guesswork.  
#To make your new branch, type <syntaxhighlight line='none' enclose='none'>git checkout -b feature/crime-time-usa</syntaxhighlight>. Git will do a bit of work, and then you'll be pumped into your new branch! 


===Terminal Git Workflow, Useful Commands, Tips===
BYOND, being patterned on C++, is an object-orient programming language. Abstract classes are defined in the code, which serve as templates for objects manipulated by functions. Suppose, for example, you are making a game with bears. You define all the variables and functions associated with them: What they're called, how they move, etc. This is the bear class. Whenever a bear comes into existence within the game, an object of this class is instantiated. Though its variables are derived from its class, changes made to them are made only to that specific bear; neither other bears nor the template itself are affected.  
<b>File Statuses</b>:
So, there's four possible file statuses (not all the official names):
*Added
*Modified
*Unmodified
*Untracked
Currently (if you haven't touched any files since you cloned goonstation, and haven't messed with compiling or hosting) every single file in the goonstation directory is <b>unmodified</b>. As soon as you modify a file in any way, that file will become <b>modified</b> and lose its unmodified status.  
If you type <syntaxhighlight line='none' enclose='none'>git status</syntaxhighlight> (git status will show you all added, modified and untracked files in the branch you're working in, and the name of the branch you're working in), you'll see that file in a modified files category with the file path in red text. Now, if you type <syntaxhighlight line='none' enclose='none'>git add your/file/path/yourfilename</syntaxhighlight>, your file will become <b>added</b>, and it'll be added to the list of files that will be committed.  
I'll talk about committing a bit later. If you (or byond, in the case of the weird hosting and compiling files) creates a new file in your goonstation directory, it'll be added as an <b>untracked</b> file. Both untracked and modified files will persist between branches and commits. This is useful for some things, like editing config/admins.txt to include yourself as a host for testing purposes and then never adding the file so you'll always have an admin rank anytime you test... but it can also be problematic so make sure you're not leaving anything untracked or modified that should either be committed or reverted.


<b>Branch Control:</b>
The concept of inheritance is central to object-oriented programming. One class can be derived from another, such that they share everything defined in the parent class. For instance, you might wish your game to feature a special type of bear. The path for a bear is <syntaxhighlight lang='cpp' line='none' enclose='none'>/mob/bear</syntaxhighlight> (bear is itself a child of mob, a built-in class which will be discussed later). Therefore, you make a subclass <syntaxhighlight lang='cpp' line='none' enclose='none'>/mob/bear/fuzzy_wuzzy</syntaxhighlight>. Any changes to /bear affect /bear/fuzzy_wuzzy, but not vice-versa. You can even define subtypes of inherited functions, a practice known as overloading. Suppose /bear has a function called sylvan_defecation, rendered in DM as <syntaxhighlight lang='cpp' line='none' enclose='none'>/mob/bear/proc/sylvan_defecation()</syntaxhighlight>. However, you want bears of the /fuzzy_wuzzy variety to behave differently when answering nature's call, and so you overload that function by defining <syntaxhighlight lang='cpp' line='none' enclose='none'>/mob/bear/fuzzy_wuzzy/sylvan_defecation()</syntaxhighlight> (note the absence of /proc/). Whenever a function calls sylvan_defecation() on a bear that belongs to the /fuzzy_wuzzy/ subclass, it will execute its special version of that function.
To list all of your branches, type <syntaxhighlight line='none' enclose='none'>git branch</syntaxhighlight>. If your list of branches is taller than your terminal window, use the arrow keys to navigate down the list. When you get to the bottom, press q to exit the weird no-typey mode so you can continue to do commands.  
If you want to switch to a different branch, type <syntaxhighlight line='none' enclose='none'>git checkout feature/new-stuff-v3</syntaxhighlight>.  
If you want to create a new branch, type <syntaxhighlight line='none' enclose='none'>git checkout -b feature/new-stuff-v4</syntaxhighlight>


<b>Committing And You:</b>
DM, as we discussed above, is executed by way of a process virtual machine. This means that, though it shares much of C++'s syntax and logic, it is ultimately a lot simpler. As such, it is not overly concerned with rigid type-management. A variable might represent a number one moment and a string the next. Such a transformation can still cause all manner of errors, if the coder does not account for it, but it won't necessarily cause the game to crash. In most cases Dream Daemon will simply shrug, inform you of your blunder, and carry on to the best of its abilities. This sort of extreme looseness is of dubious efficacy, but it means that you won't need to fret about the number of bytes allocated to a given value, whether a number can be negative, and other such distracting things.
You can save changes to files, but one of the advantages of using git is that it has REALLY good version control. Say you commit some changes on a patch that's making a new jumpsuit, right? In your first commit which you made yesterday, you made the basics of the new jumpsuit, giving it a name, description and a sprite. But- egads! When you open up dreammaker today, your code is gone! Well, you can fix that by reverting to your earlier commit, where everything will be restored to exactly how it was when you committed yesterday.
In order to commit, you'll want some files to commit. Add files you want to commit like how its shown in the file statuses section. Then, just type <syntaxhighlight line='none' enclose='none'>git commit -m "your commit log message here!!"</syntaxhighlight>
This will commit all the files you told it to commit, and save that in the commit log along with your message.  
(


<b>Pushing Changes:</b>
===ATOMs and Datums===
Just type <syntaxhighlight line='none' enclose='none'>git push origin feature/handholding</syntaxhighlight> to push your local changes on your local branch to your online version of the branch that other people can see and interact with.
As mentioned above, BYOND has certain built in classes. The first of these is /datum. This is simply the ancestral class, from which all others are derived; note that a class defined with no explicit parent is considered a child of /datum. From /datum comes /atom, the fundamental class for things in the game world. Simply put, if a thing is on the map, it derives from /atom. This brings us to the four elemental classes: /turf, /area, /mob, and /obj. Note that /turf and /area are derived directly from atom, whereas /mob and /obj are derived from /atom/movable. Only objects derived from the elemental classes can exist on the map; this contrivance means there is no point in defining direct descendants of /atom and /atom/movable.


===Tortoise Git Setup, Workflow, Commands, Useful Tips===
The /obj class is something of a catchall for movable objects. You might derive from it classes for machines, items, or even creatures. Anything player-controllable, however, must belong to /mob, intended exclusively for creatures. Both objs and mobs within the map are contained by objects of the class /turf/. A turf is simply a tile on the map. Being as it is a point on a grid, a turf cannot move. Turfs, in turn, are contained by objects of the class /area. Areas are meant for use as zones or rooms. In the same way that multiple items can be contained within a single map tile, multiple map tiles can be contained within a single area. You might, for example, wish for a certain sound to play when a player is in a given room, or for certain creatures to be barred from certain places, or goodness knows what else. The possibilities are myriad.
(ask urs to fill this one out she seems to know some of this stuff)


===Using Dreammaker===
It should be noted that there exist built-in classes not mentioned here, such as /client or /image, but they are not relevant at present.


Now I'm going to show you how to edit, compile, and run code, using DreamMaker.
In summary, the line of descent is as follows:
*/datum
*/datum/atom
*/datum/atom/area
*/datum/atom/turf
*/datum/atom/movable
*/datum/atom/movable/obj
*/datum/atom/movable/mob


To open DreamMaker, open byond. Then navigate to the setting menu and click Open DreamMaker
== Licenses and Stuff ==
[[File:Opendm.png]]
<b>Historical Structure</b>
===Introduction to DM as a language===
DM is a high-level programming language, meaning, effectively, that its use does not require much understanding of computer hardware. Its purpose is the creation of games, and so tricky things like memory management are smoothed over for the coder's convenience. This is done by way of a process virtual machine: .DM source code is compiled not into machine language, but into a binary format designed specifically for BYOND. For a Dream Maker Binary (.DMB) to run it must be hosted by Dream Daemon, one of BYOND's four executables (Dream Seeker, the program used to play BYOND games, can also host them, but it is not recommended for Space Station 13).


BYOND, being patterned on C++, is an object-orient programming language. Abstract classes are defined in the code, which serve as templates for objects manipulated by functions. Suppose, for example, you are making a game with bears. You define all the variables and functions associated with them: What they're called, how they move, etc. This is the bear class. Whenever a bear comes into existence within the game, an object of this class is instantiated. Though its variables are derived from its class, changes made to them are made only to that specific bear; neither other bears nor the template itself are affected.
Goonstation formerly stood at a weird intersection of open- and closed-source. Most of the code is closed-source, kept away from the public; however, some coders may share some code with you, particularly if you want to make a patch. In addition, there have been two public releases of the source code: [https://github.com/goonstation/goonstation-2016 one from March 2016] and [https://github.com/goonstation/goonstation-2020 one from 2020], which contains the source as it was on January 1st, 2020, with certain secrets and other things plucked out. Pretty much all the patches made at the time used code from these repositories. So, if closed source is a walled garden, Goonstation was a walled garden that occasionally let people in to study the gardening techniques and landscape patterns used, and sometimes, it released books and treatises explaining how the garden is constructed.
 
The concept of inheritance is central to object-oriented programming. One class can be derived from another, such that they share everything not defined in the child class. For instance, you might wish your game to feature a special type of bear. The path for a bear is /mob/bear (bear is itself a child of mob, a built-in class which will be discussed later). Therefore, you make a subclass /mob/bear/fuzzy_wuzzy. Any changes to /bear affect /bear/fuzzy_wuzzy, but not vice-versa. You can even define subtypes of inherited functions, a practice known as overloading. Suppose /bear has a function called sylvan_defecation, rendered in DM as /mob/bear/proc/sylvan_defecation(). However, you want bears of the /fuzzy_wuzzy variety to behave differently when answering nature's call, and so you overload that function by defining /mob/bear/fuzzy_wuzzy/sylvan_defecation() (note the absence of /proc/). Whenever a function calls sylvan_defecation() on a bear that belongs to the /fuzzy_wuzzy/ subclass, it will execute its special version of that function.
 
DM, as we discussed above, is executed by way of a process virtual machine. This means that, though it shares much of C++'s syntax and logic, it is ultimately a lot simpler. As such, it is not overly concerned with rigid type-management. A variable might represent a number one moment and a string the next. Such a transformation can still cause all manner of errors, if the coder does not account for it, but it won't necessarily cause the game to crash. In most cases Dream Daemon will simply shrug, inform you of your blunder, and carry on to the best of its abilities. This sort of extreme looseness is of dubious efficacy, but it means that you won't need to fret about the number of bytes allocated to a given value, whether a number can be negative, and other such distracting things.
 
===ATOMs and Datums===
(talk about area, turf, object, mob, datum, how the inheritance works for all of them, examples, why you should use specific ones for specific things)


===Code Stuff You Should Know===
<b>Current Structure</b>
(0 and false and null making ifs return false, basics of for/while loops, making new vars, overlays, adding basic procs, loc, src, usr, istype, switch, ..(), probably more lol)


===Code Conventions===
As of April 1st, 2020, the goonstation administration made the decision to make the code open-source; for the interested, a statement from the admins exists [https://hackmd.io/@ZeWaka/opensource at this link.] The new open source is [https://github.com/goonstation/goonstation found here]. Some elements are still kept secret, particularly content designed to be secret so it can't just be instantly looked up and figured out; but the vast majority of the code is now maintained there.
(talk about stuff like variable/proc naming, whitespace, commenting, ettiquite, where to put your files)


===Spriting/Sprites===
<b>License</b>
(talk about sprite stuff for code)


===Tips, Tricks and Useful Strategies===
Goonstation is specifically licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License, or just CC BY-NC-SA 3.0 US. It's best explained on [https://creativecommons.org/licenses/by-nc-sa/3.0/us/ its dedicated page] on the Creative Commons website, but it essentially means people like you can contribute code to Goonstation, using code from the public releases, open source release, and/or snippets of code shared by people on the Goonstation coder team, and the only lawyers you'll have to worry about are ones in-game.
(stuff like looking through the code to see if someone's done something you've already


===Submitting a Patch===
{{Community}}
(talk about compare vs pr, how to package up sounds, sprites, how to format a forum post, good resources for recording videos of patches)


== Supplementary Video ==
[[Category:Contribution Tutorials]]
<youtube>https://www.youtube.com/watch?v=_t0ZBAk72K8</youtube>

Latest revision as of 06:15, 21 June 2021

To Run, Host, Compile, And Develop on SS13 Go To The Goonstation Development Guide

Be sure to follow it exactly!

Discord is the place to talk to fellow players, admins, and devs in realtime. There's plenty of friendly people there, capable of answering most of your questions. Join at This Invite Link If you have problems with the above guide, visit ##imcoder

All of these links and more can be found at https://github.com/goonstation/goonstation

You can also take a look at DM by Example guide here: [1]

Introduction to DM as a language

DM is a high-level programming language, meaning, effectively, that its use does not require much understanding of computer hardware. Its purpose is the creation of games, and so tricky things like memory management are smoothed over for the coder's convenience. This is done by way of a process virtual machine: .DM source code is compiled not into machine language, but into a binary format designed specifically for BYOND. For a Dream Maker Binary (.DMB) to run it must be hosted by Dream Daemon, one of BYOND's four executables (Dream Seeker, the program used to play BYOND games, can also host them, but it is not recommended for Space Station 13).

BYOND, being patterned on C++, is an object-orient programming language. Abstract classes are defined in the code, which serve as templates for objects manipulated by functions. Suppose, for example, you are making a game with bears. You define all the variables and functions associated with them: What they're called, how they move, etc. This is the bear class. Whenever a bear comes into existence within the game, an object of this class is instantiated. Though its variables are derived from its class, changes made to them are made only to that specific bear; neither other bears nor the template itself are affected.

The concept of inheritance is central to object-oriented programming. One class can be derived from another, such that they share everything defined in the parent class. For instance, you might wish your game to feature a special type of bear. The path for a bear is <syntaxhighlight lang='cpp' line='none' enclose='none'>/mob/bear</syntaxhighlight> (bear is itself a child of mob, a built-in class which will be discussed later). Therefore, you make a subclass <syntaxhighlight lang='cpp' line='none' enclose='none'>/mob/bear/fuzzy_wuzzy</syntaxhighlight>. Any changes to /bear affect /bear/fuzzy_wuzzy, but not vice-versa. You can even define subtypes of inherited functions, a practice known as overloading. Suppose /bear has a function called sylvan_defecation, rendered in DM as <syntaxhighlight lang='cpp' line='none' enclose='none'>/mob/bear/proc/sylvan_defecation()</syntaxhighlight>. However, you want bears of the /fuzzy_wuzzy variety to behave differently when answering nature's call, and so you overload that function by defining <syntaxhighlight lang='cpp' line='none' enclose='none'>/mob/bear/fuzzy_wuzzy/sylvan_defecation()</syntaxhighlight> (note the absence of /proc/). Whenever a function calls sylvan_defecation() on a bear that belongs to the /fuzzy_wuzzy/ subclass, it will execute its special version of that function.

DM, as we discussed above, is executed by way of a process virtual machine. This means that, though it shares much of C++'s syntax and logic, it is ultimately a lot simpler. As such, it is not overly concerned with rigid type-management. A variable might represent a number one moment and a string the next. Such a transformation can still cause all manner of errors, if the coder does not account for it, but it won't necessarily cause the game to crash. In most cases Dream Daemon will simply shrug, inform you of your blunder, and carry on to the best of its abilities. This sort of extreme looseness is of dubious efficacy, but it means that you won't need to fret about the number of bytes allocated to a given value, whether a number can be negative, and other such distracting things.

ATOMs and Datums

As mentioned above, BYOND has certain built in classes. The first of these is /datum. This is simply the ancestral class, from which all others are derived; note that a class defined with no explicit parent is considered a child of /datum. From /datum comes /atom, the fundamental class for things in the game world. Simply put, if a thing is on the map, it derives from /atom. This brings us to the four elemental classes: /turf, /area, /mob, and /obj. Note that /turf and /area are derived directly from atom, whereas /mob and /obj are derived from /atom/movable. Only objects derived from the elemental classes can exist on the map; this contrivance means there is no point in defining direct descendants of /atom and /atom/movable.

The /obj class is something of a catchall for movable objects. You might derive from it classes for machines, items, or even creatures. Anything player-controllable, however, must belong to /mob, intended exclusively for creatures. Both objs and mobs within the map are contained by objects of the class /turf/. A turf is simply a tile on the map. Being as it is a point on a grid, a turf cannot move. Turfs, in turn, are contained by objects of the class /area. Areas are meant for use as zones or rooms. In the same way that multiple items can be contained within a single map tile, multiple map tiles can be contained within a single area. You might, for example, wish for a certain sound to play when a player is in a given room, or for certain creatures to be barred from certain places, or goodness knows what else. The possibilities are myriad.

It should be noted that there exist built-in classes not mentioned here, such as /client or /image, but they are not relevant at present.

In summary, the line of descent is as follows:

  • /datum
  • /datum/atom
  • /datum/atom/area
  • /datum/atom/turf
  • /datum/atom/movable
  • /datum/atom/movable/obj
  • /datum/atom/movable/mob

Licenses and Stuff

Historical Structure

Goonstation formerly stood at a weird intersection of open- and closed-source. Most of the code is closed-source, kept away from the public; however, some coders may share some code with you, particularly if you want to make a patch. In addition, there have been two public releases of the source code: one from March 2016 and one from 2020, which contains the source as it was on January 1st, 2020, with certain secrets and other things plucked out. Pretty much all the patches made at the time used code from these repositories. So, if closed source is a walled garden, Goonstation was a walled garden that occasionally let people in to study the gardening techniques and landscape patterns used, and sometimes, it released books and treatises explaining how the garden is constructed.

Current Structure

As of April 1st, 2020, the goonstation administration made the decision to make the code open-source; for the interested, a statement from the admins exists at this link. The new open source is found here. Some elements are still kept secret, particularly content designed to be secret so it can't just be instantly looked up and figured out; but the vast majority of the code is now maintained there.

License

Goonstation is specifically licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License, or just CC BY-NC-SA 3.0 US. It's best explained on its dedicated page on the Creative Commons website, but it essentially means people like you can contribute code to Goonstation, using code from the public releases, open source release, and/or snippets of code shared by people on the Goonstation coder team, and the only lawyers you'll have to worry about are ones in-game.

Community
Contributing Guide to Contributing to Wikistation · Goonstation Development Guide · Goonstation Contributor Guidelines · Spriting · Goonstation Spriting Guidelines · Coding · Goonstation Code Guide · Hosting a server · Mapping · Goonstation Map Submission Guidelines · Goonstation Audio Guidelines · Contributing to Requisitions
Members Admins
Culture & Art Terminology · Storyline (Old Storyline) · Fan Videos · Fan Art
History & Happenings Changelog · Pre-2016 Changelog · History of SS13
Tales & Humor Sex and the Singularity · Maintenance Doggs · The Rapper · The Trial of Heisenbee · Albert and the Deep Blue Sea · The uWu Interrogation · HeadSurgeon · Tales of The Devil‎ · IT'S ALIVE! It died. IT'S ALIVE! It died. IT'S ALIVE!‎ · The floor is now explosions‎ · My god, it's full of butt · The Crashwich · The Doom Peel‎ · Jugglemancy‎