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.
Nothing can be disclosed about any project unless that project is in a playable state and is capable of having a public demo released.
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.
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.
No release date can be given to the public for any project that is not fully complete.
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.
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.
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.
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.
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.
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.
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.
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.
We will be honest with the public in all dealings, even if doing so may negatively impact our potential for earnings or profit.
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:
While it is always nice to have new features added to an existing game, fixing bugs is always our top priority.
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.
To prevent overloading the various services we use, we will only release a maximum of one bug patch per week for any given project.
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.
When following the TVI Paradigm, 100% of the truth should be covered with unit tests.
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.
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.
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.
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.
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.
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.