If you're familiar with the framework, you can help out others in the discord server.
If something isn't working quite as expected, report it on the issue tracker. Make sure to accurate describe your situation, the behaviour you're seeing, and the behaviour you're expecting. Consider also attaching a minimal example project to make it easier for others to reproduce.
Sometimes there are typos or wrong/missing information in comments and documentation. Those instances should also be reported on the issue tracker.
If there's a feature you'd like to see added to the framework, head over to the issue tracker and create a new issue.
In your issue, thoroughly explain the feature you would like to see and why it would be a good addition to the framework.
Then add the question label to the issue and a collaborator will take a look and decide if they think your idea is suitable for the framework.
Every pull request should have a corresponding issue that it fixes. If you're looking for something to fix for the first time, try taking a look at issues with the good first issue label.
To submit changes to MDFramework via a Pull Request, first you should fork the repo to have a copy of your own. Pull requests that get accepted to MDFramework will be Squashed & Merged to keep the changes in a single commit. To prevent that from messing up the history of your fork's master branch, you should create feature branches for each pull request you'll make. This will keep your commits to the feature branch then once your pull request is accepted and merged, you can pull latest with the squashed commit to your master branch.
Sometimes a pull request will require changes to the Wiki, but since only collaborators are allowed to modify the wiki, you might not be able to make the update yourself. Instead, your pull request description should include what changes need to be made and the full write-up to be added to the wiki, if applicable. Then a collaborator will make the wiki changes for you when the pull request is merged.
If either your pull request adds a new feature that could benefit from an example or you want to add an example for a feature that doesn't have one yet, create a pull request for the Examples Repo.
MDFramework uses XML Comments. At a minimum, every accessible class, member, type, etc should have a completed <summary> tag.
By accessible, it's meant that anything that could be referenced or used by an MDFramework user, not necessarily a contributor. This will typically mean, if it's marked public or protected then it should have a <summary>.
MDFramework uses 4-space indents.
Nesting should be minimized, if reversing logic can reduce the amount of nesting, please do so.
PascalCase should be used globally. There are some exceptions, for example const variables should use SCREAMING_SNAKE_CASE.
The opening brace should always be on a new line unless if the block is empty then the opening and closing brace can be on the same line.
virtual int MyVirtualFunc()
{
return -1;
}virtual void MyVirtualFunc() {}Single line blocks for an if or for should always have braces.
if (condition == false)
{
return;
}The use of regions is optional, but if the file you're modifying already has regions, please continue to adhere to them.
String interpolation is prefered over format strings.
MDLog.Error(LOG_CAT, $"The value {value} was below 0");The main class for the file should be at the bottom of the file (eg. MDGameInstance in MDGameInstance.cs).
The order of appearance otherwise from top to bottom should be: namespace, enum, struct, class.
When inside of other blocks, these should appear before the fields, properties, and methods.
Field and Properties should come before methods.
All aspects of MDFramework should be in the MD namespace.
Functions that are marked internal to a class/struct should have the _Internal suffix.