Difference between revisions of "Darwinbots 3"
m (→Introduction) |
(→Where's the DB3 EXE?) |
||
| (73 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | Darwinbots 3 is a long term project to recode Darwinbots in C# as a brand new program. Every feature and aspect is going to be examined and refined as its added, in a framework that will ensure robustness and agility in handling bugs and new features. | + | Darwinbots 3 is a long term project to recode Darwinbots in C# as a brand new program. Every feature and aspect is going to be examined and refined as its added, in a framework that will ensure robustness and agility in handling bugs and new features. The code can be browsed: [http://svn.darwinbots.com/Darwinbots3/ http://svn.darwinbots.com/Darwinbots3/] |
| − | == | + | == Compiling the code == |
| − | === | + | === Getting the compiler === |
| − | + | You'll need a version of Visual C# that's at least 2013. Newer versions should work fine, but I haven't tested it. (Also, this all might run under Mono in Linux, but I don't have either so no promises). You can download [http://msdn2.microsoft.com/en-us/express/aa975050.aspx C# express] for free. The whole process will probably take several hours to do. | |
| − | + | You will also need to install Python, at least version 3.6. You can [https://www.python.org/downloads/windows/ download Python here]. | |
| − | === | + | === Downloading the dependencies === |
| − | * | + | To compile/run the project, you need: |
| + | |||
| + | * DirectX installed. Needs to be the latest version installed. Try running the [http://www.microsoft.com/en-us/download/confirmation.aspx?id=35 web installer] to see if you have the latest version. | ||
| + | |||
| + | === Get either Subversion or a Subversion client === | ||
| + | For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You "check out" a copy of the current source code from the repository and store it locally on your computer. You then change the source code in places and "commit" it back to the repository. If there have been changes in the mean time that conflict with your changes (should be a pretty rare occurrence), SVN will notify you and ask you to resolve the problem before the commit is applied to the central code repository. Another advantage of working this way is that the entire evolution of the code is tracked. If some bug is found that was introduced months ago, you can browse through the repository at different versions of the program to find what changes caused it. | ||
| + | |||
| + | You can either try one of the [http://www.sliksvn.com/en/download Subversion commandline builds] if you're into that sort of thing, or try one of the GUI based Subversion clients. I like [http://www.syntevo.com/smartsvn/index.html SmartSVN] myself. | ||
| + | |||
| + | === Accessing the repository and committing === | ||
| + | [http://svn.darwinbots.com/Darwinbots3/ http://svn.darwinbots.com/Darwinbots3/] This is the link for the repository. It has anonymous access, so anyone can download and browse it. To commit changes, you need a username and password. Post a request for one [http://forum.darwinbots.com/index.php/board,62.0.html here]. If you haven't registered in the forum yet, please do so. It's important that progress is talked about so others can see what's going on. | ||
| + | |||
| + | === How you should set up your SVN projects and local directories === | ||
| + | You can dump the source whereever you want. Everything is set up with relative paths. I usually put it on the root level myself: | ||
| − | * | + | C:\ |
| + | * \Darwinbots3Source <-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them | ||
| − | === | + | === Visual Studio solution files === |
| − | + | Instead of one large master solution file to build the entire project, each module maintains its own solution file for just that solution. Usually it will contain the module itself, some unit tests, and a test app. This is to make checking unit tests for errors simpler, among other purposes. All the modules spit out binaries in to the bin/Release directory, and these are checked in, so there's no need to rebuild everything very often (assuming source and binary and kept in sync, which will usually be true). To build the entire project, you'll need to run one of the build scripts in the Scripts directory. | |
| − | + | Rebuilding everything locally can help with debugging across module boundaries, though. | |
| − | |||
| − | |||
| − | === | + | === Junk directories and bin folders === |
| − | + | The projects are set up to place bulky build files in the Junk directory. This directory should always be empty on the repository, except for the "About This Folder.txt" file. Final EXEs are built to the Bin folder. None of the binaries are checked in to the repository. The binaries in the Bin folder are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). | |
| − | |||
| − | |||
| − | + | === You have the code, now what? === | |
| − | + | You'll need to build all the different modules. There isn't a single solution file to build everything (on purpose, since lots of smaller solution files are more manageable), but in the Scripts folder there's a batch file called build.py that will build everything in the correct order. Run that file. If you have a different version of Visual Studio than 2013 you'll need to run it from the command line with the --version flag set. eg: For Visual Studio 2017 the version is 15 (confusingly), so you'd set --version=15 and it should work. | |
| − | |||
| − | + | === Where's the DB3 EXE? === | |
| + | Under Modules\Darwinbots3 there is a Darwinbots3 solution. At the moment the Darwinbots3 binary is pretty empty, but there is a Bot.Testbed application that is starting to come together. | ||
== Coding standards == | == Coding standards == | ||
| − | + | ||
| + | === Basic Standards === | ||
| + | Look at the code, and follow by example. | ||
| + | |||
| + | === Repository etiquette === | ||
| + | * Prefer to post lots of small, atomic changes over large, far-reaching changes. It's easier to integrate for other people, and minimizes the possibility of commit conflicts. | ||
| + | |||
| + | * Keep the repository's code running. Don't commit a change that would break the program, or worse, prevent it from compiling. If you do anyway, fix the problem immediately. | ||
| + | |||
| + | * Be careful what files you submit. If it's a large temporary file you accidentally submitted it will take up repository space for ever and ever, even if you remove it from the repository later. | ||
=== Unit testing === | === Unit testing === | ||
| − | Unit testing is a way to ensure that a function or section of code works like you think it should. It is '' | + | Unit testing is a way to ensure that a function or section of code works like you think it should. It is ''immeasurably'' important for keeping the code robust and bug free. It also makes refactoring much easier. [http://www.gamesfromwithin.com/articles/0502/000073.html this site] is an excellent introduction to Unit Testing for games. |
| − | |||
| − | |||
| − | + | Ideally, you would write the tests first and then "fix" the program to pass those tests. This requires some discipline that I personally don't always have, so I'm not going to ''strongly'' enforce this. Aim for this standard anyway. Definitely unit test as many aspects of the code you're working on as possible, even if it's after the fact. | |
| − | I'm not | ||
| − | + | If you want to submit code without tests, it'll probably end up in the trashcan, honestly, when time comes for me to figure out how it's supposed to work (and why it's currently not working). | |
| − | |||
| − | + | == Release pattern == | |
| + | When a new release is ready, it's given a version number. The format is: | ||
| + | * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable | ||
| + | * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable | ||
| + | * '''Darwinbots3.0.exe''' - The first feature complete and stable release. | ||
| + | * '''Darwinbots3.XXX RC1''' - A release candidate. The number after RC is the release candidate version. The XXX is the version number (starts at 001, goes to 999). | ||
| + | * '''Darwinbots3.XXX''' - The stable release for version XXX. | ||
| − | + | Note that these files alphabetically sort according to when they are expected to release. This is important. | |
Latest revision as of 05:06, 6 May 2017
Darwinbots 3 is a long term project to recode Darwinbots in C# as a brand new program. Every feature and aspect is going to be examined and refined as its added, in a framework that will ensure robustness and agility in handling bugs and new features. The code can be browsed: http://svn.darwinbots.com/Darwinbots3/
Contents
- 1 Compiling the code
- 1.1 Getting the compiler
- 1.2 Downloading the dependencies
- 1.3 Get either Subversion or a Subversion client
- 1.4 Accessing the repository and committing
- 1.5 How you should set up your SVN projects and local directories
- 1.6 Visual Studio solution files
- 1.7 Junk directories and bin folders
- 1.8 You have the code, now what?
- 1.9 Where's the DB3 EXE?
- 2 Coding standards
- 3 Release pattern
Compiling the code
Getting the compiler
You'll need a version of Visual C# that's at least 2013. Newer versions should work fine, but I haven't tested it. (Also, this all might run under Mono in Linux, but I don't have either so no promises). You can download C# express for free. The whole process will probably take several hours to do.
You will also need to install Python, at least version 3.6. You can download Python here.
Downloading the dependencies
To compile/run the project, you need:
- DirectX installed. Needs to be the latest version installed. Try running the web installer to see if you have the latest version.
Get either Subversion or a Subversion client
For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You "check out" a copy of the current source code from the repository and store it locally on your computer. You then change the source code in places and "commit" it back to the repository. If there have been changes in the mean time that conflict with your changes (should be a pretty rare occurrence), SVN will notify you and ask you to resolve the problem before the commit is applied to the central code repository. Another advantage of working this way is that the entire evolution of the code is tracked. If some bug is found that was introduced months ago, you can browse through the repository at different versions of the program to find what changes caused it.
You can either try one of the Subversion commandline builds if you're into that sort of thing, or try one of the GUI based Subversion clients. I like SmartSVN myself.
Accessing the repository and committing
http://svn.darwinbots.com/Darwinbots3/ This is the link for the repository. It has anonymous access, so anyone can download and browse it. To commit changes, you need a username and password. Post a request for one here. If you haven't registered in the forum yet, please do so. It's important that progress is talked about so others can see what's going on.
How you should set up your SVN projects and local directories
You can dump the source whereever you want. Everything is set up with relative paths. I usually put it on the root level myself:
C:\
- \Darwinbots3Source <-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them
Visual Studio solution files
Instead of one large master solution file to build the entire project, each module maintains its own solution file for just that solution. Usually it will contain the module itself, some unit tests, and a test app. This is to make checking unit tests for errors simpler, among other purposes. All the modules spit out binaries in to the bin/Release directory, and these are checked in, so there's no need to rebuild everything very often (assuming source and binary and kept in sync, which will usually be true). To build the entire project, you'll need to run one of the build scripts in the Scripts directory.
Rebuilding everything locally can help with debugging across module boundaries, though.
Junk directories and bin folders
The projects are set up to place bulky build files in the Junk directory. This directory should always be empty on the repository, except for the "About This Folder.txt" file. Final EXEs are built to the Bin folder. None of the binaries are checked in to the repository. The binaries in the Bin folder are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects).
You have the code, now what?
You'll need to build all the different modules. There isn't a single solution file to build everything (on purpose, since lots of smaller solution files are more manageable), but in the Scripts folder there's a batch file called build.py that will build everything in the correct order. Run that file. If you have a different version of Visual Studio than 2013 you'll need to run it from the command line with the --version flag set. eg: For Visual Studio 2017 the version is 15 (confusingly), so you'd set --version=15 and it should work.
Where's the DB3 EXE?
Under Modules\Darwinbots3 there is a Darwinbots3 solution. At the moment the Darwinbots3 binary is pretty empty, but there is a Bot.Testbed application that is starting to come together.
Coding standards
Basic Standards
Look at the code, and follow by example.
Repository etiquette
- Prefer to post lots of small, atomic changes over large, far-reaching changes. It's easier to integrate for other people, and minimizes the possibility of commit conflicts.
- Keep the repository's code running. Don't commit a change that would break the program, or worse, prevent it from compiling. If you do anyway, fix the problem immediately.
- Be careful what files you submit. If it's a large temporary file you accidentally submitted it will take up repository space for ever and ever, even if you remove it from the repository later.
Unit testing
Unit testing is a way to ensure that a function or section of code works like you think it should. It is immeasurably important for keeping the code robust and bug free. It also makes refactoring much easier. this site is an excellent introduction to Unit Testing for games.
Ideally, you would write the tests first and then "fix" the program to pass those tests. This requires some discipline that I personally don't always have, so I'm not going to strongly enforce this. Aim for this standard anyway. Definitely unit test as many aspects of the code you're working on as possible, even if it's after the fact.
If you want to submit code without tests, it'll probably end up in the trashcan, honestly, when time comes for me to figure out how it's supposed to work (and why it's currently not working).
Release pattern
When a new release is ready, it's given a version number. The format is:
- Darwinbots3 AXXXXX.exe - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable
- Darwinbots3 BXXXXX.exe - A beta release. The XXXXX is the source control revision corresponding to the executable
- Darwinbots3.0.exe - The first feature complete and stable release.
- Darwinbots3.XXX RC1 - A release candidate. The number after RC is the release candidate version. The XXX is the version number (starts at 001, goes to 999).
- Darwinbots3.XXX - The stable release for version XXX.
Note that these files alphabetically sort according to when they are expected to release. This is important.
