- How to Open a Bug Report
- How to Open a Feature Request
- How to Find Documentation Tasks
- How to Find Programing Tasks
- How to Find Creative Tasks
Thank you for taking a look at Spectra. With the help of potential contributors, like you, we hope to make this one of the best SIM-RTS-RPG (hew!) games out there.
The following document was put together to help you to better understand how to find something to do, how to go about doing that thing and then how to share that with the rest of the community. We understand that it's very frustrating having a desire to help out but not knowing where to start or, you know where to start, but lack the detailed instructions for doing something you already know you want to do.
In every game studio the tasks are broken down into manageable parts. Those parts are then worked on by people who have the desire and the talent to get those tasks accomplished. These tasks often fall into a number of specific roles:
- Evangelist - Someone who really loves and understand the work and wants to connect others to it
- Quality Controller - Someone who doesn't mind pushing things to their limit and breaking something (if only to make it better!)
- Technical Writer - Someone who understand the project and wants to help others understand it as well
- Game Designer - Someone who has played a wide number of games and understands how to create game mechanics that others will love
- Programmer - Someone who understand how to implement the concepts proposed by the Game Designers
- Artist - Someone who has a technical knowledge of how modern video games work but also have been touched by a muse; be their expertise in animations, images, models, story lines or other creations.
There can be many more roles but these are the ones that we will focus on throughout the rest of this document.
There are a number of ways that you can directly contribute, even if you are not a programmer or an artist. Documents are always needing to be read, re-read and updated as things change with in the project and to correct those pesky grammatical and spelling bugs that seem to creep in. In addition, tutorials and explanation articles are always welcome, as well as bug related tasks (finding and reporting them, and detailed bug investigations), feature request research and of course we'll take code, art and Unity asset submissions as well.
Often people will end up wearing many hats, where an artist might contribute some documentation or provide a crucial bug fix, a programmer might try their hand at some art assets and Technical Writers might feel the need to evangelize the game. These roles are in no way meant as a limitation but as a organization tool for work that needs to be performed.
When contributing please take note that we subscribe to the Contributor Covenant Code of Conduct and we expect all contributors to abide by the code contained. Please take a moment to review this document if you have not already.
This is by far the most open-ended of the roles as there is no telling who might find our game fun and become impassioned enough to tell others; and we like it like that. If you feel the need to express your love for Spectra then we encourage you, however, there are some things we would rather you NOT do:
- NO LYING - No providing false or misleading information in regards to Spectra, it's developers, it's community, those that have contributed, those that will contribute or about anyone or anything that has, currently or will at some future time exist in our shared three dimensional universe.
- Post to Appropriate Places - Do not post information on forums, chat rooms, message boards, mailing lists or any other form of communication in which ideas are transferred from one being to another that is not appropriate to that venue.
- Respect Other's Disinterest - If a community doesn't wish to know about the awesome that is Spectra then do not press or in any way make yourself an annoyance to those who you are evangelizing.
- NO HYPE - Things will take as long as they take and hype only makes for people getting upset and disappointed.
Outside of the above items you should not do, feel free to tell everyone far and wide about the virtues of Spectra and how it can improve their lives. Also, let developers know that if they too wish to partake in our community that we would very much appreciate anything they have to offer. Just like yourself, we are all here because of our desire to make Spectra great and in the end this project is not about the documents, assets or the logic but is about the people and our shared vision.
These are the true warriors, fighting in the trenches to bring a better experience for the rest, it can not be stressed enough how important good Quality Controllers are to a project. Many software houses tend to under value the work that Quality Controllers provide and often leave it to the community to debug (oh ...) their code, assets and documentation. Here we understand the absolute need for the services they provide and are grateful for every detailed bug report provided.
- Determine if the bug has already been reported
- If you find that the Issue has already been opened then a new Issue is not needed.
- Feel free to add your experiences to bug reports and to reopen bug Issues if it crops up again.
- Create a "Bug Report" on the Issues page.
- Add [BUG] to the title of your issue (ie [BUG] Cats Get Too Many Cheeseburgers)
- Make sure that you are very detailed with what you are experiencing
- Check back often, or enable the notification options, in case others have questions or need further clarification
Game designers contribute to the project by helping to define how the mechanics of the game actually work. Much of what makes a good game depends greatly on how thoroughly thought out each and every game element is. The hallmark of good game design is when that design is transparent to the player and appears seamless and intuitive. With the help of good Game Designers Spectra will be one of those games!
It might be a little nuanced the difference between a bug vs a change in the expected operation of the game. In the case of the latter we would want to open a feature request. The following is a few examples of what would constitute a Feature Request:
- The element is completely missing from the project
- Current behavior is missing a critical element to make it complete
- A current element behaves in a way you feel is detrimental to the project as a whole but is the current, expected, behavior
When you have the next best feature for the Spectra project you will first need to let us know about it!
- Determine if the same or similar Feature Requests already exists.
- If one does exist, feel free to expand upon it by commenting on the Issue but do not open a new one.
- Create a Feature Request on the Issues page.
- If your Feature Request requires additional/changed documentation then a Documentation Request is also required
- You must provide a reference to the Documentation Request in the Feature Request Issue
- Make sure that you are very detailed with what you think the feature should accomplish, how it should be implemented and it's predicted effect on other features.
- If your Feature Request requires additional/changed documentation then a Documentation Request is also required
- Check back often, or enable the notification options, in the event others have questions about your proposal
- You will know when the feature is accepted when the "approved" label is assigned to it
- If there are multiple requests as a part of the feature, the feature will not be moved to the master branch until all dependent parts have been completed.
- It is important to keep in mind that all new features, even simple changes, often have wide ranging effect which need to be fully explored.
- Also remember that not all features can be added into the game (but I'm sure we'll try!) and features need to be released in an orderly way so even if the feature is accepted it may not go in immediately.
- Determine if the Documentation Request you want to create already exists.
- Ask questions about implementation on the Issue thread and/or join the Discord server to talk with people in real time.
- If you find an Issue that is very close to what you'd like to do but missing some critical element, comment on that Issue so the change can be discussed.
- Open an Issue explaining your proposed documentation changes/additions
- Add [DOC] the title of your issue (ie. [DOC] How to Install Spectra)
- Others may ask questions or request changes to your proposal so make sure to check back, or enable the notification options!
- You will know if the Issue is accepted when it's given the "approved" label
- If there are multiple requests as a part of the request, the request will not be moved to the master branch until all dependent parts have been completed.
- Determine if the same or similar Asset Requests already exists.
- If one does exist, feel free to expand upon it by commenting on the Issue but do not create a new one.
- Create an Asset Request on the Issues page.
- If your Asset Request requires additional/changed documentation then a Documentation Request is also required
- You must provide a reference to the Documentation Request in the Asset Request Issue
- The more detailed you are (reference image links are suggested) the more likely you are to get an artist to pick it up.
- If your Asset Request requires additional/changed documentation then a Documentation Request is also required
- Check back often, or enable the notification options, in the event others have questions about your proposal
- You will know when the feature is accepted when the "approved" label is assigned to it
- If there are multiple requests as a part of the feature, the feature will not be moved to the master branch until all dependent parts have been completed.s
Technical Writers are the back-bone of a well organized project. There is nearly an endless amount of information that needs to be documented so that everyone can be on the same page.
Often, these skilled people come after a large part of the functionality of the project is complete but this is where this projects diverges from that norm. It's very likely that the game, over many iterations will change and become more than what it was before, and this will cause the documentation to change. If this fact does not dissuade you then please read on!
- Code Level Documentation - This should be performed by the Programmers but in the event it is missed or is found lacking, we would love people to add to the code clarity.
- Features and Functions - Documenting how the game works from the most general, "How to Open Spectra" to the ridiculously explicit "How to Play 12 Copies of Spectra at Once with Helium Cooled Processors"
- Public Relations - This is how we present ourselves to the world at large. This includes the web pages, GitHub pages, any promotional material and press releases.
- Tutorials - Show others how to do things that they don't yet know how to do. These could include trade related articles, videos, local pages or anything else where something unclear becomes more so (clear that is).
- Look at the Issue tracker for Documentation Requests:
- Issues must be open, "approved" and unassigned before any work should be done.
- There may be bugs in the current documentation so it may be worthwhile to look there as well
- Submit your own Documentation Request
- Find an Issue to resolve
- Fork the repository
- Create a new branch with the format 'issue#{issue-id}-{your-github-user}' (ie issue#224-mdwigley)
- Make any changes or additions to your new branch
- Make sure to keep your forks in sync with the original repository
- If you find that you need help with implementation, ask to have the "Help Wanted" label added to the issue as well as seeking others on the Discord server
- When finished, submit a Pull Request that includes just the changes in the Issue.
- Others may ask questions or request changes so make sure to check back, or enable the notification options!
- The Pull Request will be reviewed and, if approved, will be merged.
- If there is an Asset or Project Issue in conjunction with the Documentation Issue, the feature will not be moved to the master branch until all dependent parts have been completed.
- When merged you will be an official contributor.
Programmers are responsible for implementing the features presented by Game Designers and managing the assets created by Artists.
- Look on the Issue Tracker
- Ask questions about implementation on the Issue thread and/or join the Discord server to talk with people in real time.
- Issues must be open, "approved" and unassigned before any work should be done.
- Assist Team Members/Contributor already assigned to an Issue
- If a Team Member/Contributor is working on something you feel you are particularly good with, ask if they would like assistance and if there is anything you can do to help.
- Whoever is assigned to an Issue is ultimately responsible for it and has the final say on how that Issue will be implemented.
- if you fundamentally disagree with an approach or implementation you are free to voice that concern in the Issue and can ultimately file a subsequent Feature Request to change the implementation or approach in the future.
- Not all Programmers or Issues lend themselves to assistance so please do not take it personally if the Programmer doesn't want/need assistance.
- Submit your own Feature Request
- Setup your Development Environment
- Find an issue to resolve
- Fork the repository
- Create a new branch with the format 'issue#{issue-id}-{your-github-user}' (ie issue#224-mdwigley)
- Update sub-modules
- Make any changes or additions to your new branch (do not modify "./Assets/Internal")
- Make sure to keep your forks in sync with the original repository
- If you find that you need help with implementation, ask to have the "Help Wanted" label added to the issue as well as seeking others on the Discord server
- Ensure all files have been white-space formatted
- Often the default formatting for Visual Studio or MonoDevelop will do
- If you use Visual Studio you can use the official format settings
- Comment your code with both code level and construct definitions
- We use Doxygen for code level documentation
- When finished, submit a Pull Request that includes just the changes in the Issue.
- Others may ask questions or request changes so make sure to check back, or enable the notification options!
- The Pull Request will be reviewed and, if approved, will be merged.
- If there is an Asset or Documentation Issue in conjunction with the Project Issue, the feature will not be moved to the master branch until all dependent parts have been completed.
- When merged you will be an official contributor!
The title Artist, in this respect, covers a wide array of potential contributors skill sets. From audio to particle systems to models and textures to sprites and UI, there is a near endless need for assets and no lack of need for their refinement and optimization. What sets a video game artist into a league of their own is the equally wide array of technical knowledge surrounding the implementation of their art.
- Look at the Issue tracker for Asset Requests
- Only Issues with the label of "approved" should have any work performed
- Ask questions about implementation on the Issue thread and/or join the Discord server to talk with people in real time.
- Assist Team Members/Contributor already assigned to an Issue
- If a Team Member/Contributor is working on something you feel you are particularly good with, ask if they would like assistance and if there is anything you can do to help.
- Whoever is assigned to an Issue is ultimately responsible for it and has the final say on how that Issue will be implemented.
- If you fundamentally disagree with an approach or implementation you are free to voice that concern in the Issue and can ultimately file a subsequent Asset Request to change the implementation or approach in the future.
- Not all Artists or Issues lend themselves to assistance so please do not take it personally if the Artist doesn't want/need assistance.
- Submit your own Asset Request
- Find an issue to resolve
- Fork the repository and clone the repository to your local system.
- Update sub-modules
- Create a new branch in the Assets fork with the format 'issue#{issue-id}-{your-github-user}' (ie issue#167-mwigley)
- Make any changes or additions to your new branch under the Studio's Asset sub-module starting at "./Assets/Internal/"
- Commit changes to your branch on the repository
- When finished, submit a Pull Request that includes just the changes in the Issue.
- Others may ask questions or request changes so make sure to check back, or enable the notification options!
- The Pull Request will be reviewed and, if approved, will be merged.
- If there is an Project or Documentation Issue in conjunction with the Asset Issue, the feature will not be moved to the master branch until all dependent parts have been completed.
- When merged you will be an official contributor!
This CONTRIBUTING document was compiled with the help of nayafia/contributing-template.