Policies

This page outlines the various internal policies that have been established in regards to CupCode Gamers public relations. These policies must be adhered to at all times by all employees and/or representatives of CupCode Gamers. These policies are provided to the public in the interest of providing clarity to our business practices and procedures.

1. No WIP Disclosures

   Nothing can be disclosed about any project unless that project is in a playable state and is capable of having a public demo released.

2. No Future Disclosures

   No features of any project may be disclosed to the public unless that feature is already included in the project and is tested to be working.

3. Regular Postings

   Once a project has been announced to the public, there must be regular postings on the website to keep the community up to date with what is going on with the project.

4. No Release Dates

   No release date can be given to the public for any project that is not fully complete.

5. Final Release Date

   Once a project has been completed, and is ready for publication, a release date may be given to the public at that time.  Once a release date is set, it can not be changed.

6. Real Gameplay Only

   Any videos or images released about a project can only contain actual gameplay footage from the actual game.  No scripted environments or external CGI are allowed.  

7. Non-Disclosure Agreements

   Anyone that is involved with working on any project must sign a Non-Disclosure Agreement stating that they will not disclose any information about the project without express permission, regardless of whether the project has been published or not.

8. 3rd Party Resources

   3rd party resources, such as code or other assets, may only be used if there is sufficient documentation to prove that the original author provides us permission to use it in a commercial capacity.

9. Open Source Licenses

   Open source resources may only be used if the associated license does not restrict our usage of the resource in a commercial capacity, or require us to release anything to the public.

10. Video Friendly

    We allow, and encourage the production and publication of videos and video streams that portray our products. We also allow those videos and streams to be monetized without additional requirements.

11. Post Release Announcement

    Once a release date has been announced, only bug fixes and new content can be added to the project. New features may not be added until after the release. New content may be added only if it has minimal chance of introducing new bugs.

12. User Privacy

    We will only collect the bare minimum amount of data necessary. That data will be maintained in the highest security level possible. Collected data will not be shared with any other persons, companies, or entities for any reason.

13. Honesty Over Profit

    We will be honest with the public in all dealings, even if doing so may negatively impact our potential for earnings or profit.

14. Development Standards

    It is our intent to develop our software to be as bug free as possible. To help ensure this occurs, we have enacted the following development polices:

    1. Bugs First

       While it is always nice to have new features added to an existing game, fixing bugs is always our top priority.

    2. Bug Patch Timing

       We can not hold any bug fix for more than a week once its completed. Let's say we've got 3 bugs, and we fix one of them, but the other two will take a while. We will not hold that first bug until the other two are done, instead we will release that bug fix on its own.

    3. One Patch per Week

       To prevent overloading the various services we use, we will only release a maximum of one bug patch per week for any given project.

    4. Unit Testable

       All game code should be written using the TVI Paradigm unless doing so would negatively impact the performance of the game. This is to help ensure that all game functionality is unit testable.

    5. 100% Unit Test Coverage of Truth

       When following the TVI Paradigm, 100% of the truth should be covered with unit tests.

    6. Test Driven Development

       When writing new code, or updating existing code, developers should follow the Red, Green, Refactor coding cycle. Unit tests should be written first based on the code requirements. Then the method should be written/edited until the unit test passes. Then the code should be refactored to make it run better or more efficiently.

    7. Unit tests from Bugs

       Whenever a bug is reported, a developer should write a new unit test that fails as long as the bug exists. Then the code should be updated to fix the bug. This helps to ensure that the same bug is never released again.

    8. Release Process

       All releases should occur only from an appropriate master branch. Feature and development branches should be merged into a staging branch and tested both via unit tests and qa testing. Upon successful testing the staging branch should be merged with a master branch and a release can be built from there.

    9. Constant and Consistent Error Handling

       All methods in the code should be wrapped in error handlers. Any methods that return values should return a default or predetermined error value when an error occurs. All errors should be logged to an error log. While this may be seen as unnecessary in most methods, it guarantees that the application never crashes, and allows us to control any actual failures that occur.

    10. Error Logs

        To facilitate faster bug fixes, all new projects should contain a means of logging all errors to an error log. The contents of the error log, in full or partial, should be accessible from within the game. This will allow players to provide more technical details when making bug reports. Every log entry should contain class and method names to help developers identify where an error occurs, as well as a code or text that describes the error.

    11. In-App Bug Reporting

        When possible, players should have the ability to report bugs from directly within the game. They should be given the option of including a screen-shot or the error logs in the bug report.

15. Staff Rights

    At CupCode Gamers, we believe in individuality and the freedoms of expression. We strongly stand behind all of the first 10 amendments. However, we do have to ensure the clean public image of our company, so we have enacted the following policies to outline how we handle various issues:

    1. Freedom of speech and expresion

       Staff members are free to express their opinions in any way they please as long as they are:

       1. Not doing so while directly representing CupCode Gamers.
       2. Not violating any laws.
       3. Not providing any indication that its the opinion of CupCode Gamers.
       4. Not referencing CupCode Gamers, or using any image, mark, product, or other materials that belong to CupCode Gamers.
    2. Criminal acts

       As a company, we will not take any actions against any staff member for any crime committed outside the company until that staff member is found guilty and is formally sentenced. However, if the crime was committed while working for or representing CupCode Gamers, then we may take action against them based on the action during work time.

    3. The Second Amendment

       As a company, we support the second amendment in full. Any staff member who does not have any criminal convictions in their past are permitted, and even encouraged to bear arms while in our offices. As a company, we will even assist staff members to obtain the necessary certifications and permits to bear arms visibly or concealed. It is our belief that an armed work-force is a better deterrent and protection than a single guard or security cameras.