http://wiki.darwinbots.com/api.php?action=feedcontributions&feedformat=atom&user=Numsgil 2026-06-17T08:02:30Z User contributions MediaWiki 1.29.0 http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5795 2017-05-06T10:06:40Z

<p>Numsgil: /* Where's the DB3 EXE? */</p> <hr /> <div>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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> 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.<br /> <br /> You will also need to install Python, at least version 3.6. You can [https://www.python.org/downloads/windows/ download Python here].<br /> <br /> === Downloading the dependencies ===<br /> To compile/run the project, you need:<br /> <br /> * 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.<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I usually put it on the root level myself:<br /> <br /> C:\<br /> * \Darwinbots3Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> === Visual Studio solution files ===<br /> 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. <br /> <br /> Rebuilding everything locally can help with debugging across module boundaries, though.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; 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).<br /> <br /> === You have the code, now what? ===<br /> 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.<br /> <br /> === Where's the DB3 EXE? ===<br /> 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.<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5794 2017-05-06T10:05:42Z

<p>Numsgil: /* You have the code, now what? */</p> <hr /> <div>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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> 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.<br /> <br /> You will also need to install Python, at least version 3.6. You can [https://www.python.org/downloads/windows/ download Python here].<br /> <br /> === Downloading the dependencies ===<br /> To compile/run the project, you need:<br /> <br /> * 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.<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I usually put it on the root level myself:<br /> <br /> C:\<br /> * \Darwinbots3Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> === Visual Studio solution files ===<br /> 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. <br /> <br /> Rebuilding everything locally can help with debugging across module boundaries, though.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; 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).<br /> <br /> === You have the code, now what? ===<br /> 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.<br /> <br /> === Where's the DB3 EXE? ===<br /> There isn't one yet. The idea is that it's getting built from the ground up, one module at a time. So there's no central project yet that actually uses all the modules at once. Instead each module is tested and developed individually based on some simple use cases. At the end, there'll be a nice product suite that should combine fairly organically into a final EXE. With any luck, anyway :P<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5793 2017-05-06T09:59:15Z

<p>Numsgil: /* Junk directories and bin folders */</p> <hr /> <div>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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> 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.<br /> <br /> You will also need to install Python, at least version 3.6. You can [https://www.python.org/downloads/windows/ download Python here].<br /> <br /> === Downloading the dependencies ===<br /> To compile/run the project, you need:<br /> <br /> * 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.<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I usually put it on the root level myself:<br /> <br /> C:\<br /> * \Darwinbots3Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> === Visual Studio solution files ===<br /> 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. <br /> <br /> Rebuilding everything locally can help with debugging across module boundaries, though.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; 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).<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have inter-dependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alternatively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> === Where's the DB3 EXE? ===<br /> There isn't one yet. The idea is that it's getting built from the ground up, one module at a time. So there's no central project yet that actually uses all the modules at once. Instead each module is tested and developed individually based on some simple use cases. At the end, there'll be a nice product suite that should combine fairly organically into a final EXE. With any luck, anyway :P<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5792 2017-05-06T09:57:53Z

<p>Numsgil: /* How you should set up your SVN projects and local directories */</p> <hr /> <div>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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> 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.<br /> <br /> You will also need to install Python, at least version 3.6. You can [https://www.python.org/downloads/windows/ download Python here].<br /> <br /> === Downloading the dependencies ===<br /> To compile/run the project, you need:<br /> <br /> * 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.<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I usually put it on the root level myself:<br /> <br /> C:\<br /> * \Darwinbots3Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> === Visual Studio solution files ===<br /> 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. <br /> <br /> Rebuilding everything locally can help with debugging across module boundaries, though.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of sync with each other.<br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have inter-dependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alternatively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> === Where's the DB3 EXE? ===<br /> There isn't one yet. The idea is that it's getting built from the ground up, one module at a time. So there's no central project yet that actually uses all the modules at once. Instead each module is tested and developed individually based on some simple use cases. At the end, there'll be a nice product suite that should combine fairly organically into a final EXE. With any luck, anyway :P<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5791 2017-05-06T09:56:38Z

<p>Numsgil: /* Getting the compiler */</p> <hr /> <div>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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> 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.<br /> <br /> You will also need to install Python, at least version 3.6. You can [https://www.python.org/downloads/windows/ download Python here].<br /> <br /> === Downloading the dependencies ===<br /> To compile/run the project, you need:<br /> <br /> * 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.<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I would suggest something like this just for sanity, though:<br /> <br /> C:\<br /> * \Darwinbots3<br /> ** \Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside a Darwinbots3 folder, but life will probably be easier if it is.<br /> <br /> === Visual Studio solution files ===<br /> 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. <br /> <br /> Rebuilding everything locally can help with debugging across module boundaries, though.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of sync with each other.<br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have inter-dependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alternatively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> === Where's the DB3 EXE? ===<br /> There isn't one yet. The idea is that it's getting built from the ground up, one module at a time. So there's no central project yet that actually uses all the modules at once. Instead each module is tested and developed individually based on some simple use cases. At the end, there'll be a nice product suite that should combine fairly organically into a final EXE. With any luck, anyway :P<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Screen_shots&diff=5723 2015-03-06T17:23:16Z

<p>Numsgil: </p> <hr /> <div>__NOTOC__ <br /> <br /> DarwinBots 2.1 screenshots. The program hasn't really changed graphically in several years ;) Feel free to add interesting screenshots if you have any of newer versions.<br /> <br /> If it looks interesting, [http://wiki.darwinbots.com/w/Main_FTP#Main_Install Download it and check it out!]<br /> <br /> == Typical Simulation ==<br /> [[Image:Fieldcirc.gif|left]] A typical simulation... those yellow guys are Turneria Preservans (called this way because John Turner programmed them and they are kinda ecologist robots) eating the vegetable Alga Minimalis, in green.<br /> <br /> == Zoomed in ==<br /> [[Image:Bigzoom.gif|right]] A zoomed scene from the same simulation. Robots suck energy from each other by shooting &quot;attack particles&quot; to the victims, which, if reached, are forced to shoot them back the white energy particles. That's why you see such a mess of coloured dots. There's a banquet going on there!<br /> <br /> Look at the two yellow bots tied at the centre/bottom of the screen. These are a Turneria and his newborn child. In a few seconds the tie will break and they'll go their own way (notice also that the drawings inside them are identical: it means that no mutations occurred during the duplication process).<br /> <br /> == Graphs ==<br /> [[Image:Graphs.jpg|left]] There are many different graphs you can display to follow the evolution of the simulation and its inhabitants. Just as an example, these are population/cycles, Average DNA mutations/cycles and average sons/ cycles. Obviously divided by species.<br /> <br /> == Other Tools ==<br /> [[Image:Console.jpg|right]] Other tools to play with. The single robot's data (species name, energy, age, offspring, mutations number, and so on), his complete DNA (a program written in a simple interpreted language), a console to debug it easily -just in case you want to program your own. You can even look at the robot's genes activation in real time in a winamp style :)<br /> <br /> == Options Window ==<br /> [[Image:Simopts.jpg|left]] And this is the simulation set-up window. As you can see, there are many options to tinker with.<br /> <br /> Just to mention some of those you can't see: under the General tab, field size and geometry, population control; under Physics, friction, moving and swimming factors, brownian motion; under Costs, the energy costs/benefits ratios; under Mutation rates, a general mutation multiplier; and more: autosaving parameters, database recording, internet organisms sharing.<br /> <br /> == Microscope ==<br /> [[Image:Microscope.gif|right]] Ok, this one has been slightly modified with Paint Shop Pro. Just an edge contour, anyway. It looked so &quot;microscope&quot; this way! But the worms are true multicellular organisms, swimming. They develop from a single egg cell, dividing many times to form the complete body, and tieing all the child cells in a precise shape. Then they go around swimming, eating and reproducing like any good animal should do.<br /> <br /> It took me a week to program them!<br /> <br /> == Excel ==<br /> [[Image:Excel.jpg|left]] This is what you can get by reloading the database files generated by DarwinBots into Excel or in a database software. For example, this scatter graph shows each robot with a point P=(x,y)=(birth cycle, accumulated mutations). For each robot, birth cycle, mutations, dna length and so on have been recorded.<br /> <br /> == Excel Graphed ==<br /> [[Image:Filans.jpg|right]] And these are the same data passed through a simple program which plots the graph using colour to render the points density.<br /> <br /> This means that yellow stands for a higher number of robots falling over the same graph's coordinate.<br /> Notice the little flames detaching upwards from the main strain, representing branches in evolution, suddenly abandoned.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_Page&diff=5722 2015-03-03T20:14:54Z

<p>Numsgil: /* image:bookgreen.jpg News */ Ditching old news items</p> <hr /> <div>__NOTOC__ &lt;!-- disab<br /> 1000<br /> les Table of Contents --&gt;<br /> &lt;!---a main page with style.---&gt;<br /> &lt;center&gt;&lt;!--[[Image:Dblogo1.JPG]][[Image:KnowledgeBook.jpg]]--&gt; [[Image:WikiPage_Banner.png]] &lt;/center&gt;<br /> <br /> &lt;center&gt;Darwinbots is an artificial life simulation. Small critters called &quot;bots&quot; fight each other for food in a physically simulated 2D universe. Successful bots will live to reproduce and, over time, evolve.&lt;/center&gt;<br /> '''&lt;center&gt;Notice: This wiki is locked to edits from users due to spam, sorry for the inconvenience.&lt;/center&gt;'''<br /> <br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #80e080; padding: .5em .5em; margin: 1em; background-color: #f0fff0;&quot;|<br /> <br /> ==[[image:bookgreen.jpg]] &lt;font color=&quot;blue&quot;&gt;News&lt;/font&gt;==<br /> * ''' October 29, 2014: New installer for 2.48.25 released. See [[Main FTP|Downloads]].'''<br /> * ''' August 26, 2014 Version 2.48 released. '''<br /> * ''' July 6, 2014 Version 2.47.03 released. '''<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;New Users Portal&lt;/font&gt;==<br /> *'''[[Main FTP|Downloads and Installation Instructions]]'''<br /> *[[Introduction]] - New to Darwinbots? <br /> *[[Screen shots]]<br /> *[http://forum.darwinbots.com/ The Forum] - Chat sometime.<br /> *[[Your First Simulations]] - Getting to know the program<br /> *[[Robot Tutorial]] - Write your own bots<br /> *[[Sysvars]] - Current system variable information.<br /> *[[Operators]] - Vital parts of robot DNA<br /> *[[IRC]] - Connecting to our IRC channel.<br /> *[[Troubleshooting]] - [[FAQ|Frequently Asked Questions]]<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Reference Manual&lt;/font&gt;==<br /> <br /> *[[Robot DNA]] - Not as complicated as it at first seems.<br /> *[[Concepts]] - General concepts<br /> *[[Simulation Options]] - What do all these sliders mean?<br /> *[[League | Leagues]] - Learn about the leagues that exist.<br /> *[[Evolution Sims]] - The pinnacle of any ALife program.<br /> *[[Technical Details]] - Know *exactly* how something works.<br /> *[[Version History]] - The evolution of Darwinbots itself.<br /> *[[Readme]] Most current read me file<br /> *[[Safemode]] Error Handling / Error Reports<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Other&lt;/font&gt;==<br /> Central link pages that don't directly reflect what is currently in the DB program<br /> <br /> *[[Source Code]] - Where to get it, different versions, and how you can help.<br /> &lt;!--*[[DeBugging]] - Post up bugs and reference materials here.--&gt;<br /> *[[Ideas]] - Interactive work on different ideas. Community projects, that sort of thing.<br /> &lt;!--*[[Whimsical]] - Stories and etcetera. --&gt;<br /> &lt;!--*[[RoundTable]] - DB wikipedians unite in this discussion area. --&gt;<br /> *[[Other Resources]] - Links to resources you might find useful.<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageBottom&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;Wiki Help&lt;/font&gt; ==<br /> *Please see [http://meta.wikipedia.org/wiki/MediaWiki_User's_Guide User's Guide] for Wiki usage&lt;br&gt;<br /> *Help with [http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:How_to_edit_a_page editing pages]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Robot_DNA&diff=5614 2014-09-12T03:43:36Z

<p>Numsgil: </p> <hr /> <div>==Darwinbots 2==<br /> ===How the DNA works===<br /> * [[Genes]]<br /> * [[Execution Flag]]<br /> * The [[Stack]] <br /> * [[Custom labels]] (or variables if you prefer)<br /> * [[Order of actions]]<br /> <br /> === DNA commands===<br /> An overview of each and every DNA [[command]], from sysvars to logical operators.<br /> <br /> * [[Operators | 2.4 Operators]]<br /> <br /> * [[Pre2.4]]<br /> <br /> ==Darwinbots 3==<br /> * [[Differences from DB2]]<br /> <br /> ===The Different Parts===<br /> * [[Base Pair]]s<br /> * [[Codule]]s<br /> * [[Chromosome]]s<br /> * [[Meta Tag]]s<br /> * [[DNA]]<br /> <br /> ===How The DNA Works===<br /> * [[DNA Execution]]<br /> * [[Boolean Stack]]<br /> * [[Integer Stack]]<br /> * [[Custom Variable]]s<br /> * [[System Variable]]s<br /> * [[Mutation]]s</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5540 2014-06-28T23:22:25Z

<p>Numsgil: 2014 update</p> <hr /> <div>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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2013 (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.<br /> <br /> === Downloading the dependencies ===<br /> To compile/run the project, you need:<br /> <br /> * 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.<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I would suggest something like this just for sanity, though:<br /> <br /> C:\<br /> * \Darwinbots3<br /> ** \Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside a Darwinbots3 folder, but life will probably be easier if it is.<br /> <br /> === Visual Studio solution files ===<br /> 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. <br /> <br /> Rebuilding everything locally can help with debugging across module boundaries, though.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of sync with each other.<br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have inter-dependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alternatively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> === Where's the DB3 EXE? ===<br /> There isn't one yet. The idea is that it's getting built from the ground up, one module at a time. So there's no central project yet that actually uses all the modules at once. Instead each module is tested and developed individually based on some simple use cases. At the end, there'll be a nice product suite that should combine fairly organically into a final EXE. With any luck, anyway :P<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_Page&diff=5324 2013-08-05T07:46:42Z

<p>Numsgil: Less bleh intro sentence. Did you know whatever you write here is going to get copied by other sites?</p> <hr /> <div>__NOTOC__ &lt;!-- disab<br /> 1000<br /> les Table of Contents --&gt;<br /> &lt;!---a main page with style.---&gt;<br /> &lt;center&gt;&lt;!--[[Image:Dblogo1.JPG]][[Image:KnowledgeBook.jpg]]--&gt; [[Image:WikiPage_Banner.png]] &lt;/center&gt;<br /> <br /> &lt;center&gt;Darwinbots is an artificial life simulation. Small critters called &quot;bots&quot; fight each other for food in a physically simulated 2D universe. Successful bots will live to reproduce and, over time, evolve.&lt;/center&gt;<br /> '''&lt;center&gt;Notice: This wiki is locked to edits from users due to spam, sorry for the inconvenience.&lt;/center&gt;'''<br /> <br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #80e080; padding: .5em .5em; margin: 1em; background-color: #f0fff0;&quot;|<br /> <br /> ==[[image:bookgreen.jpg]] &lt;font color=&quot;blue&quot;&gt;News&lt;/font&gt;==<br /> * ''' June 11, 2013: Version 2.45.03 released. New installer for 2.45.03 released. Tools for version 2.45.03 released. See [[Main FTP|Downloads]].'''<br /> * ''' August 21, 2012: Version 2.45.02 released. See [[Main FTP|Downloads]].'''<br /> * ''' April 29, 2011: New installer for 2.45.01 released. See [[Main FTP|Downloads]].'''<br /> * ''' August 31, 2010: Version 2.45.01 released. See [[Main FTP|Downloads]].'''<br /> * ''' August 10, 2010: Version 2.44.06 released. See [[Main FTP|Downloads]].'''<br /> * ''' July 22, 2010: Alternative internet mode working well. See [[Internet Mode Fix]].'''<br /> * ''' July 22, 2010: IRC server up and running, come join us. See [[IRC]].'''<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;New Users Portal&lt;/font&gt;==<br /> *'''[[Main FTP|Downloads and Installation Instructions]]'''<br /> *[[Introduction]] - New to Darwinbots? <br /> *[[Screen shots]]<br /> *[http://forum.darwinbots.com/ The Forum] - Chat sometime.<br /> *[[Your First Simulations]] - Getting to know the program<br /> *[[Robot Tutorial]] - Write your own bots<br /> *[[Sysvars]] - Current system variable information.<br /> *[[IRC]] - Connecting to our IRC channel.<br /> *[[Troubleshooting]] - [[FAQ|Frequently Asked Questions]]<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Reference Manual&lt;/font&gt;==<br /> <br /> *[[Robot DNA]] - Not as complicated as it at first seems.<br /> *[[Concepts]] - General concepts<br /> *[[Simulation Options]] - What do all these sliders mean?<br /> *[[League | Leagues]] - Learn about the leagues that exist.<br /> *[[Evolution Sims]] - The pinnacle of any ALife program.<br /> *[[Technical Details]] - Know *exactly* how something works.<br /> *[[Version History]] - The evolution of Darwinbots itself.<br /> *[[Readme]] Most current read me file<br /> *[[Safemode]] Error Handling / Error Reports<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Other&lt;/font&gt;==<br /> Central link pages that don't directly reflect what is currently in the DB program<br /> <br /> *[[Source Code]] - Where to get it, different versions, and how you can help.<br /> &lt;!--*[[DeBugging]] - Post up bugs and reference materials here.--&gt;<br /> *[[Ideas]] - Interactive work on different ideas. Community projects, that sort of thing.<br /> &lt;!--*[[Whimsical]] - Stories and etcetera. --&gt;<br /> &lt;!--*[[RoundTable]] - DB wikipedians unite in this discussion area. --&gt;<br /> *[[Other Resources]] - Links to resources you might find useful.<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageBottom&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;Wiki Help&lt;/font&gt; ==<br /> *Please see [http://meta.wikipedia.org/wiki/MediaWiki_User's_Guide User's Guide] for Wiki usage&lt;br&gt;<br /> *Help with [http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:How_to_edit_a_page editing pages]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=User:Numsgil&diff=5257 2013-02-02T20:10:12Z

<p>Numsgil: Blanked the page</p> <hr /> <div></div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5227 2011-12-28T18:50:46Z

<p>Numsgil: /* Downloading the dependencies */</p> <hr /> <div>Check the following link for a real-time discussion of features and progress: [[IRC]]<br /> <br /> 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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2010 (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. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/download/en/details.aspx?id=39 XNA 3.1] - A game library released by Microsoft which is used for graphics.<br /> <br /> To distribute the project (which you probably don't care about), you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * [http://madebits.com/netz/index.php NETz] - Allows packing of the exe to make it smaller.<br /> * (TODO: Double check what needs to be installed .NET wise and XNA wise (redistributables)).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I would suggest something like this just for sanity, though:<br /> <br /> C:\<br /> * \Darwinbots3<br /> ** \Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but life will probably be easier if it is.<br /> <br /> === Visual Studio solution files ===<br /> 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. Note that you shouldn't need to do this very often.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of date. <br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alteratively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> === Where's the DB3 EXE? ===<br /> There isn't one yet. The idea is that it's getting built from the ground up, one module at a time. So there's no central project yet that actually uses all the modules at once. Instead each module is tested and developed individually based on some simple use cases. At the end, there'll be a nice product suite that should combine fairly organically into a final EXE. With any luck, anyway :P<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://forum.darwinbots.com/index.php/board,62.0.html in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks|Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5226 2011-12-28T00:32:12Z

<p>Numsgil: </p> <hr /> <div>Check the following link for a real-time discussion of features and progress: [[IRC]]<br /> <br /> 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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2010 (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. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/download/en/details.aspx?id=15300 XNA 3.0] - A game library released by Microsoft which is used for graphics.<br /> <br /> To distribute the project (which you probably don't care about), you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * [http://madebits.com/netz/index.php NETz] - Allows packing of the exe to make it smaller.<br /> * (TODO: Double check what needs to be installed .NET wise and XNA wise (redistributables)).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I would suggest something like this just for sanity, though:<br /> <br /> C:\<br /> * \Darwinbots3<br /> ** \Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but life will probably be easier if it is.<br /> <br /> === Visual Studio solution files ===<br /> 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. Note that you shouldn't need to do this very often.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of date. <br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alteratively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> === Where's the DB3 EXE? ===<br /> There isn't one yet. The idea is that it's getting built from the ground up, one module at a time. So there's no central project yet that actually uses all the modules at once. Instead each module is tested and developed individually based on some simple use cases. At the end, there'll be a nice product suite that should combine fairly organically into a final EXE. With any luck, anyway :P<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://forum.darwinbots.com/index.php/board,62.0.html in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks|Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5225 2011-12-22T02:08:37Z

<p>Numsgil: </p> <hr /> <div>Check the following link for a real-time discussion of features and progress: [[IRC]]<br /> <br /> 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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2010 (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. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/download/en/details.aspx?id=23714 XNA 4.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project (which you probably don't care about), you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * [http://madebits.com/netz/index.php NETz] - Allows packing of the exe to make it smaller.<br /> * (TODO: Double check what needs to be installed .NET wise and XNA wise (redistributables)).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> You can dump the source whereever you want. Everything is set up with relative paths. I would suggest something like this just for sanity, though:<br /> <br /> C:\<br /> * \Darwinbots3<br /> ** \Source &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but life will probably be easier if it is.<br /> <br /> === Visual Studio solution files ===<br /> 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. Note that you shouldn't need to do this very often.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of date. <br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alteratively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> === Where's the DB3 EXE? ===<br /> There isn't one yet. The idea is that it's getting built from the ground up, one module at a time. So there's no central project yet that actually uses all the modules at once. Instead each module is tested and developed individually based on some simple use cases. At the end, there'll be a nice product suite that should combine fairly organically into a final EXE. With any luck, anyway :P<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> Look at the code, and follow by example.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> 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).<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://forum.darwinbots.com/index.php/board,62.0.html in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks|Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=5209 2011-10-20T00:25:32Z

<p>Numsgil: </p> <hr /> <div>Check the following link for a real-time discussion of features and progress: [[IRC]]<br /> <br /> 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/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project (which you probably don't care about), you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * [http://madebits.com/netz/index.php NETz] - Allows packing of the exe to make it smaller.<br /> * (TODO: Double check what needs to be installed .NET wise and XNA wise (redistributables)).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of date (if anyone can think of a better way to handle this sort of thing, I'm all ears). <br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alteratively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture (Out of date) ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://forum.darwinbots.com/index.php/board,62.0.html in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks|Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_Page&diff=5032 2009-12-20T01:02:36Z

<p>Numsgil: </p> <hr /> <div>__NOTOC__ &lt;!-- disab<br /> 1000<br /> les Table of Contents --&gt;<br /> &lt;!---a main page with style.---&gt;<br /> &lt;center&gt;&lt;!--[[Image:Dblogo1.JPG]][[Image:KnowledgeBook.jpg]]--&gt; [[Image:WikiPage_Banner.png]] &lt;/center&gt;<br /> <br /> &lt;center&gt;Darwinbots is an Artificial Life simulator that merges the gameplay of C-Robots type arena combat with adaptive asexual population dynamics.&lt;/center&gt;<br /> <br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #80e080; padding: .5em .5em; margin: 1em; background-color: #f0fff0;&quot;|<br /> <br /> ==[[image:bookgreen.jpg]] &lt;font color=&quot;blue&quot;&gt;News&lt;/font&gt;==<br /> * ''' December 19, 2009: Version 2.44.04 released. See [[Main FTP|Downloads]].'''<br /> * ''' November 29, 2008: Version 2.44.1 released. See [[Main FTP|Downloads]].'''<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;New Users Portal&lt;/font&gt;==<br /> *'''[[Main FTP|Downloads and Installation Instructions]]'''<br /> *[[Introduction]] - New to Darwinbots? <br /> *[[Screen shots]]<br /> *[http://forum.darwinbots.com The Forum] - Chat sometime.<br /> *[[Your First Simulations]] - Getting to know the program<br /> *[[Robot Tutorial]] - Write your own bots<br /> *[[Sysvars]] - Current system variable information.<br /> *[[Troubleshooting]] - [[FAQ|Frequently Asked Questions]]<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Reference Manual&lt;/font&gt;==<br /> <br /> *[[Robot DNA]] - Not as complicated as it at first seems.<br /> *[[Concepts]] - General concepts<br /> *[[Simulation Options]] - What do all these sliders mean?<br /> *[[League | Leagues]] - Learn about the leagues that exist.<br /> *[[Evolution Sims]] - The pinacle of any ALife program.<br /> *[[Technical Details]] - Know *exactly* how something works.<br /> *[[Version History]] - The evolution of Darwinbots itself.<br /> <br /> *[[Readme]] Most current read me file<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Other&lt;/font&gt;==<br /> Central link pages that don't directly reflect what is currently in the DB program<br /> <br /> *[[Source Code]] - Where to get it, different versions, and how you can help.<br /> &lt;!--*[[DeBugging]] - Post up bugs and reference materials here.--&gt;<br /> *[[Ideas]] - Interactive work on different ideas. Community projects, that sort of thing.<br /> &lt;!--*[[Whimsical]] - Stories and etcetera. --&gt;<br /> &lt;!--*[[RoundTable]] - DB wikipedians unite in this discussion area. --&gt;<br /> *[[Other Resources]] - Links to resources you might find useful.<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageBottom&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;Wiki Help&lt;/font&gt; ==<br /> *Please see [http://meta.wikipedia.org/wiki/MediaWiki_User's_Guide User's Guide] for Wiki usage&lt;br&gt;<br /> *Help with [http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:How_to_edit_a_page editing pages]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_FTP&diff=5031 2009-12-20T01:01:20Z

<p>Numsgil: </p> <hr /> <div>== '''Main Install''' ==<br /> <br /> Run the main install for [http://www.darwinbots.com/FTP/Darwin21.zip DarwinBots 2.1] We are working on an installer for the latest version below, but at the moment, this is the only version for which an installer exists. It creates some directories and installs some runtimes and thus '''must be installed''' before you can use any of the newer versions below. See the [[Installation_Instructions|installation instructions]]. The version installed with this main install works, but it is ancient (several years old) so you will want to immediatly download one of the newer releases below.<br /> <br /> == Recent Releases ==<br /> <br /> To update to the latest release, simply copy the file(s) included in a new release into your install location (by default c:\Program File\DarwinbotsII\). Again, '''the new file(s) MUST be placed into your install location'''. Usually, new releases consist of only the DarwinBots executable. If other files are included in a release, you should say 'yes' to all overwrites. Then simply run the new executable instead of the executable that came with the main install. <br /> <br /> === 2.43.1L ===<br /> [http://www.darwinbots.com/FTP/Darwin2.43.1L.zip 2.43.1L] is the current recommended, and latest stable version of DarwinBots. <br /> <br /> === 2.44.04 ===<br /> <br /> [http://www.darwinbots.com/FTP/Darwin2.44.04.exe Version 2.44.04] is the latest &quot;in progress&quot; version. There might have be some bugs that 2.43.1L does not. If you encounter a bug, try to reproduce what the problem is (does it crash after loading error.sim every time?). Then go to the [http://forum.darwinbots.com forum] and file a bug report.<br /> <br /> ==Installing==<br /> <br /> === Installing DarwinBots under Linux ===<br /> <br /> DarwinBots can run under Linux using the wine Windows emulator, although the simulation speed may be slower and bugs and crashes may happen. Following these steps will usually make it work:<br /> <br /> #Install the Wine package.<br /> #Get the libraries MSVBVM60.dll, scrrun.dll and wininet.dll from reliable sources. If DB crashes when you try to run it, you'll problably need a few more dlls.<br /> #Place those files at the folder /(username)/.wine/drive_c/windows/system32. <br /> #Open a terminal window and go to the system32 folder.<br /> #Write &quot;wine regsvr32 scrrun.dll&quot;. This will register the dll in the Wine Windows registry. If this doesn't work, try &quot;regedit scrrun.dll&quot;.<br /> #Now, do &quot;winecfg&quot;, select &quot;wininet&quot; at Libraries and specify it to be run first as native.<br /> #Get the DB installer, place the setup.exe file somewhere in the drive_c folder.<br /> #Go to that folder and type wine setup.exe. This will install the old DB version and some needed files. Then you can drop the newer executables and run them with wine. If you aren't comfortable using the terminal, you can load a wine file explorer running &quot;winefile&quot;. You can also configure how wine emulates Windows for the DB executables with &quot;winecfg&quot;, although the Windows 2000 default setting seems to work well.<br /> <br /> If you are on a Gnome desktop, avoid using Gedit to edit the code of your robots, as it will enter incompatible line breaks.<br /> <br /> === Step by Step Darwinbots Installation Instructions (Windows) ===<br /> <br /> # Go to [[Main_FTP | here]] and download Darwinbots 2.1.<br /> # Unzip it, using a program like 7-zip or Windows XPs Extract All function (Rightclick, select Extract All, Press next until it starts unzipping, Select Show Extracted Files, Press Finish. A folder with the setup file in it should show)<br /> # Run setup.<br /> #* Press Yes.<br /> #* Press Next twice.<br /> #* Press install.<br /> #* Press finish.<br /> # Download the latest release. At the time of writing this is 2.43.<br /> # Unzip it.<br /> # Copy the exe file. Paste it in your Darwinbots Install directory (C:\Program Files\DarwinbotsII)<br /> # To run Darwinbots, run the exe you pasted into your Darwinbots directory.<br /> <br /> === Upgrading ===<br /> <br /> The Darwinbots community is quite active, and major releases are made public generally every month. Each new version contains substantial improvements. Don't cheat your Darwinbots experience! Be sure to have the latest version installed.<br /> <br /> Upgrading Darwinbots is quite easy, as all you need is the new sysvars file and executable. New patches are listed here in chronological order, so newer releases are generally listed last for a section.<br /> <br /> Newer releases are, obviously, of higher numbers. Thus 2.36 comes after 2.35 but before 2.4.<br /> <br /> After downloading the zip of the new version, unzip it to your Darwinbots folder. (typically C:\Program Files\DarwinBotsII) Yes, you must do this manually. The developers are far too busy with real programming to figure out how to implement an autopatcher.<br /> <br /> When you unzip your new version of DarwinBots, &quot;sysvars2.21.txt&quot; will automatically overwrite the existing version if you have one. This is okay since the '''sysvars files are backward compatible'''.<br /> <br /> == Bots ==<br /> Note: The robots that come with the main 2.1 install above will run in modern versions, but they are going to act a little stupid. They may have a hard time even surviving. '''Strongly consider downloading more modern bots from the [http://forum.darwinbots.com/index.php?showforum=13 bestiary].''' [http://forum.darwinbots.com/index.php?act=ST&amp;f=24&amp;t=157&amp;st=0#entry240895 Animal Minimalis] is a good start, and is used in the [[Robot Tutorial]]s. Just copy the text into a plain old .txt file, and put the file into your robots directory.<br /> <br /> == Tutorials ==<br /> <br /> The [http://www.darwinbots.com/FTP/DarwinTutorial1+2.zip Darwinbots bot writing tutorial by PY] is a little old but a very good primer to learning how the DNA works. You can also check out the [[Robot Tutorial]]<br /> <br /> == Regional settings ==<br /> Darwinbots is pretty stupid and assumes that you're using the American decimal system, where numbers look like this: 123,456.789 (123 thousand...). If you don't live in America, and you're used to numbers looking like this: 123.456,789, Darwinbots will run, but there will be a few random errors in the user interface. To fix this, go to your Windows Control Panel-&gt;Regional and Language Options-&gt; and make sure the number blank says &quot;123,456,789.00&quot;. If it doesn't, change your region to one that does (such as English(United States)).<br /> <br /> == Final Note ==<br /> New versions almost always have bugs. The first week or so after a new release is filled with the programmers releasing minor updates almost daily. These updates are noted by the suffix numbers of the version. Thus, 2.37.0 was the initial release of 2.37 2.37.4 is the 4th bug fix version released.<br /> <br /> We know it's a pain to download a new patch almost every day. But it's only through community bug testing that the bugs can be isolated at all.<br /> <br /> Anything with the same first 3 digits (that is, all versions of 2.XX) have the same ''features'' and differ only in minor bug fixing.<br /> <br /> == See Also ==<br /> <br /> * [[Previous Versions]]<br /> * [[Source code download]]<br /> * [[Troubleshooting]]<br /> Return to [[Main Page]]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_FTP&diff=4967 2009-12-10T05:11:11Z

<p>Numsgil: </p> <hr /> <div>__NOTOC__&lt;!-- __NOTOC__ disables Table of Contents (short pages may not require it--&gt;<br /> == Main Install ==<br /> <br /> Run the main install for [http://www.darwinbots.com/FTP/Darwin21.zip DarwinBots 2.1] We are working on an installer for the latest version below, but at the moment, this is the only version for which an installer exists. It creates some directories and installs some runtimes and thus '''must be installed''' before you can use any of the newer versions below. See the [[Installation_Instructions|installation instructions]]. The version installed with this main install works, but it is ancient (several years old) so you will want to immediatly download one of the newer releases below.<br /> <br /> == Recent Releases ==<br /> <br /> To update to the latest release, simply copy the file(s) included in a new release into your install location (by default c:\Program File\DarwinbotsII\). Again, '''the new file(s) MUST be placed into your install location'''. Usually, new releases consist of only the DarwinBots executable. If other files are included in a release, you should say 'yes' to all overwrites. Then simply run the new executable instead of the executable that came with the main install. <br /> <br /> === 2.43.1L ===<br /> [http://www.darwinbots.com/FTP/Darwin2.43.1L.zip 2.43.1L] is the current recommended, and latest stable version of DarwinBots. <br /> <br /> === 2.44.03 ===<br /> <br /> [http://www.darwinbots.com/FTP/Darwin2.44.03.exe Version 2.44.03] is the latest &quot;in progress&quot; version. There might have be some bugs that 2.43.1L does not. If you encounter a bug, try to reproduce what the problem is (does it crash after loading error.sim every time?). Then go to the [http://forum.darwinbots.com forum] and file a bug report.<br /> <br /> == Bots ==<br /> Note: The robots that come with the main 2.1 install above will run in modern versions, but they are going to act a little stupid. They may have a hard time even surviving. '''Strongly consider downloading more modern bots from the [http://forum.darwinbots.com/index.php?showforum=13 bestiary].''' [http://forum.darwinbots.com/index.php?act=ST&amp;f=24&amp;t=157&amp;st=0#entry240895 Animal Minimalis] is a good start, and is used in the [[Robot Tutorial]]s. Just copy the text into a plain old .txt file, and put the file into your robots directory.<br /> <br /> == Tutorials ==<br /> <br /> The [http://www.darwinbots.com/FTP/DarwinTutorial1+2.zip Darwinbots bot writing tutorial by PY] is a little old but a very good primer to learning how the DNA works. You can also check out the [[Robot Tutorial]]<br /> <br /> == See Also ==<br /> <br /> * [[Previous Versions]]<br /> * [[Source code download]]<br /> <br /> == Vista and Windows 7 ==<br /> If you are running Vista or Windows 7, you will need to '''run the installation as an Administrator'''. Right-click on the Darwinbots install (or a shortcut to it) and choose &quot;Run as Administrator&quot;. This can sometimes be a problem even if you have UAC disabled.<br /> <br /> == Windows 95 Trouble ==<br /> There is a report that Darwinbots might cause problems if you are running Windows 95. If you experience any such problems, please post them to the [http://forum.darwinbots.com forum].<br /> <br /> Return to [[Main Page]]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_Page&diff=4966 2009-12-10T05:10:42Z

<p>Numsgil: /* image:bookgreen.jpg &lt;font color=&quot;blue&quot;&gt;News&lt;/font&gt; */</p> <hr /> <div>__NOTOC__ &lt;!-- disab<br /> 1000<br /> les Table of Contents --&gt;<br /> &lt;!---a main page with style.---&gt;<br /> &lt;center&gt;&lt;!--[[Image:Dblogo1.JPG]][[Image:KnowledgeBook.jpg]]--&gt; [[Image:MainpageBanner.jpg]] &lt;/center&gt;<br /> <br /> &lt;center&gt;Darwinbots is an Artificial Life simulator that merges the gameplay of C-Robots type arena combat with adaptive asexual population dynamics.&lt;/center&gt;<br /> <br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #80e080; padding: .5em .5em; margin: 1em; background-color: #f0fff0;&quot;|<br /> <br /> ==[[image:bookgreen.jpg]] &lt;font color=&quot;blue&quot;&gt;News&lt;/font&gt;==<br /> * ''' November 29, 2009: Version 2.44.03 released. See [[Main FTP|Downloads]].'''<br /> * ''' November 29, 2008: Version 2.44.1 released. See [[Main FTP|Downloads]].'''<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;New Users Portal&lt;/font&gt;==<br /> *'''[[Main FTP|Downloads]]'''<br /> *[[Introduction]] - New to Darwinbots? <br /> *[[Screen shots]]<br /> *[[Installation Instructions]] - Installing later versions.<br /> *[http://forum.darwinbots.com The Forum] - Chat sometime.<br /> *[[Your First Simulations]] - Getting to know the program<br /> *[[Robot Tutorial]] - Write your own bots<br /> *[[Sysvars]] - Current system variable information.<br /> *[[Troubleshooting]] - [[FAQ|Frequently Asked Questions]]<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Reference Manual&lt;/font&gt;==<br /> <br /> *[[Robot DNA]] - Not as complicated as it at first seems.<br /> *[[Concepts]] - General concepts<br /> *[[Simulation Options]] - What do all these sliders mean?<br /> *[[League | Leagues]] - Learn about the leagues that exist.<br /> *[[Evolution Sims]] - The pinacle of any ALife program.<br /> *[[Technical Details]] - Know *exactly* how something works.<br /> *[[Version History]] - The evolution of Darwinbots itself.<br /> <br /> *[[Readme]] Most current read me file<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Other&lt;/font&gt;==<br /> Central link pages that don't directly reflect what is currently in the DB program<br /> <br /> *[[Source Code]] - Where to get it, different versions, and how you can help.<br /> &lt;!--*[[DeBugging]] - Post up bugs and reference materials here.--&gt;<br /> *[[Ideas]] - Interactive work on different ideas. Community projects, that sort of thing.<br /> &lt;!--*[[Whimsical]] - Stories and etcetera. --&gt;<br /> &lt;!--*[[RoundTable]] - DB wikipedians unite in this discussion area. --&gt;<br /> *[[Other Resources]] - Links to resources you might find useful.<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageBottom&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;Wiki Help&lt;/font&gt; ==<br /> *Please see [http://meta.wikipedia.org/wiki/MediaWiki_User's_Guide User's Guide] for Wiki usage&lt;br&gt;<br /> *Help with [http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:How_to_edit_a_page editing pages]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_Page&diff=4963 2009-11-30T03:33:11Z

<p>Numsgil: /* image:bookgreen.jpg &lt;font color=&quot;blue&quot;&gt;News&lt;/font&gt; */</p> <hr /> <div>__NOTOC__ &lt;!-- disab<br /> 1000<br /> les Table of Contents --&gt;<br /> &lt;!---a main page with style.---&gt;<br /> &lt;center&gt;&lt;!--[[Image:Dblogo1.JPG]][[Image:KnowledgeBook.jpg]]--&gt; [[Image:MainpageBanner.jpg]] &lt;/center&gt;<br /> <br /> &lt;center&gt;Darwinbots is an Artificial Life simulator that merges the gameplay of C-Robots type arena combat with adaptive asexual population dynamics.&lt;/center&gt;<br /> <br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #80e080; padding: .5em .5em; margin: 1em; background-color: #f0fff0;&quot;|<br /> <br /> ==[[image:bookgreen.jpg]] &lt;font color=&quot;blue&quot;&gt;News&lt;/font&gt;==<br /> * ''' November 29, 2009: Version 2.44.02 released. See [[Main FTP|Downloads]].'''<br /> * ''' November 29, 2008: Version 2.44.1 released. See [[Main FTP|Downloads]].'''<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;New Users Portal&lt;/font&gt;==<br /> *'''[[Main FTP|Downloads]]'''<br /> *[[Introduction]] - New to Darwinbots? <br /> *[[Screen shots]]<br /> *[[Installation Instructions]] - Installing later versions.<br /> *[http://forum.darwinbots.com The Forum] - Chat sometime.<br /> *[[Your First Simulations]] - Getting to know the program<br /> *[[Robot Tutorial]] - Write your own bots<br /> *[[Sysvars]] - Current system variable information.<br /> *[[Troubleshooting]] - [[FAQ|Frequently Asked Questions]]<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageLeft&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Reference Manual&lt;/font&gt;==<br /> <br /> *[[Robot DNA]] - Not as complicated as it at first seems.<br /> *[[Concepts]] - General concepts<br /> *[[Simulation Options]] - What do all these sliders mean?<br /> *[[League | Leagues]] - Learn about the leagues that exist.<br /> *[[Evolution Sims]] - The pinacle of any ALife program.<br /> *[[Technical Details]] - Know *exactly* how something works.<br /> *[[Version History]] - The evolution of Darwinbots itself.<br /> <br /> *[[Readme]] Most current read me file<br /> |width=&quot;50%&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #ffa2a2; padding: .5em .5em; margin: 1em; background-color: #fff3f3;&quot;|<br /> <br /> ==[[image:bookred.jpg]] &lt;font color=&quot;blue&quot;&gt;Other&lt;/font&gt;==<br /> Central link pages that don't directly reflect what is currently in the DB program<br /> <br /> *[[Source Code]] - Where to get it, different versions, and how you can help.<br /> &lt;!--*[[DeBugging]] - Post up bugs and reference materials here.--&gt;<br /> *[[Ideas]] - Interactive work on different ideas. Community projects, that sort of thing.<br /> &lt;!--*[[Whimsical]] - Stories and etcetera. --&gt;<br /> &lt;!--*[[RoundTable]] - DB wikipedians unite in this discussion area. --&gt;<br /> *[[Other Resources]] - Links to resources you might find useful.<br /> |}<br /> <br /> {| width=&quot;100%&quot; style=&quot;background: transparent;&quot;<br /> |class=&quot;MainPageBottom&quot; width=&quot;50%&quot; rowspan=&quot;2&quot; valign=&quot;top&quot; style=&quot;border: 1px solid #a0a0ff; padding: .5em .5em; margin: 1em; background-color: #f0f0ff;&quot;|<br /> <br /> ==[[image:bookblue.jpg]] &lt;font color=&quot;blue&quot;&gt;Wiki Help&lt;/font&gt; ==<br /> *Please see [http://meta.wikipedia.org/wiki/MediaWiki_User's_Guide User's Guide] for Wiki usage&lt;br&gt;<br /> *Help with [http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:How_to_edit_a_page editing pages]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_FTP&diff=4962 2009-11-30T03:32:25Z

<p>Numsgil: </p> <hr /> <div>__NOTOC__&lt;!-- __NOTOC__ disables Table of Contents (short pages may not require it--&gt;<br /> == Main Install ==<br /> <br /> Run the main install for [http://www.darwinbots.com/FTP/Darwin21.zip DarwinBots 2.1] We are working on an installer for the latest version below, but at the moment, this is the only version for which an installer exists. It creates some directories and installs some runtimes and thus '''must be installed''' before you can use any of the newer versions below. See the [[Installation_Instructions|installation instructions]]. The version installed with this main install works, but it is ancient (several years old) so you will want to immediatly download one of the newer releases below.<br /> <br /> == Recent Releases ==<br /> <br /> To update to the latest release, simply copy the file(s) included in a new release into your install location (by default c:\Program File\DarwinbotsII\). Again, '''the new file(s) MUST be placed into your install location'''. Usually, new releases consist of only the DarwinBots executable. If other files are included in a release, you should say 'yes' to all overwrites. Then simply run the new executable instead of the executable that came with the main install. <br /> <br /> === 2.43.1L ===<br /> [http://www.darwinbots.com/FTP/Darwin2.43.1L.zip 2.43.1L] is the current recommended, and latest stable version of DarwinBots. <br /> <br /> === 2.44.02 ===<br /> <br /> [http://www.darwinbots.com/FTP/Darwin2.44.02.exe Version 2.44.1] is the latest &quot;in progress&quot; version. There might have be some bugs that 2.43.1L does not. If you encounter a bug, try to reproduce what the problem is (does it crash after loading error.sim every time?). Then go to the [http://forum.darwinbots.com forum] and file a bug report.<br /> <br /> == Bots ==<br /> Note: The robots that come with the main 2.1 install above will run in modern versions, but they are going to act a little stupid. They may have a hard time even surviving. '''Strongly consider downloading more modern bots from the [http://forum.darwinbots.com/index.php?showforum=13 bestiary].''' [http://forum.darwinbots.com/index.php?act=ST&amp;f=24&amp;t=157&amp;st=0#entry240895 Animal Minimalis] is a good start, and is used in the [[Robot Tutorial]]s. Just copy the text into a plain old .txt file, and put the file into your robots directory.<br /> <br /> == Tutorials ==<br /> <br /> The [http://www.darwinbots.com/FTP/DarwinTutorial1+2.zip Darwinbots bot writing tutorial by PY] is a little old but a very good primer to learning how the DNA works. You can also check out the [[Robot Tutorial]]<br /> <br /> == See Also ==<br /> <br /> * [[Previous Versions]]<br /> * [[Source code download]]<br /> <br /> == Vista and Windows 7 ==<br /> If you are running Vista or Windows 7, you will need to '''run the installation as an Administrator'''. Right-click on the Darwinbots install (or a shortcut to it) and choose &quot;Run as Administrator&quot;. This can sometimes be a problem even if you have UAC disabled.<br /> <br /> == Windows 95 Trouble ==<br /> There is a report that Darwinbots might cause problems if you are running Windows 95. If you experience any such problems, please post them to the [http://forum.darwinbots.com forum].<br /> <br /> Return to [[Main Page]]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4960 2009-11-16T06:11:08Z

<p>Numsgil: /* Downloading the dependencies */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * [http://madebits.com/netz/index.php NETz] - Allows packing of the exe to make it smaller.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of date (if anyone can think of a better way to handle this sort of thing, I'm all ears). <br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alteratively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture (Out of date) ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks|Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4959 2009-11-05T17:55:20Z

<p>Numsgil: /* You have the code, now what? */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of date (if anyone can think of a better way to handle this sort of thing, I'm all ears). <br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, the release libraries are on the repository so you shouldn't need to compile all the projects first time. You can just open one up randomly and compile it and it'll work. Alteratively, in the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in.<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture (Out of date) ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks|Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4958 2009-11-05T17:54:03Z

<p>Numsgil: /* Junk directories and bin folders */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder. Only release binaries are on the repository, and are what projects use when they want to import another (for instance, the release build of UnitTestSharp is used for the unit testing projects). Note that this can cause weird problems if you build a project in debug mode and not in release mode, and then submit code changes to the repository, since the binary and source code will be out of date (if anyone can think of a better way to handle this sort of thing, I'm all ears). <br /> <br /> Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture (Out of date) ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks|Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Troubleshooting&diff=4957 2009-11-03T02:25:15Z

<p>Numsgil: /* Run-time error 713 on Windows 7 */</p> <hr /> <div>== My program crashes 10 seconds after starting a sim ==<br /> <br /> Sounds to me like you have an old settings file. From 2.1 maybe?<br /> <br /> Well, let's see what Purple Youko has to say about that!<br /> <br /> &quot;It has been frequently mentioned lately that the default settings file is boring. Let's face it, in today's world of DarwinBots, T-Preservans is nothing to write home about. In his day he wasn't bad but now we need something fresh that actually survives.<br /> <br /> Also the default value for veggie feeding that you used in older versions (10,000) doesn't work too well in 2.36. It used to represent the energy level for the whole sim but now it just directly controls the veggie feed rate.<br /> <br /> 10,000 energy per cycle!<br /> <br /> No wonder their eyes pop out!<br /> <br /> Set it to 30. Makes more sense that way. That will be the default value for F1 and F2 leagues from now on<br /> <br /> Anyway, without more ado, here is a nice new settings file that uses Hunter 2.2 as the default robot. He survives, grows and fights pretty well but he is no longer top bot so it shouldn't be too discouraging for newbies.&quot; -Purple Youko<br /> <br /> If you don't have Hunter 2.2 then please go and download him from [http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=82&amp;st=0&amp;#entry102242 here in the beatiary]. Now save his file into your DarwinBotsII/robots folder and off you go.<br /> <br /> === Settings file ===<br /> <br /> The easiest way is to download it from [http://s9.invisionfree.com/DarwinBots_Forum/index.php?act=Attach&amp;type=post&amp;id=404809 here], but some of you have weird internet and can't download. Shame, shame. So the below is an exact transcription (yep, it's just a text file). Save it as default.set in you settings directory. If you're in post 2.4, you'll probably need to load this into your sim using the &quot;load settings&quot; button.<br /> <br /> '''NOTE''': If you download the file from the link above ...&lt;br&gt;<br /> the path in line 8 will be: '''&quot;Z:\DB Backup\DarwinBotsII\Robots&quot;'''.&lt;br&gt;<br /> You need to alter that path to point to the folder where you have installed DarwinBotsII.&lt;br&gt;<br /> If you have installed DarwinBotsII to a location other than &quot;C:\Program Files\DarwinBotsII\&quot; ...&lt;br&gt; <br /> change that path in the '''default.set''' file (line 8 in the following)<br /> to ensure the program will be able to locate your robots.&lt;br&gt;<br /> (I believe if you make it '''&quot;&amp;#\Robots&quot;''' it will work regardless of where you installed DBII as long as your Settings folder&lt;br&gt;<br /> is located in the same directory as the Robots folder.&lt;br&gt;<br /> This default.set also requires that you have robot '''&quot;Hunter V2.2.txt&quot;''' in your folder.&lt;br&gt;<br /> Either that or you need to edit it out of the file.&lt;br&gt;<br /> Play with it and see ... why not?)<br /> <br /> &lt;!-- NOTE: using &lt;pre&gt; and &lt;/pre&gt; to create a box for code, including HTML code--&gt;<br /> &lt;!-- no need to put a leading space on the left of each entry--&gt;<br /> &lt;pre&gt;<br /> -2<br /> 1<br /> 9271<br /> 6971<br /> 0<br /> 0<br /> 0<br /> &quot;C:\Program Files\DarwinBotsII\Robots&quot;<br /> 5<br /> &quot;Alga_Minimalis.txt&quot;<br /> #TRUE#<br /> #FALSE#<br /> 3983420<br /> 0<br /> 3000<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 56<br /> 73<br /> 13<br /> 3<br /> 48<br /> 407<br /> 21<br /> 444<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> 19140<br /> 13620<br /> 0<br /> 0<br /> 5000<br /> &quot;&amp;#\Robots&quot;<br /> 5<br /> &quot;Hunter V2.2.txt&quot;<br /> #FALSE#<br /> #FALSE#<br /> 25356<br /> 0<br /> 3000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 5000<br /> 57<br /> 431<br /> 59<br /> 47<br /> 34<br /> 381<br /> 8<br /> 14<br /> 0<br /> 0<br /> 0<br /> 0<br /> 0<br /> &quot;&quot;<br /> 2<br /> 1<br /> 9237<br /> 6928<br /> 25<br /> #FALSE#<br /> #FALSE#<br /> 0<br /> #TRUE#<br /> 30<br /> 10<br /> .004<br /> .04<br /> 2<br /> 1<br /> 200<br /> #TRUE#<br /> 3<br /> 0<br /> 0<br /> .8<br /> 1.1<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> 0<br /> 1<br /> #FALSE#<br /> 0<br /> 0<br /> &quot;&quot;<br /> #FALSE#<br /> #FALSE#<br /> #FALSE#<br /> #FALSE#<br /> 90<br /> #FALSE#<br /> 10<br /> 1<br /> #FALSE#<br /> 1000<br /> 2<br /> 3<br /> .5<br /> #FALSE#<br /> #FALSE#<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &quot;&quot;<br /> &quot;&quot;<br /> 0<br /> &quot;&quot;<br /> &lt;/pre&gt;<br /> <br /> == Windows 95 Problems ==<br /> There is a report that Darwinbots will replace comdlg32.dll with a newer and apparently non-compatible version if you run WIndows 95. Individual instances of this should be reported in the [http://forum.darwinbots.com forum].<br /> <br /> == Runtime Error==<br /> I keep getting a runtime error (76)<br /> This happens rendomly while running a simulation.[[User:Blacksmith|Blacksmith]] 15:42, 21 January 2008 (MST)<br /> <br /> == Run-time error 713 on Windows 7 ==<br /> On Windows 7, in the &quot;Simulation Settings&quot; window, the &quot;Custom Simulation Costs&quot; button on the Physics and Costs tab causes a fatal error as follows:<br /> <br /> Run-time error '713': Class not registered. You need the following file to be installed on your machine. MSSTDFMT.DLL.<br /> <br /> This problem is (allegedly) fixable on Windows Vista via regsvr32. The same method, unfortunately, fails to work on Windows 7 (a fatal error occurs between opening the file and registering it), locking those users out of those settings unless they proceed to install and run Darwinbots inside XP Mode (an XP Virtual Machine).<br /> <br /> : I've installed windows 7 x64 at work today. It wasn't working at all at first, but I re-ran the installation program as an administrator and it seems to work just fine now. --[[User:Numsgil|Numsgil]] 19:25, 2 November 2009 (MST)</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Main_FTP&diff=4956 2009-11-03T02:19:51Z

<p>Numsgil: </p> <hr /> <div>__NOTOC__&lt;!-- __NOTOC__ disables Table of Contents (short pages may not require it--&gt;<br /> == Main Install ==<br /> <br /> Run the main install for [http://www.darwinbots.com/FTP/Darwin21.zip DarwinBots 2.1] We are working on an installer for the latest version below, but at the moment, this is the only version for which an installer exists. It creates some directories and installs some runtimes and thus '''must be installed''' before you can use any of the newer versions below. See the [[Installation_Instructions|installation instructions]]. The version installed with this main install works, but it is ancient (several years old) so you will want to immediatly download one of the newer releases below.<br /> <br /> == Recent Releases ==<br /> <br /> To update to the latest release, simply copy the file(s) included in a new release into your install location (by default c:\Program File\DarwinbotsII\). Again, '''the new file(s) MUST be placed into your install location'''. Usually, new releases consist of only the DarwinBots executable. If other files are included in a release, you should say 'yes' to all overwrites. Then simply run the new executable instead of the executable that came with the main install. <br /> <br /> === 2.43.1L ===<br /> [http://www.darwinbots.com/FTP/Darwin2.43.1L.zip 2.43.1L] is the current recommended, and latest stable version of DarwinBots. <br /> <br /> === 2.44.1 ===<br /> <br /> [http://www.darwinbots.com/FTP/Darwin2.44.1.zip Version 2.44.1] is the latest official release fresh from the developers. It is very stable though it is always possible there are a few bugs, particularly in newer feature areas. Please make the developers aware of any issues you encounter via the [http://forum.darwinbots.com forum]. <br /> <br /> Some bots may behave differently in recent versions than they did in very old versions (versions prior to 2.4) due to differences in the underlying physics engines and changes/additions to the underlying DNA language. Please bring any such differences you notice to the attention of the program authors at the [http://forum.darwinbots.com forum].<br /> <br /> Note: The robots that come with the main 2.1 install above will run in modern versions, but they are going to act a little stupid. They may have a hard time even surviving. '''Strongly consider downloading more modern bots from the [http://forum.darwinbots.com/index.php?showforum=13 bestiary].''' [http://forum.darwinbots.com/index.php?act=ST&amp;f=24&amp;t=157&amp;st=0#entry240895 Animal Minimalis] is a good start, and is used in the [[Robot Tutorial]]s. Just copy the text into a plain old .txt file, and put the file into your robots directory.<br /> <br /> == Tutorials ==<br /> <br /> The [http://www.darwinbots.com/FTP/DarwinTutorial1+2.zip Darwinbots bot writing tutorial by PY] is a little old but a very good primer to learning how the DNA works. You can also check out the [[Robot Tutorial]]<br /> <br /> == See Also ==<br /> <br /> * [[Previous Versions]]<br /> * [[Source code download]]<br /> <br /> == Vista and Windows 7 ==<br /> If you are running Vista or Windows 7, you will need to '''run the installation as an Administrator'''. Right-click on the Darwinbots install (or a shortcut to it) and choose &quot;Run as Administrator&quot;. <br /> <br /> == Windows 95 Trouble ==<br /> There is a report that Darwinbots might cause problems if you are running Windows 95. If you experience any such problems, please post them to the [http://forum.darwinbots.com forum].<br /> <br /> Return to [[Main Page]]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Tasks&diff=4953 2009-10-15T00:15:52Z

<p>Numsgil: </p> <hr /> <div>== References ==<br /> * [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C]<br /> * Numerical Methods for Least Squared Problems by Ake Bjorck. ISBN: 0-89871-360-9<br /> <br /> == Azimuth tasks ==<br /> * Expand the rectangular matrix class. See SquareMatrix.<br /> <br /> * Construct a QR decomposer. See the existing code for LU decomposition to get an idea of how the format works. Make sure to test thoroughly to see that it properly handles full rank, below full rank, and rectangular (full and non full rank) matrices. Since QR decomposer works on rectangular matrices, the interface will be a little different than for the others. Also, because it needs to handle arbitrary matrices, a rank revealing QR (RRQR) decomposer is in order.<br /> <br /> * Construct a sparse Cholesky decomposer. I don't have any references for this.<br /> <br /> * Construct a sparse QR decomposer. There's whole sections on this in Numerical Methods for Least Squares Problems, but I haven't read them yet.<br /> <br /> * Right now there are methods for finding roots of up to quartic polynomials analytically. No general analytic methods exist beyond quartic, so we need an iterative general polynomial root finder. This is actually a sort of tricky problem from a numerical standpoint. See section 9.5 in Numerical Recipes in C (&quot;Roots of Polynomials&quot;). Because finding all the roots might be computationally expensive and probably unnecessary, allowing the user to extract roots one at a time with successive calls would work well. The primary use case in mind would involve finding the least positive real root &gt;= 0 (collisions between cubic splines).<br /> <br /> * Someone needs to take a look at finding the points of collision between two &quot;fat&quot; splines. Imagine a line segment. Now move a sphere along the line segment. You have a capsule. Now replace the line segment with a polygon (cubic most likely). See [http://www.gamedev.net/community/forums/topic.asp?topic_id=547699 this thread] I wrote on gamedev talking about it from a broadphase point of view. Someone mentioned &quot;multidimensional Sturm's theorem&quot;. Also, there's [http://www.cs.uiowa.edu/~kearney/pubs/CurvesAndSufacesClosestPoint.pdf closest point on spline to point], which could maybe be expanded in some way, or the basic idea mined.<br /> <br /> == UI.Controls taks ==<br /> * Build an exception console. Basically when Darwinbots is running, when an exception is encountered I want a special exception explorer to pop up on the screen that lets the user examine the exception (in a non modal way), log it in some ways (send an error report, save it to disk, save the currently running sim, etc.), and then ignore it and continue on with the sim (actually the sim should attempt to continue without the user present, but that's another story).<br /> <br /> == Graphics.Core tasks ==<br /> * Build a skeletal animation system. Not strictly necessary for Darwinbots but would be nice to have. See the implementation of Collage to get an idea of what needs to happen.<br /> <br /> * Build a GDI implementation. Consult the XNA implementation as necessary to get an idea of what to do. Should be pretty easy, since you don't have to worry about batching.<br /> <br /> * Graphics.Core is woefully under tested because I wasn't really certain what I was doing as I was doing it, as far as interface goes. Just go back through and try to test as much of the code that's untested at the moment as possible.<br /> <br /> == Non module specific ==<br /> * Code coverage - Each module (hopefully) has some unit tests. Right now there's no way to tell how much of a module is being tested and how much is completely untested. Either find or build some tools that allow us to determine how much of the code is covered by the unit tests.<br /> <br /> * Profiling - Likewise no tools exist right now to profile the code for performance bottlenecks. Either find or build a tool to aid in profiling.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Tasks&diff=4952 2009-10-14T23:34:21Z

<p>Numsgil: </p> <hr /> <div>== References ==<br /> * [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C]<br /> * Numerical Methods for Least Squared Problems by Ake Bjorck. ISBN: 0-89871-360-9<br /> <br /> == Azimuth tasks ==<br /> * Expand the rectangular matrix class. See SquareMatrix.<br /> <br /> * Construct a QR decomposer. See the existing code for LU decomposition to get an idea of how the format works. Make sure to test thoroughly to see that it properly handles full rank, below full rank, and rectangular (full and non full rank) matrices. Since QR decomposer works on rectangular matrices, the interface will be a little different than for the others. Also, because it needs to handle arbitrary matrices, a rank revealing QR (RRQR) decomposer is in order.<br /> <br /> * Construct a sparse Cholesky decomposer. I don't have any references for this.<br /> <br /> * Construct a sparse QR decomposer. There's whole sections on this in Numerical Methods for Least Squares Problems, but I haven't read them yet.<br /> <br /> * Right now there are methods for finding roots of up to quartic polynomials analytically. No general analytic methods exist beyond quartic, so we need an iterative general polynomial root finder. This is actually a sort of tricky problem from a numerical standpoint. See section 9.5 in Numerical Recipes in C (&quot;Roots of Polynomials&quot;). Because finding all the roots might be computationally expensive and probably unnecessary, allowing the user to extract roots one at a time with successive calls would work well. The primary use case in mind would involve finding the least positive real root &gt;= 0 (collisions between cubic splines).<br /> <br /> * Someone needs to take a look at finding the points of collision between two &quot;fat&quot; splines. Imagine a line segment. Now move a sphere along the line segment. You have a capsule. Now replace the line segment with a polygon (cubic most likely). See [http://www.gamedev.net/community/forums/topic.asp?topic_id=547699 this thread] I wrote on gamedev talking about it from a broadphase point of view. Someone mentioned &quot;multidimensional Sturm's theorem&quot;.<br /> <br /> == UI.Controls taks ==<br /> * Build an exception console. Basically when Darwinbots is running, when an exception is encountered I want a special exception explorer to pop up on the screen that lets the user examine the exception (in a non modal way), log it in some ways (send an error report, save it to disk, save the currently running sim, etc.), and then ignore it and continue on with the sim (actually the sim should attempt to continue without the user present, but that's another story).<br /> <br /> == Graphics.Core tasks ==<br /> * Build a skeletal animation system. Not strictly necessary for Darwinbots but would be nice to have. See the implementation of Collage to get an idea of what needs to happen.<br /> <br /> * Build a GDI implementation. Consult the XNA implementation as necessary to get an idea of what to do. Should be pretty easy, since you don't have to worry about batching.<br /> <br /> * Graphics.Core is woefully under tested because I wasn't really certain what I was doing as I was doing it, as far as interface goes. Just go back through and try to test as much of the code that's untested at the moment as possible.<br /> <br /> == Non module specific ==<br /> * Code coverage - Each module (hopefully) has some unit tests. Right now there's no way to tell how much of a module is being tested and how much is completely untested. Either find or build some tools that allow us to determine how much of the code is covered by the unit tests.<br /> <br /> * Profiling - Likewise no tools exist right now to profile the code for performance bottlenecks. Either find or build a tool to aid in profiling.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Robot_DNA&diff=4949 2009-09-27T07:10:36Z

<p>Numsgil: </p> <hr /> <div>==Darwinbots 3==<br /> * [[Differences from DB2]]<br /> <br /> ===The Different Parts===<br /> * [[Base Pair]]s<br /> * [[Codule]]s<br /> * [[Chromosome]]s<br /> * [[Meta Tag]]s<br /> * [[DNA]]<br /> <br /> ===How The DNA Works===<br /> * [[DNA Execution]]<br /> * [[Boolean Stack]]<br /> * [[Integer Stack]]<br /> * [[Custom Variable]]s<br /> * [[System Variable]]s<br /> * [[Mutation]]s<br /> <br /> ==Darwinbots 2==<br /> ===How the DNA works===<br /> * [[Genes]]<br /> * [[Execution Flag]]<br /> * The [[Stack]] <br /> * [[Custom labels]] (or variables if you prefer)<br /> * [[Order of actions]]<br /> <br /> === DNA commands===<br /> An overview of each and every DNA [[command]], from sysvars to logical operators.<br /> <br /> * [[Operators | 2.4 Operators]]<br /> <br /> * [[Pre2.4]]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Tasks&diff=4948 2009-09-27T06:51:24Z

<p>Numsgil: </p> <hr /> <div>== References ==<br /> * [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C]<br /> * Numerical Methods for Least Squared Problems by Ake Bjorck. ISBN: 0-89871-360-9<br /> <br /> == Azimuth tasks ==<br /> * Construct a Cholesky decomposer. See the existing code for LU decomposition to get an idea of how the format works. Make sure to test thoroughly to see that it properly handles singular, non symmetric, and non positive definite matrices. See section 2.9 in Numerical Recipes in C.<br /> <br /> * Construct a rectangular matrix class. Probably should name it MNRectangularMatrix. Use NSquareMatrix as a template. Be sure that the interface allows users to use a NSquareMatrix as a MNRectangularMatrix.<br /> <br /> * Construct a QR decomposer. See the existing code for LU decomposition to get an idea of how the format works. Make sure to test thoroughly to see that it properly handles full rank, below full rank, and rectangular (full and non full rank) matrices. Since QR decomposer works on rectangular matrices, the interface will be a little different than for the others.<br /> <br /> * Construct a sparse Cholesky decomposer. I don't have any references for this.<br /> <br /> * Construct a sparse QR decomposer. There's whole sections on this in Numerical Methods for Least Squares Problems, but I haven't read them yet.<br /> <br /> * Right now there are methods for finding roots of up to quartic polynomials analytically. No analytic methods exist beyond quartic, so we need an iterative general polynomial root finder. This is actually a sort of tricky problem from a numerical standpoint. See section 9.5 in Numerical Recipes in C (&quot;Roots of Polynomials&quot;). Because finding all the roots might be computationally expensive and probably unnecessary, allowing the user to extract roots one at a time with successive calls would work well. The primary use case in mind would involve finding the least positive real root &gt;= 0 (collisions between cubic splines).<br /> <br /> == UI.Controls taks ==<br /> * Build an exception console. Basically when Darwinbots is running, when an exception is encountered I want a special exception explorer to pop up on the screen that lets the user examine the exception (in a non modal way), log it in some ways (send an error report, save it to disk, save the currently running sim, etc.), and then ignore it and continue on with the sim (actually the sim should attempt to continue without the user present, but that's another story).<br /> <br /> == Graphics.Core tasks ==<br /> * Build a skeletal animation system. Not strictly necessary for Darwinbots but would be nice to have. See the implementation of Collage to get an idea of what needs to happen.<br /> <br /> * Build a GDI implementation. Consult the XNA implementation as necessary to get an idea of what to do. Should be pretty easy, since you don't have to worry about batching.<br /> <br /> * Graphics.Core is woefully under tested because I wasn't really certain what I was doing as I was doing it, as far as interface goes. Just go back through and try to test as much of the code that's untested at the moment as possible.<br /> <br /> == Non module specific ==<br /> * Code coverage - Each module (hopefully) has some unit tests. Right now there's no way to tell how much of a module is being tested and how much is completely untested. Either find or build some tools that allow us to determine how much of the code is covered by the unit tests.<br /> <br /> * Profiling - Likewise no tools exist right now to profile the code for performance bottlenecks. Either find or build a tool to aid in profiling.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Tasks&diff=4947 2009-09-17T22:16:13Z

<p>Numsgil: </p> <hr /> <div>== References ==<br /> * [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C]<br /> * Numerical Methods for Least Squared Problems by Ake Bjorck. ISBN: 0-89871-360-9<br /> <br /> == Azimuth tasks ==<br /> * Construct a Cholesky decomposer. See the existing code for LU decomposition to get an idea of how the format works. Make sure to test thoroughly to see that it properly handles singular, non symmetric, and non positive definite matrices. See section 2.9 in Numerical Recipes in C.<br /> <br /> * Construct a sparse Cholesky decomposer. I don't have any references for this.<br /> <br /> * Construct a sparse QR decomposer. There's whole sections on this in Numerical Methods for Least Squares Problems, but I haven't read them yet.<br /> <br /> * Right now there are methods for finding roots of up to quartic polynomials analytically. No analytic methods exist beyond quartic, so we need an iterative general polynomial root finder. This is actually a sort of tricky problem from a numerical standpoint. See section 9.5 in Numerical Recipes in C (&quot;Roots of Polynomials&quot;). Because finding all the roots might be computationally expensive and probably unnecessary, allowing the user to extract roots one at a time with successive calls would work well. The primary use case in mind would involve finding the least positive real root &gt;= 0 (collisions between cubic splines).<br /> <br /> == UI.Controls taks ==<br /> * Build an exception console. Basically when Darwinbots is running, when an exception is encountered I want a special exception explorer to pop up on the screen that lets the user examine the exception (in a non modal way), log it in some ways (send an error report, save it to disk, save the currently running sim, etc.), and then ignore it and continue on with the sim (actually the sim should attempt to continue without the user present, but that's another story).<br /> <br /> == Graphics.Core tasks ==<br /> * Build a skeletal animation system. Not strictly necessary for Darwinbots but would be nice to have. See the implementation of Collage to get an idea of what needs to happen.<br /> <br /> * Build a GDI implementation. Consult the XNA implementation as necessary to get an idea of what to do. Should be pretty easy, since you don't have to worry about batching.<br /> <br /> * Graphics.Core is woefully under tested because I wasn't really certain what I was doing as I was doing it, as far as interface goes. Just go back through and try to test as much of the code that's untested at the moment as possible.<br /> <br /> == Non module specific ==<br /> * Code coverage - Each module (hopefully) has some unit tests. Right now there's no way to tell how much of a module is being tested and how much is completely untested. Either find or build some tools that allow us to determine how much of the code is covered by the unit tests.<br /> <br /> * Profiling - Likewise no tools exist right now to profile the code for performance bottlenecks. Either find or build a tool to aid in profiling.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Tasks&diff=4946 2009-09-13T21:56:45Z

<p>Numsgil: </p> <hr /> <div>== References ==<br /> * [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C]<br /> * Numerical Methods for Least Squared Problems by Ake Bjorck. ISBN: 0-89871-360-9<br /> <br /> == Azimuth tasks ==<br /> * Construct a Cholesky decomposer. See the existing code for LU decomposition to get an idea of how the format works. Make sure to test thoroughly to see that it properly handles singular, non symmetric, and non positive definite matrices. See section 2.9 in Numerical Recipes in C.<br /> <br /> * Construct a sparse Cholesky decomposer. I don't have any references for this.<br /> <br /> * Construct a sparse QR decomposer. There's whole sections on this in Numerical Methods for Least Squares Problems, but I haven't read them yet.<br /> <br /> == UI.Controls taks ==<br /> * Build an exception console. Basically when Darwinbots is running, when an exception is encountered I want a special exception explorer to pop up on the screen that lets the user examine the exception (in a non modal way), log it in some ways (send an error report, save it to disk, save the currently running sim, etc.), and then ignore it and continue on with the sim (actually the sim should attempt to continue without the user present, but that's another story).<br /> <br /> == Graphics.Core tasks ==<br /> * Build a skeletal animation system. Not strictly necessary for Darwinbots but would be nice to have. See the implementation of Collage to get an idea of what needs to happen.<br /> <br /> * Build a GDI implementation. Consult the XNA implementation as necessary to get an idea of what to do. Should be pretty easy, since you don't have to worry about batching.<br /> <br /> * Graphics.Core is woefully under tested because I wasn't really certain what I was doing as I was doing it, as far as interface goes. Just go back through and try to test as much of the code that's untested at the moment as possible.<br /> <br /> == Non module specific ==<br /> * Code coverage - Each module (hopefully) has some unit tests. Right now there's no way to tell how much of a module is being tested and how much is completely untested. Either find or build some tools that allow us to determine how much of the code is covered by the unit tests.<br /> <br /> * Profiling - Likewise no tools exist right now to profile the code for performance bottlenecks. Either find or build a tool to aid in profiling.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Tasks&diff=4945 2009-09-13T21:47:29Z

<p>Numsgil: </p> <hr /> <div>== References ==<br /> * [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C]<br /> * Numerical Methods for Least Squared Problems by Ake Bjorck. ISBN: 0-89871-360-9<br /> <br /> == Azimuth tasks ==<br /> * Construct a Cholesky decomposer. See the existing code for LU decomposition to get an idea of how the format works. Make sure to test thoroughly to see that it properly handles singular, non symmetric, and non positive definite matrices. See section 2.9 in Numerical Recipes in C.<br /> <br /> * Construct a sparse Cholesky decomposer. I don't have any references for this.<br /> <br /> * Construct a sparse QR decomposer. There's whole sections on this in Numerical Methods for Least Squares Problems, but I haven't read them yet.<br /> <br /> == UI.Controls taks ==<br /> * Build an exception console. Basically when Darwinbots is running, when an exception is encountered I want a special exception explorer to pop up on the screen that lets the user examine the exception (in a non modal way), log it in some ways (send an error report, save it to disk, save the currently running sim, etc.), and then ignore it and continue on with the sim (actually the sim should attempt to continue without the user present, but that's another story).<br /> <br /> == Graphics.Core tasks ==<br /> * Build a skeletal animation system. Not strictly necessary for Darwinbots but would be nice to have. See the implementation of Collage to get an idea of what needs to happen.<br /> <br /> * Build a GDI implementation. Consult the XNA implementation as necessary to get an idea of what to do. Should be pretty easy, since you don't have to worry about batching.<br /> <br /> == Non module specific ==<br /> * Code coverage - Each module (hopefully) has some unit tests. Right now there's no way to tell how much of a module is being tested and how much is completely untested. Either find or build some tools that allow us to determine how much of the code is covered by the unit tests.<br /> <br /> * Profiling - Likewise no tools exist right now to profile the code for performance bottlenecks. Either find or build a tool to aid in profiling.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Tasks&diff=4944 2009-09-13T21:40:16Z

<p>Numsgil: New page: == References == * [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C] * Numerical Methods for Least Squared Problems by Ake Bjorck. ISBN: 0-89871-360-9 == Azimuth tasks == * C...</p> <hr /> <div>== References ==<br /> * [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C]<br /> * Numerical Methods for Least Squared Problems by Ake Bjorck. ISBN: 0-89871-360-9<br /> <br /> == Azimuth tasks ==<br /> * Construct a Cholesky decomposer. See the existing code for LU decomposition to get an idea of how the format works. Make sure to test thoroughly to see that it properly handles singular, non symmetric, and non positive definite matrices. See section 2.9 in Numerical Recipes in C.<br /> <br /> * Construct a sparse Cholesky decomposer. I don't have any references for this.<br /> <br /> * Construct a sparse QR decomposer. There's whole sections on this in Numerical Methods for Least Squares Problems, but I haven't read them yet.<br /> <br /> == UI.Controls taks ==<br /> * Build an exception console. Basically when Darwinbots is running, when an exception is encountered I want a special exception explorer to pop up on the screen that lets the user examine the exception (in a non modal way), log it in some ways (send an error report, save it to disk, save the currently running sim, etc.), and then ignore it and continue on with the sim (actually the sim should attempt to continue without the user present, but that's another story).<br /> <br /> == Graphics.Core tasks ==<br /> * Build a skeletal animation system. Not strictly necessary for Darwinbots but would be nice to have. See the implementation of Collage to get an idea of what needs to happen.<br /> <br /> * Build a GDI implementation. Consult the XNA implementation as necessary to get an idea of what to do. Should be pretty easy, since you don't have to worry about batching.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4943 2009-09-13T21:25:50Z

<p>Numsgil: /* Subarticles */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture (Out of date) ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks|Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4942 2009-09-13T21:25:38Z

<p>Numsgil: /* Subarticles */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture (Out of date) ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> * [[Darwinbots3/Tasks]] - A list of relatively self contained tasks which need doing.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4939 2009-08-15T00:19:02Z

<p>Numsgil: /* Release pattern */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision (ie: the changelist number in the SVN) corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture (Out of date) ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4938 2009-08-15T00:18:14Z

<p>Numsgil: /* Architecture */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture (Out of date) ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4937 2009-08-15T00:17:55Z

<p>Numsgil: </p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Modules ==<br /> Modules generally have the following structure: there's a &quot;core&quot; API which is essentially a wrapper around different implementations (for examples, see the graphics modules). These &quot;core&quot; APIs will automatically search for and load any appropriate implementations in the same assembly or search for assemblies in the same working directory.<br /> <br /> Each of these implementations will have the core library, a unit testing project, and a demo framework. The unit testing project is built with UnitTestSharp and is designed to be run as a post build step of itself in the solution. So if you build the implementation in the IDE you might notice that the unit testing project is reporting that it's failing to build. This can be either an actual compile error or a failing test (which will be treated as a compile error. Double clicking on the error will usually take you to where in source it's failing). The demo framework is a (generally untested) simple app which can be used to interact with various aspects of the module in question without waiting for it to be integrated into Darwinbots3 in the final stage. For instance, for DNA there's a console version which let's you write DNA code and see the results. For physics there's a &quot;physics playground&quot; with various physics scenarios presented to the user to inspect. These demo frameworks generally won't be presented to the end user. They're more for developers.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4936 2009-08-11T18:27:21Z

<p>Numsgil: /* Visual Studio solution files */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory. Note that you shouldn't need to do this very often, since the end binaries are submitted to the repository.<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4935 2009-08-11T18:25:47Z

<p>Numsgil: /* Coding standards */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory (note: as of this writing such scripts do not exist. - Sept 08)<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Repository etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> * Be careful what files you submit. If it's a large file it will take up repository space for ever and ever, even if you remove it from the repository later. Repository space is not unlimited.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Module/Graphics.Core&diff=4934 2009-06-15T16:39:14Z

<p>Numsgil: </p> <hr /> <div>'''Graphics.Core''' is an interface module which allows other modules to draw without understanding the different APIs involved.<br /> <br /> == Selecting a graphics module ==<br /> Depending on the platform (windows, XBox, etc.) different graphics APIs might be used. Often, there is a choice between multiple different APIs. The GraphicsAdapterManager singleton searches through the current executing assembly for graphics modules which can be used. The current executing directory is also searched for binaries of the form &quot;Graphics*.dll&quot;, and any graphics modules found in them are extracted.<br /> <br /> GraphicsAdapaterManager.Modules is an IEnumberable&lt;string&gt; containing the names of all the available modules. Select one from the list and set the current adapter with a call to GraphicsAdapterManager.Singleton.SetCurrentModule(moduleName);<br /> <br /> == DrawPrimitive ==<br /> A DrawPrimitive is all the information necessary to draw a shape in a body's local space. It contains all the information about transformations, vertices, colors, draw order, style, and color. Plus obviously what sort of shape it is.<br /> <br /> The DrawPrimitive is the most basic form for all graphics.<br /> <br /> == Collages ==<br /> A '''collage''' is a collection of draw primitives. A collage defines a template for drawing a compound shape.<br /> <br /> Adding DrawPrimitives to a collage can be done manually. However the preferred use is to use the collage as an object which knows how to add primitives to itself. By setting the Color and Style properties, the collage can act as a sort of immediate mode smart drawing canvas.<br /> <br /> == Collage Ref ==<br /> Collages are ''templates'' for drawing compound shapes. In order to actually draw the collage, you must initialize a CollageRef.<br /> <br /> The collage ref can contain specific &quot;local&quot; information about a collage. For instance, if a collage had an animation sequence, the collage ref would contain the time stamp in to that animation sequence. In this way a single collage is sort of a template from which multiple individual instances can be spawned.<br /> <br /> == Entity ==<br /> An entity represents an actual drawable object. It combines a CollageRef with a world transform.<br /> <br /> == Cel ==<br /> As in an animation cel. A cel is basically a &quot;layer&quot; onto which entities are drawn. <br /> <br /> In order to keep the draw orders sane, draw order only affects the draw order in a cel. Draw order only affects the relative ordering of primitives in a cel.<br /> <br /> It helps to think of a cel as a piece of cellophane on which entities are painted according to their draw order. Just like in an animation studio, multiple cels can make up a final scene (for instance, a background cel, a foreground cel, and a character cel can all be drawn).<br /> <br /> == DrawQueue ==<br /> A draw queue holds the different cels to be drawn, and orders them appropriately.<br /> <br /> == WindowHandle ==<br /> A window handle represents an actual drawable surface somewhere on screen. By submitting the draw queue to be drawn, graphics can be put on to the screen.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4933 2009-06-15T15:28:38Z

<p>Numsgil: /* Subarticles */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory (note: as of this writing such scripts do not exist. - Sept 08)<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> * [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> * [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots_3&diff=4932 2009-06-15T08:05:10Z

<p>Numsgil: /* Subarticles */</p> <hr /> <div>Use the following link for a real-time discussion of features and progress: [http://chat.darwinbots.com Link to developer's chat]<br /> <br /> 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: [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/Darwinbots3/]<br /> <br /> == Compiling the code ==<br /> === Getting the compiler ===<br /> You'll need a version of Visual C# 2008 (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. If you're prompted on whether to install any SQL components, choose yes. The whole process will probably take several hours to do. The good news is that even if you never start programming Darwinbots, you just found a free high quality compiler :D<br /> <br /> === Downloading the dependencies ===<br /> To compile the project, you need:<br /> <br /> * [http://www.microsoft.com/downloads/thankyou.aspx?familyId=7d70d6ed-1edd-4852-9883-9a33c0ad8fee&amp;displayLang=en XNA 3.0] - A game library released by Microsoft which is used for graphics and math related things.<br /> <br /> To distribute the project, you need:<br /> <br /> * [http://research.microsoft.com/~mbarnett/ILMerge.aspx ILMerge] - Allows multiple .NET assemblies (.DLLs) to be packaged into a single assembly.<br /> * Double check what needs to be installed .NET wise and XNA wise (redistributables).<br /> <br /> === Get either Subversion or a Subversion client ===<br /> For those unfamiliar with version control, it's basically a way to ensure that multiple people can work on the same source code. You &quot;check out&quot; 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 &quot;commit&quot; 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.<br /> <br /> 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. Numsgil uses [http://www.syntevo.com/smartsvn/index.html SmartSVN], which he highly recommends.<br /> <br /> === Accessing the repository and committing ===<br /> [https://svn2.hosted-projects.com/Numsgil/Darwinbots3/ https://svn2.hosted-projects.com/Numsgil/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://www.darwinbots.com/Forum/index.php?s=2c5129f4c423731b6c1effece256aaef&amp;showforum=62 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.<br /> <br /> === How you should set up your SVN projects and local directories ===<br /> I recommend setting up two SVN projects. One for the 3rd party libraries, and one for the current branch your working on (or trunk or a specific tag or what have you). It doesn't matter where you put the source code, as long as the current branch you're working on is a sibling to the 3rdParty folder. For example, this is the suggested setup:<br /> <br /> * \Darwinbots3<br /> ** \Source<br /> *** \3rdParty &lt;-- sync this to the 3rd party directory in the repository<br /> *** \Trunk (actual name doesn't matter) &lt;-- sync this to the trunk directory in the repository, or one of the tags or branches if you're working from them<br /> <br /> Again, the source folder doesn't have to be inside your Darwinbots3 folder, but 3rdParty and Trunk (or whatever you name it) need to be siblings.<br /> <br /> === Visual Studio solution files ===<br /> 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. To build the entire project, you'll need to run one of the build scripts in the Scripts directory (note: as of this writing such scripts do not exist. - Sept 08)<br /> <br /> === Junk directories and bin folders ===<br /> 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 &quot;About This Folder.txt&quot; file. Final EXEs are built to the Bin folder, which also should be empty on the repository, except for its own &quot;About This Folder.txt&quot; file. Under the scripts directory, there are scripts for publishing from the Bin directory to the top level Darwinbots3 directory (essentially publishing locally) and scripts to clean the junk folders (delete files and such).<br /> <br /> This setup is subject to change based on usability issues.<br /> <br /> === You have the code, now what? ===<br /> Each module has its own solution file. Because many modules have interdependencies, you'll have to build all the modules at least once. In the Scripts folder, there is a batch file called BuildAll-Release. Run that file. You might need to run it more than once depending on what order the batch file decides to build the modules in. (Using the batch file is no longer necessary)<br /> <br /> == Coding standards ==<br /> <br /> === Basic Standards ===<br /> I'm using [http://weblogs.asp.net/brijmohan/archive/2008/10/10/c-coding-standards-by-lance-s.aspx this standard], or trying to anyway.<br /> <br /> === Etiquette ===<br /> * 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.<br /> <br /> * 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.<br /> <br /> === Unit testing ===<br /> 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.<br /> <br /> Ideally, you would write the tests first and then &quot;fix&quot; 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.<br /> <br /> === Design patterns ===<br /> I'm not too concerned about strictly following design patterns, but you should at the least be aware of them. [http://www.dofactory.com/Patterns/Patterns.aspx This article] shows the more common design patterns and examples for them. Personally I've found various factory patterns useful for things like the DNA language parsing and unparsing.<br /> <br /> == Release pattern ==<br /> When a new release is ready, it's given a version number. The format is:<br /> * '''Darwinbots3 AXXXXX.exe''' - An alpha release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3 BXXXXX.exe''' - A beta release. The XXXXX is the source control revision corresponding to the executable<br /> * '''Darwinbots3.0.exe''' - The first feature complete and stable release.<br /> * '''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).<br /> * '''Darwinbots3.XXX''' - The stable release for version XXX.<br /> <br /> Note that these files alphabetically sort according to when they are expected to release. This is important.<br /> <br /> == Architecture ==<br /> I'm designing the program around the idea of &quot;data-centered&quot;. You can read a paper about it [http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf here] (just browse through it, it's pretty big. Focus on the part near the beginning where he explores different architecture models). <br /> <br /> Basically, each module interacts only indirectly with other modules through a central data repository. Instead of a something like monster[456].Draw(), you'd have Draw(Monster[456]). The benefit of a design like this is that it allows you to swap different modules (change your graphics from OpenGL to Ogre, for instance) easily, lowers the allowed interdependency between modules, and lets the modules themselves be reused in different projects.<br /> <br /> In general, all the game data, such a bots, shots, ties, etc., go into a central repository. A method goes into class of a data object only if it's strictly involved with manipulating the data and not doing something to it. For instance, a function that takes an amount a bot is supposed to be charged in nrg and gives it waste too should go with the bot's class. A function that handles collisions between bots and shots should probably go in a module. It's not strictly black and white, but generally ask yourself if adding a function ties the data directly together with a module. If we wanted to swap out one of the modules, would we find it difficult to disentangle the data repository from it? If so, it belongs in a module (in the case of the bot shot collision, it would probably belong in the game logic module).<br /> <br /> The following is a rough draft of the different modules I'm planning:<br /> <br /> * DNAModule AKA Sunweaver - A fairly self contained module that handles most of its own functions, parsing, etc. Very little interfacing is needed with it beyond a few &quot;black box&quot; controls.<br /> * Graphics Module - Consists strictly of calls to OpenGL, assuming I use OpenGL.<br /> * GUI Module - Contains the dialog boxes and windows the user will probably use and see, all written with Forms.<br /> * Game Logic Module - Handles the core simulation, minus physics and DNA.<br /> * Math library AKA Azimuth - A low level library of basic math primitives and functions like vectors, matrices, and solving systems of linear equations.<br /> * Physics Module AKA Lodestone - The physics engine for Darwinbots, coded for a great deal of feedback as far as collision forces, etc.<br /> * Networking - Handles interfacing with the internet. Users could download bots from an online database right from the program, for instance. Also internet sharing, program updates, etc.<br /> * Disk IO - Handles serializing the data. Data will probably be saved as zipped XML files, to allow for outside manipulation through scripting languages.<br /> * MainExe - Basically nothing more than calls to the different modules to initialize them and start the game loop, calling each module in the proper order.<br /> * Central Data Repository - Stores references to bots, shots, ties, DNA, etc. Very little algorithmic work going on.<br /> <br /> These modules ideally would end up as seperate DLLs to help enforce modularity, but this might cause cyclic dependancies, so I'm not holding my breath.<br /> <br /> == Design == <br /> Visit the [[Darwinbots 3 wish list | wish list]] to see the major features under consideration from the point of view of the end result. Discuss them [http://www.darwinbots.com/Forum/index.php?showforum=62 in the forum].<br /> <br /> == Milestones ==<br /> [[Darwinbots3/Milestone 1|Milestone 1]] - Basic functionality version<br /> <br /> == Subarticles ==<br /> [[Darwinbots3/Physics|Physics explanation]] - An explanation in plain &lt;math&gt;\LaTeX&lt;/math&gt; of how the physics engine works.<br /> [[Darwinbots3/Module|Modules]] - A list of modules involved in Darwinbots3 and an explanation of how each works.<br /> <br /> == DNA ==<br /> Visit the [[Robot DNA]] page to see how the DNA will work.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Module/Graphics.Core&diff=4931 2009-06-15T08:02:25Z

<p>Numsgil: New page: '''Graphics.Core''' is an interface module which allows other modules to draw without understanding the different APIs involved. == Selecting a graphics module == Depending on the platfor...</p> <hr /> <div>'''Graphics.Core''' is an interface module which allows other modules to draw without understanding the different APIs involved.<br /> <br /> == Selecting a graphics module ==<br /> Depending on the platform (windows, XBox, etc.) different graphics APIs might be used. Often, there is a choice between multiple different APIs. The GraphicsAdapterManager singleton searches through the current executing assembly for graphics modules which can be used. The current executing directory is also searched for binaries of the form &quot;Graphics*.dll&quot;, and any graphics modules found in them are extracted.<br /> <br /> GraphicsAdapaterManager.Modules is an IEnumberable&lt;string&gt; containing the names of all the available modules. Select one from the list and set the current adapter with a call to GraphicsAdapterManager.Singleton.SetCurrentModule(moduleName);<br /> <br /> == DrawPrimitive ==<br /> A DrawPrimitive is all the information necessary to draw a shape in a body's local space. It contains all the information about transformations, vertices, colors, draw order, style, and color. Plus obviously what sort of shape it is.<br /> <br /> The DrawPrimitive is the most basic form for all graphics.<br /> <br /> == Collages ==<br /> A '''collage''' is a collection of draw primitives. A collage defines a template for drawing a compound shape.<br /> <br /> Adding DrawPrimitives to a collage can be done manually. However the preferred use is to use the collage as an object which knows how to add primitives to itself. By setting the Color and Style properties, the collage can act as a sort of immediate mode smart drawing canvas.<br /> <br /> == Collage Ref ==<br /> Collages are ''templates'' for drawing compound shapes. In order to actually draw the collage, you must initialize a CollageRef.<br /> <br /> == Entity ==<br /> An entity represents an actual drawable object. It combines a CollageRef with a world transform.<br /> <br /> == Cel ==<br /> As in animation cel. A cel can contain multiple entities. In order to keep the draw orders sane, draw order only affects the draw order in a cel. Once a cel has been drawn, the draw order buffer is wiped clean so that the next cel can be drawn. It helps to think of a cel as a piece of cellophane on which entities are painted according to their draw order. Just like in an animation studio, multiple cels can make up a final scene (for instance, a background cel, a foreground cel, and a character cel can all be drawn).<br /> <br /> == DrawQueue ==<br /> A draw queue holds the different cels to be drawn, and orders them appropriately.<br /> <br /> == WindowHandle ==<br /> A window handle represents an actual drawable surface somewhere on screen. By submitting the draw queue to be drawn, graphics can be put on to the screen.</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Module&diff=4930 2009-06-15T07:27:48Z

<p>Numsgil: New page: Documentation of the modules which make up Darwinbots3: Graphics.Core</p> <hr /> <div>Documentation of the modules which make up Darwinbots3:<br /> <br /> [[Darwinbots3/Module/Graphics.Core | Graphics.Core]]</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Milestone_1&diff=4929 2009-06-15T07:11:36Z

<p>Numsgil: /* GUI */</p> <hr /> <div>This is the first milestone for Darwinbots 3, representing a bare minimum working version of the program, with all core subsystems in place (physics, DNA, etc.). Essentially this is a simplified version of what Darwinbots 1 looked like. These requirements best case wishful thinking. Some requirements may need to be relaxed.<br /> <br /> == Definitions ==<br /> * '''Assets''' - Files created during a user's use of Darwinbots. This would include bots, simulations, settings, etc.<br /> * '''The project''' - Darwinbots 3. Not to be confused with a C# project.<br /> <br /> == Administrative tasks ==<br /> These are &quot;meta coding&quot; tasks that are not involved directly in the creation or operation of the program, but are still necessary to accomplish. Examples include programmer tools, documentation, and installation scripts.<br /> <br /> === Installer ===<br /> The program will have an installer which will properly and correctly install and uninstall the program using NSIS.<br /> <br /> * The creation of the installation program will be entirely automated or with as little user input as possible.<br /> * The installer will properly create registry keys for the program to store information about where it's installed on disk, with the option to easily add new parameters to the registry as needed. <br /> * The uninstaller will remove these registry keys entirely.<br /> * The installer will properly handle users installing a newer version on top of an older version.<br /> * The uninstaller will prompt for removing assets, and if the user so chooses, entirely remove all assets.<br /> * Assuming the user chooses to remove all assets, there shall be no trace of where Darwinbots was installed. If a user installs then uninstalls Darwinbots, their directory structure should be identical to when they started.<br /> <br /> === UnitTestSharp (DONE) ===<br /> Unit test sharp is a unit testing framework in .NET constructed to meet the unit testing needs of the project.<br /> <br /> * (DONE) The user will be able to easily construct unit tests for a module they're working on, and add the running of these tests to the build process, so they are notified immediately when something breaks.<br /> * (DONE) The module will be used to test itself, ie: eating your own dog food.<br /> * (DONE) The user will be able to construct data driven tests, where the same test is run using different data. Constructing and maintaining this data should be as easy as maintaining a spreadsheet in Excel.<br /> * (DONE) The user should be able to double click on any failed test in the build process and be taken to the exact line which failed.<br /> <br /> === Code coverage ===<br /> A method to measure code coverage for unit tests will be set up (probably NCover). Generating a report of code coverage for a given module will be as painless as possible (eg: double click).<br /> <br /> === Build process (DONE) ===<br /> A build process will be created and finalized, without any external dependencies beyond what can be placed in the repository. That is, a user with a fresh XP install and a SVN client should be able to sync to the repository and double click on a script/program to entirely build the project, with no other user input required.<br /> <br /> * (DONE) Programmers should not have to explicitly register a solution with some master build list somewhere. The builder should search through all directories in the project for any solution files and build them.<br /> * (DONE) No additional build scripts should need to be maintained beyond *.sln and *.csproj files.<br /> * The build system should not break if a module is renamed or moved up or down in its directory structure.<br /> ** TODO: See if there's a way to explicitly register the &quot;source root&quot; as a system variable, instead of relying on relative paths. Determine if doing so is actually an improvement, or if the ability to have multiple source directories on the computer is preferable.<br /> * (DONE) When a programmer syncs to the latest version on the repository, they shouldn't have to remember to rebuild any changed code, either because the changed module binaries have also been downloaded with the sync, or because the build process they use will know about the update and recompile the changed dependent modules.<br /> * The build process should be sure to run unit tests, and properly report to the user any tests which have failed.<br /> ** TODO: The &quot;build all&quot; scripts are a little flaky about reporting to the user when something fails.<br /> <br /> == Coding tasks ==<br /> These tasks are programming code the end users of Darwinbots 3 will actually be using. At the end of this milestone, users should be able to successfully run some bot species in a sim, watch them evolve, and save and load sims and bots.<br /> <br /> === DNA (Sunweaver) ===<br /> The Sunweaver module will be complete aside from codules and chromosomes.<br /> <br /> * Parsing from human readable text to the internal data structure, and back to human readable text will be entirely supported. Comments and formatting do not necessarily need to be preserved in this process.<br /> * Only single codule DNA will be supported, just like the current DB2. Support for multiple codules and chromosomes will be held off for a later milestone.<br /> * Command list and DNA syntax should be mostly finalized. Bots constructed or evolved using Milestone 1 should still be operable in the 3.0 release.<br /> * Asexual reproduction of DNA with mutations will work properly.<br /> * The following mutation types will be supported:<br /> ** Point mutations - A base pair is transformed into another random base pair. The probability of each base pair being chosen is uniformly distributed.<br /> ** Insertion - A length of random base pairs will be inserted into a random location in the genome.<br /> ** Deletion - A random contiguous length of DNA will be entirely removed from the genome.<br /> ** Translocation - A random contiguous length of DNA will removed from a section of the codule and re-inserted in a different location<br /> ** Amplification - A random contiguous length of DNA will be copied and that copy inserted at a random location.<br /> * A decision will be made as far as which mutation types might occur during reproduction, which might occur during any given cycle, and which can be either.<br /> <br /> === Physics (Lodestone) ===<br /> <br /> * (DONE) '''Shape''' - A shape consists of collision detection geometry, but no mass, inertia, velocity, position, orientation, etc. information. The following shapes must be supported at a minimum:<br /> ** Point<br /> ** Circle<br /> ** Rectangle/Polygon<br /> ** Capsule (with circular ends of different radii) NOTE: This is no longer a Milestone 1 requirement<br /> ** Trapezoid (Replaces Capsule for at least Milestone 1)<br /> * (DONE) '''Point Mass''' - An inertial object with no physical dimensions. That is, it has the 0th, 1st, and 2nd derivatives of position and orientation, as well as mass and moment of inertia.<br /> ** Point masses will support objects with no mass and/or inertia, and objects with infinite mass and/or inertia.<br /> * (DONE) '''Body''' - A combination of one or more shapes and a point mass.<br /> ** Decide how to handle collisions between 0 mass objects and collisions between infinite mass objects.<br /> ** Decide how to handle two infinite mass objects squeezing another body between them (irresistable force and an unmovable object). Disallowing infinite mass objects from moving is a valid solution.<br /> * Bodies will be realistically simulated assuming constant acceleration between frames.<br /> * No tunneling will be permitted. No matter how fast a body is moving, it should be impossible to incorrectly pass through another body. An adaptive integration step will be used for bodies where necessary to resolve collisions.<br /> * Stacking of arbitrary depth will be stable. Create a stacking matrix representing all the forces at work and invert to find the reaction forces.<br /> * Figure out how to handle sliding. If necessary it is permissible for all objects to have infinite coefficients of friction (eg: no slipping).<br /> * Figure out how to handle rolling. (No ideas here).<br /> * It must be permissible for a body to be ''inside'' another body. For instance, all bots must be inside the rectangular bounds of the simulation.<br /> * All forces on a body during a timestep need to be enumerated and browsable. This will be important for touch senses for bots, as well as handling bots &quot;breaking&quot; under load.<br /> * Shapes changing shape or size are for another milestone.<br /> * Joints and articulated bodies are for another milestone.<br /> * Destructable shapes (for ant tunnels, etc.) are for another milestone.<br /> * Fluid simulation (for smells) are for another milestone.<br /> * Fluid simulation (for swimming) are for another milestone.<br /> <br /> === Graphics ===<br /> * Vector graphics will be used.<br /> * In order to use modern 3D hardware, each bot will really be a polygon.<br /> * Curves (circles, ovoids, etc.) will be handled on the shader side to avoid issues with subdivision.<br /> * Try out XNA and GDI. Maybe even allow the user to switch which one is being used in an options panel somewhere.<br /> <br /> === Substances ===<br /> * nrg - The currency used to pay for actions and stay alive<br /> * muscle - Used to strengthen actions. There is an upkeep involved every cycle.<br /> * fat - Used to store nrg.<br /> * chloroplasts (leaves?)- Used to convert sunlight into nrg<br /> <br /> === Veggies ===<br /> The system to feed veggies will be in place and mostly finalized. Veggies will receive nrg based on their surface area and how many chloroplasts they have.<br /> <br /> === Combat ===<br /> * A simplified combat system will be supported to allow for bots to eat each other and veggies. This does not need to be the final system. Depending on the state of the physics engine, this can either be shots, ties, or phagocytosis.<br /> <br /> === GUI ===<br /> * When loading the program, the user is presented instantly with a dialog to that effect.<br /> * The main simulation window is a MDI child of the main program.<br /> * User options panel:<br /> ** Add a species based on a DNA file on disk.<br /> ** Add a zerobot species with a user supplied length<br /> ** Edit mutation rates on a species<br /> *** This should propagate to all currently existing bots of that species. Or prompt the user if it doesn't. Or prompt the user with a choice about which way to do it.<br /> ** Set the starting properties, numbers, and distributions for the spawn of a species.<br /> ** Autosave frequency<br /> ** Simulation settings. In the future these will be attachable to shapes to allow for different properties in the same sim. So keep this in mind when implementing.<br /> *** Ability to change properties for veggies: sunlight flux.<br /> *** Ability to change physics properties like gravity and drag.<br /> *** Ability to set costs for bot actions and DNA upkeep, etc. Reasonable default values will be provided.<br /> *** Ability to set field size. Ability to set field size to infinity.<br /> *** Ability to set a random seed for simulation determinism.<br /> ** Ability to zoom in and out on the main simulation display.<br /> *** (DONE) Using the mouse wheel<br /> *** Using the keyboard<br /> *** Using a GUI widget<br /> ** Ability to turn on/off graphical display, as well as set an update frequency.<br /> ** Graphs will be done in a later milestone.<br /> <br /> === Disk operations (serialization) ===<br /> * Save/load simulation settings<br /> * Save/load an organism (a bot with information on its body levels, etc.)<br /> * Leverage organism save/load and settings save/load routines for simulation save/load.<br /> * All saved files should be parsable by external utilities (XML maybe)<br /> * All saved files should be tiny (compressed XML maybe)</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Milestone_1&diff=4928 2009-06-15T07:10:54Z

<p>Numsgil: /* Graphics */</p> <hr /> <div>This is the first milestone for Darwinbots 3, representing a bare minimum working version of the program, with all core subsystems in place (physics, DNA, etc.). Essentially this is a simplified version of what Darwinbots 1 looked like. These requirements best case wishful thinking. Some requirements may need to be relaxed.<br /> <br /> == Definitions ==<br /> * '''Assets''' - Files created during a user's use of Darwinbots. This would include bots, simulations, settings, etc.<br /> * '''The project''' - Darwinbots 3. Not to be confused with a C# project.<br /> <br /> == Administrative tasks ==<br /> These are &quot;meta coding&quot; tasks that are not involved directly in the creation or operation of the program, but are still necessary to accomplish. Examples include programmer tools, documentation, and installation scripts.<br /> <br /> === Installer ===<br /> The program will have an installer which will properly and correctly install and uninstall the program using NSIS.<br /> <br /> * The creation of the installation program will be entirely automated or with as little user input as possible.<br /> * The installer will properly create registry keys for the program to store information about where it's installed on disk, with the option to easily add new parameters to the registry as needed. <br /> * The uninstaller will remove these registry keys entirely.<br /> * The installer will properly handle users installing a newer version on top of an older version.<br /> * The uninstaller will prompt for removing assets, and if the user so chooses, entirely remove all assets.<br /> * Assuming the user chooses to remove all assets, there shall be no trace of where Darwinbots was installed. If a user installs then uninstalls Darwinbots, their directory structure should be identical to when they started.<br /> <br /> === UnitTestSharp (DONE) ===<br /> Unit test sharp is a unit testing framework in .NET constructed to meet the unit testing needs of the project.<br /> <br /> * (DONE) The user will be able to easily construct unit tests for a module they're working on, and add the running of these tests to the build process, so they are notified immediately when something breaks.<br /> * (DONE) The module will be used to test itself, ie: eating your own dog food.<br /> * (DONE) The user will be able to construct data driven tests, where the same test is run using different data. Constructing and maintaining this data should be as easy as maintaining a spreadsheet in Excel.<br /> * (DONE) The user should be able to double click on any failed test in the build process and be taken to the exact line which failed.<br /> <br /> === Code coverage ===<br /> A method to measure code coverage for unit tests will be set up (probably NCover). Generating a report of code coverage for a given module will be as painless as possible (eg: double click).<br /> <br /> === Build process (DONE) ===<br /> A build process will be created and finalized, without any external dependencies beyond what can be placed in the repository. That is, a user with a fresh XP install and a SVN client should be able to sync to the repository and double click on a script/program to entirely build the project, with no other user input required.<br /> <br /> * (DONE) Programmers should not have to explicitly register a solution with some master build list somewhere. The builder should search through all directories in the project for any solution files and build them.<br /> * (DONE) No additional build scripts should need to be maintained beyond *.sln and *.csproj files.<br /> * The build system should not break if a module is renamed or moved up or down in its directory structure.<br /> ** TODO: See if there's a way to explicitly register the &quot;source root&quot; as a system variable, instead of relying on relative paths. Determine if doing so is actually an improvement, or if the ability to have multiple source directories on the computer is preferable.<br /> * (DONE) When a programmer syncs to the latest version on the repository, they shouldn't have to remember to rebuild any changed code, either because the changed module binaries have also been downloaded with the sync, or because the build process they use will know about the update and recompile the changed dependent modules.<br /> * The build process should be sure to run unit tests, and properly report to the user any tests which have failed.<br /> ** TODO: The &quot;build all&quot; scripts are a little flaky about reporting to the user when something fails.<br /> <br /> == Coding tasks ==<br /> These tasks are programming code the end users of Darwinbots 3 will actually be using. At the end of this milestone, users should be able to successfully run some bot species in a sim, watch them evolve, and save and load sims and bots.<br /> <br /> === DNA (Sunweaver) ===<br /> The Sunweaver module will be complete aside from codules and chromosomes.<br /> <br /> * Parsing from human readable text to the internal data structure, and back to human readable text will be entirely supported. Comments and formatting do not necessarily need to be preserved in this process.<br /> * Only single codule DNA will be supported, just like the current DB2. Support for multiple codules and chromosomes will be held off for a later milestone.<br /> * Command list and DNA syntax should be mostly finalized. Bots constructed or evolved using Milestone 1 should still be operable in the 3.0 release.<br /> * Asexual reproduction of DNA with mutations will work properly.<br /> * The following mutation types will be supported:<br /> ** Point mutations - A base pair is transformed into another random base pair. The probability of each base pair being chosen is uniformly distributed.<br /> ** Insertion - A length of random base pairs will be inserted into a random location in the genome.<br /> ** Deletion - A random contiguous length of DNA will be entirely removed from the genome.<br /> ** Translocation - A random contiguous length of DNA will removed from a section of the codule and re-inserted in a different location<br /> ** Amplification - A random contiguous length of DNA will be copied and that copy inserted at a random location.<br /> * A decision will be made as far as which mutation types might occur during reproduction, which might occur during any given cycle, and which can be either.<br /> <br /> === Physics (Lodestone) ===<br /> <br /> * (DONE) '''Shape''' - A shape consists of collision detection geometry, but no mass, inertia, velocity, position, orientation, etc. information. The following shapes must be supported at a minimum:<br /> ** Point<br /> ** Circle<br /> ** Rectangle/Polygon<br /> ** Capsule (with circular ends of different radii) NOTE: This is no longer a Milestone 1 requirement<br /> ** Trapezoid (Replaces Capsule for at least Milestone 1)<br /> * (DONE) '''Point Mass''' - An inertial object with no physical dimensions. That is, it has the 0th, 1st, and 2nd derivatives of position and orientation, as well as mass and moment of inertia.<br /> ** Point masses will support objects with no mass and/or inertia, and objects with infinite mass and/or inertia.<br /> * (DONE) '''Body''' - A combination of one or more shapes and a point mass.<br /> ** Decide how to handle collisions between 0 mass objects and collisions between infinite mass objects.<br /> ** Decide how to handle two infinite mass objects squeezing another body between them (irresistable force and an unmovable object). Disallowing infinite mass objects from moving is a valid solution.<br /> * Bodies will be realistically simulated assuming constant acceleration between frames.<br /> * No tunneling will be permitted. No matter how fast a body is moving, it should be impossible to incorrectly pass through another body. An adaptive integration step will be used for bodies where necessary to resolve collisions.<br /> * Stacking of arbitrary depth will be stable. Create a stacking matrix representing all the forces at work and invert to find the reaction forces.<br /> * Figure out how to handle sliding. If necessary it is permissible for all objects to have infinite coefficients of friction (eg: no slipping).<br /> * Figure out how to handle rolling. (No ideas here).<br /> * It must be permissible for a body to be ''inside'' another body. For instance, all bots must be inside the rectangular bounds of the simulation.<br /> * All forces on a body during a timestep need to be enumerated and browsable. This will be important for touch senses for bots, as well as handling bots &quot;breaking&quot; under load.<br /> * Shapes changing shape or size are for another milestone.<br /> * Joints and articulated bodies are for another milestone.<br /> * Destructable shapes (for ant tunnels, etc.) are for another milestone.<br /> * Fluid simulation (for smells) are for another milestone.<br /> * Fluid simulation (for swimming) are for another milestone.<br /> <br /> === Graphics ===<br /> * Vector graphics will be used.<br /> * In order to use modern 3D hardware, each bot will really be a polygon.<br /> * Curves (circles, ovoids, etc.) will be handled on the shader side to avoid issues with subdivision.<br /> * Try out XNA and GDI. Maybe even allow the user to switch which one is being used in an options panel somewhere.<br /> <br /> === Substances ===<br /> * nrg - The currency used to pay for actions and stay alive<br /> * muscle - Used to strengthen actions. There is an upkeep involved every cycle.<br /> * fat - Used to store nrg.<br /> * chloroplasts (leaves?)- Used to convert sunlight into nrg<br /> <br /> === Veggies ===<br /> The system to feed veggies will be in place and mostly finalized. Veggies will receive nrg based on their surface area and how many chloroplasts they have.<br /> <br /> === Combat ===<br /> * A simplified combat system will be supported to allow for bots to eat each other and veggies. This does not need to be the final system. Depending on the state of the physics engine, this can either be shots, ties, or phagocytosis.<br /> <br /> === GUI ===<br /> * When loading the program, the user is presented instantly with a dialog to that effect.<br /> * The main simulation window is a MDI child of the main program.<br /> * User options panel:<br /> ** Add a species based on a DNA file on disk.<br /> ** Add a zerobot species with a user supplied length<br /> ** Edit mutation rates on a species<br /> *** This should propagate to all currently existing bots of that species. Or prompt the user if it doesn't. Or prompt the user with a choice about which way to do it.<br /> ** Set the starting properties, numbers, and distributions for the spawn of a species.<br /> ** Autosave frequency<br /> ** Simulation settings. In the future these will be attachable to shapes to allow for different properties in the same sim. So keep this in mind when implementing.<br /> *** Ability to change properties for veggies: sunlight flux.<br /> *** Ability to change physics properties like gravity and drag.<br /> *** Ability to set costs for bot actions and DNA upkeep, etc. Reasonable default values will be provided.<br /> *** Ability to set field size. Ability to set field size to infinity.<br /> *** Ability to set a random seed for simulation determinism.<br /> ** Ability to zoom in and out on the main simulation display.<br /> *** Using the mouse wheel<br /> *** Using the keyboard<br /> *** Using a GUI widget<br /> ** Ability to turn on/off graphical display, as well as set an update frequency.<br /> ** Graphs will be done in a later milestone.<br /> <br /> <br /> === Disk operations (serialization) ===<br /> * Save/load simulation settings<br /> * Save/load an organism (a bot with information on its body levels, etc.)<br /> * Leverage organism save/load and settings save/load routines for simulation save/load.<br /> * All saved files should be parsable by external utilities (XML maybe)<br /> * All saved files should be tiny (compressed XML maybe)</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Milestone_1&diff=4927 2009-06-15T07:09:55Z

<p>Numsgil: /* Physics (Lodestone) */</p> <hr /> <div>This is the first milestone for Darwinbots 3, representing a bare minimum working version of the program, with all core subsystems in place (physics, DNA, etc.). Essentially this is a simplified version of what Darwinbots 1 looked like. These requirements best case wishful thinking. Some requirements may need to be relaxed.<br /> <br /> == Definitions ==<br /> * '''Assets''' - Files created during a user's use of Darwinbots. This would include bots, simulations, settings, etc.<br /> * '''The project''' - Darwinbots 3. Not to be confused with a C# project.<br /> <br /> == Administrative tasks ==<br /> These are &quot;meta coding&quot; tasks that are not involved directly in the creation or operation of the program, but are still necessary to accomplish. Examples include programmer tools, documentation, and installation scripts.<br /> <br /> === Installer ===<br /> The program will have an installer which will properly and correctly install and uninstall the program using NSIS.<br /> <br /> * The creation of the installation program will be entirely automated or with as little user input as possible.<br /> * The installer will properly create registry keys for the program to store information about where it's installed on disk, with the option to easily add new parameters to the registry as needed. <br /> * The uninstaller will remove these registry keys entirely.<br /> * The installer will properly handle users installing a newer version on top of an older version.<br /> * The uninstaller will prompt for removing assets, and if the user so chooses, entirely remove all assets.<br /> * Assuming the user chooses to remove all assets, there shall be no trace of where Darwinbots was installed. If a user installs then uninstalls Darwinbots, their directory structure should be identical to when they started.<br /> <br /> === UnitTestSharp (DONE) ===<br /> Unit test sharp is a unit testing framework in .NET constructed to meet the unit testing needs of the project.<br /> <br /> * (DONE) The user will be able to easily construct unit tests for a module they're working on, and add the running of these tests to the build process, so they are notified immediately when something breaks.<br /> * (DONE) The module will be used to test itself, ie: eating your own dog food.<br /> * (DONE) The user will be able to construct data driven tests, where the same test is run using different data. Constructing and maintaining this data should be as easy as maintaining a spreadsheet in Excel.<br /> * (DONE) The user should be able to double click on any failed test in the build process and be taken to the exact line which failed.<br /> <br /> === Code coverage ===<br /> A method to measure code coverage for unit tests will be set up (probably NCover). Generating a report of code coverage for a given module will be as painless as possible (eg: double click).<br /> <br /> === Build process (DONE) ===<br /> A build process will be created and finalized, without any external dependencies beyond what can be placed in the repository. That is, a user with a fresh XP install and a SVN client should be able to sync to the repository and double click on a script/program to entirely build the project, with no other user input required.<br /> <br /> * (DONE) Programmers should not have to explicitly register a solution with some master build list somewhere. The builder should search through all directories in the project for any solution files and build them.<br /> * (DONE) No additional build scripts should need to be maintained beyond *.sln and *.csproj files.<br /> * The build system should not break if a module is renamed or moved up or down in its directory structure.<br /> ** TODO: See if there's a way to explicitly register the &quot;source root&quot; as a system variable, instead of relying on relative paths. Determine if doing so is actually an improvement, or if the ability to have multiple source directories on the computer is preferable.<br /> * (DONE) When a programmer syncs to the latest version on the repository, they shouldn't have to remember to rebuild any changed code, either because the changed module binaries have also been downloaded with the sync, or because the build process they use will know about the update and recompile the changed dependent modules.<br /> * The build process should be sure to run unit tests, and properly report to the user any tests which have failed.<br /> ** TODO: The &quot;build all&quot; scripts are a little flaky about reporting to the user when something fails.<br /> <br /> == Coding tasks ==<br /> These tasks are programming code the end users of Darwinbots 3 will actually be using. At the end of this milestone, users should be able to successfully run some bot species in a sim, watch them evolve, and save and load sims and bots.<br /> <br /> === DNA (Sunweaver) ===<br /> The Sunweaver module will be complete aside from codules and chromosomes.<br /> <br /> * Parsing from human readable text to the internal data structure, and back to human readable text will be entirely supported. Comments and formatting do not necessarily need to be preserved in this process.<br /> * Only single codule DNA will be supported, just like the current DB2. Support for multiple codules and chromosomes will be held off for a later milestone.<br /> * Command list and DNA syntax should be mostly finalized. Bots constructed or evolved using Milestone 1 should still be operable in the 3.0 release.<br /> * Asexual reproduction of DNA with mutations will work properly.<br /> * The following mutation types will be supported:<br /> ** Point mutations - A base pair is transformed into another random base pair. The probability of each base pair being chosen is uniformly distributed.<br /> ** Insertion - A length of random base pairs will be inserted into a random location in the genome.<br /> ** Deletion - A random contiguous length of DNA will be entirely removed from the genome.<br /> ** Translocation - A random contiguous length of DNA will removed from a section of the codule and re-inserted in a different location<br /> ** Amplification - A random contiguous length of DNA will be copied and that copy inserted at a random location.<br /> * A decision will be made as far as which mutation types might occur during reproduction, which might occur during any given cycle, and which can be either.<br /> <br /> === Physics (Lodestone) ===<br /> <br /> * (DONE) '''Shape''' - A shape consists of collision detection geometry, but no mass, inertia, velocity, position, orientation, etc. information. The following shapes must be supported at a minimum:<br /> ** Point<br /> ** Circle<br /> ** Rectangle/Polygon<br /> ** Capsule (with circular ends of different radii) NOTE: This is no longer a Milestone 1 requirement<br /> ** Trapezoid (Replaces Capsule for at least Milestone 1)<br /> * (DONE) '''Point Mass''' - An inertial object with no physical dimensions. That is, it has the 0th, 1st, and 2nd derivatives of position and orientation, as well as mass and moment of inertia.<br /> ** Point masses will support objects with no mass and/or inertia, and objects with infinite mass and/or inertia.<br /> * (DONE) '''Body''' - A combination of one or more shapes and a point mass.<br /> ** Decide how to handle collisions between 0 mass objects and collisions between infinite mass objects.<br /> ** Decide how to handle two infinite mass objects squeezing another body between them (irresistable force and an unmovable object). Disallowing infinite mass objects from moving is a valid solution.<br /> * Bodies will be realistically simulated assuming constant acceleration between frames.<br /> * No tunneling will be permitted. No matter how fast a body is moving, it should be impossible to incorrectly pass through another body. An adaptive integration step will be used for bodies where necessary to resolve collisions.<br /> * Stacking of arbitrary depth will be stable. Create a stacking matrix representing all the forces at work and invert to find the reaction forces.<br /> * Figure out how to handle sliding. If necessary it is permissible for all objects to have infinite coefficients of friction (eg: no slipping).<br /> * Figure out how to handle rolling. (No ideas here).<br /> * It must be permissible for a body to be ''inside'' another body. For instance, all bots must be inside the rectangular bounds of the simulation.<br /> * All forces on a body during a timestep need to be enumerated and browsable. This will be important for touch senses for bots, as well as handling bots &quot;breaking&quot; under load.<br /> * Shapes changing shape or size are for another milestone.<br /> * Joints and articulated bodies are for another milestone.<br /> * Destructable shapes (for ant tunnels, etc.) are for another milestone.<br /> * Fluid simulation (for smells) are for another milestone.<br /> * Fluid simulation (for swimming) are for another milestone.<br /> <br /> === Graphics ===<br /> * Vector graphics will be used.<br /> * In order to use modern 3D hardware, each bot will really be a polygon. Be sure to adaptively subdivide as relative size increases.<br /> * Try out XNA and GDI. Maybe even allow the user to switch which one is being used in an options panel somewhere.<br /> <br /> === Substances ===<br /> * nrg - The currency used to pay for actions and stay alive<br /> * muscle - Used to strengthen actions. There is an upkeep involved every cycle.<br /> * fat - Used to store nrg.<br /> * chloroplasts (leaves?)- Used to convert sunlight into nrg<br /> <br /> === Veggies ===<br /> The system to feed veggies will be in place and mostly finalized. Veggies will receive nrg based on their surface area and how many chloroplasts they have.<br /> <br /> === Combat ===<br /> * A simplified combat system will be supported to allow for bots to eat each other and veggies. This does not need to be the final system. Depending on the state of the physics engine, this can either be shots, ties, or phagocytosis.<br /> <br /> === GUI ===<br /> * When loading the program, the user is presented instantly with a dialog to that effect.<br /> * The main simulation window is a MDI child of the main program.<br /> * User options panel:<br /> ** Add a species based on a DNA file on disk.<br /> ** Add a zerobot species with a user supplied length<br /> ** Edit mutation rates on a species<br /> *** This should propagate to all currently existing bots of that species. Or prompt the user if it doesn't. Or prompt the user with a choice about which way to do it.<br /> ** Set the starting properties, numbers, and distributions for the spawn of a species.<br /> ** Autosave frequency<br /> ** Simulation settings. In the future these will be attachable to shapes to allow for different properties in the same sim. So keep this in mind when implementing.<br /> *** Ability to change properties for veggies: sunlight flux.<br /> *** Ability to change physics properties like gravity and drag.<br /> *** Ability to set costs for bot actions and DNA upkeep, etc. Reasonable default values will be provided.<br /> *** Ability to set field size. Ability to set field size to infinity.<br /> *** Ability to set a random seed for simulation determinism.<br /> ** Ability to zoom in and out on the main simulation display.<br /> *** Using the mouse wheel<br /> *** Using the keyboard<br /> *** Using a GUI widget<br /> ** Ability to turn on/off graphical display, as well as set an update frequency.<br /> ** Graphs will be done in a later milestone.<br /> <br /> <br /> === Disk operations (serialization) ===<br /> * Save/load simulation settings<br /> * Save/load an organism (a bot with information on its body levels, etc.)<br /> * Leverage organism save/load and settings save/load routines for simulation save/load.<br /> * All saved files should be parsable by external utilities (XML maybe)<br /> * All saved files should be tiny (compressed XML maybe)</div>

Numsgil http://wiki.darwinbots.com/index.php?title=Darwinbots3/Milestone_1&diff=4926 2009-06-15T07:08:12Z

<p>Numsgil: /* Build process */</p> <hr /> <div>This is the first milestone for Darwinbots 3, representing a bare minimum working version of the program, with all core subsystems in place (physics, DNA, etc.). Essentially this is a simplified version of what Darwinbots 1 looked like. These requirements best case wishful thinking. Some requirements may need to be relaxed.<br /> <br /> == Definitions ==<br /> * '''Assets''' - Files created during a user's use of Darwinbots. This would include bots, simulations, settings, etc.<br /> * '''The project''' - Darwinbots 3. Not to be confused with a C# project.<br /> <br /> == Administrative tasks ==<br /> These are &quot;meta coding&quot; tasks that are not involved directly in the creation or operation of the program, but are still necessary to accomplish. Examples include programmer tools, documentation, and installation scripts.<br /> <br /> === Installer ===<br /> The program will have an installer which will properly and correctly install and uninstall the program using NSIS.<br /> <br /> * The creation of the installation program will be entirely automated or with as little user input as possible.<br /> * The installer will properly create registry keys for the program to store information about where it's installed on disk, with the option to easily add new parameters to the registry as needed. <br /> * The uninstaller will remove these registry keys entirely.<br /> * The installer will properly handle users installing a newer version on top of an older version.<br /> * The uninstaller will prompt for removing assets, and if the user so chooses, entirely remove all assets.<br /> * Assuming the user chooses to remove all assets, there shall be no trace of where Darwinbots was installed. If a user installs then uninstalls Darwinbots, their directory structure should be identical to when they started.<br /> <br /> === UnitTestSharp (DONE) ===<br /> Unit test sharp is a unit testing framework in .NET constructed to meet the unit testing needs of the project.<br /> <br /> * (DONE) The user will be able to easily construct unit tests for a module they're working on, and add the running of these tests to the build process, so they are notified immediately when something breaks.<br /> * (DONE) The module will be used to test itself, ie: eating your own dog food.<br /> * (DONE) The user will be able to construct data driven tests, where the same test is run using different data. Constructing and maintaining this data should be as easy as maintaining a spreadsheet in Excel.<br /> * (DONE) The user should be able to double click on any failed test in the build process and be taken to the exact line which failed.<br /> <br /> === Code coverage ===<br /> A method to measure code coverage for unit tests will be set up (probably NCover). Generating a report of code coverage for a given module will be as painless as possible (eg: double click).<br /> <br /> === Build process (DONE) ===<br /> A build process will be created and finalized, without any external dependencies beyond what can be placed in the repository. That is, a user with a fresh XP install and a SVN client should be able to sync to the repository and double click on a script/program to entirely build the project, with no other user input required.<br /> <br /> * (DONE) Programmers should not have to explicitly register a solution with some master build list somewhere. The builder should search through all directories in the project for any solution files and build them.<br /> * (DONE) No additional build scripts should need to be maintained beyond *.sln and *.csproj files.<br /> * The build system should not break if a module is renamed or moved up or down in its directory structure.<br /> ** TODO: See if there's a way to explicitly register the &quot;source root&quot; as a system variable, instead of relying on relative paths. Determine if doing so is actually an improvement, or if the ability to have multiple source directories on the computer is preferable.<br /> * (DONE) When a programmer syncs to the latest version on the repository, they shouldn't have to remember to rebuild any changed code, either because the changed module binaries have also been downloaded with the sync, or because the build process they use will know about the update and recompile the changed dependent modules.<br /> * The build process should be sure to run unit tests, and properly report to the user any tests which have failed.<br /> ** TODO: The &quot;build all&quot; scripts are a little flaky about reporting to the user when something fails.<br /> <br /> == Coding tasks ==<br /> These tasks are programming code the end users of Darwinbots 3 will actually be using. At the end of this milestone, users should be able to successfully run some bot species in a sim, watch them evolve, and save and load sims and bots.<br /> <br /> === DNA (Sunweaver) ===<br /> The Sunweaver module will be complete aside from codules and chromosomes.<br /> <br /> * Parsing from human readable text to the internal data structure, and back to human readable text will be entirely supported. Comments and formatting do not necessarily need to be preserved in this process.<br /> * Only single codule DNA will be supported, just like the current DB2. Support for multiple codules and chromosomes will be held off for a later milestone.<br /> * Command list and DNA syntax should be mostly finalized. Bots constructed or evolved using Milestone 1 should still be operable in the 3.0 release.<br /> * Asexual reproduction of DNA with mutations will work properly.<br /> * The following mutation types will be supported:<br /> ** Point mutations - A base pair is transformed into another random base pair. The probability of each base pair being chosen is uniformly distributed.<br /> ** Insertion - A length of random base pairs will be inserted into a random location in the genome.<br /> ** Deletion - A random contiguous length of DNA will be entirely removed from the genome.<br /> ** Translocation - A random contiguous length of DNA will removed from a section of the codule and re-inserted in a different location<br /> ** Amplification - A random contiguous length of DNA will be copied and that copy inserted at a random location.<br /> * A decision will be made as far as which mutation types might occur during reproduction, which might occur during any given cycle, and which can be either.<br /> <br /> === Physics (Lodestone) ===<br /> <br /> * '''Shape''' - A shape consists of collision detection geometry, but no mass, inertia, velocity, position, orientation, etc. information. The following shapes must be supported at a minimum:<br /> ** Point<br /> ** Circle<br /> ** Rectangle/Polygon<br /> ** Capsule (with circular ends of different radii) NOTE: This is no longer a Milestone 1 requirement<br /> ** Trapezoid (Replaces Capsule for at least Milestone 1)<br /> * '''Point Mass''' - An inertial object with no physical dimensions. That is, it has the 0th, 1st, and 2nd derivatives of position and orientation, as well as mass and moment of inertia.<br /> ** Point masses will support objects with no mass and/or inertia, and objects with infinite mass and/or inertia.<br /> * '''Body''' - A combination of one or more shapes and a point mass.<br /> ** Decide how to handle collisions between 0 mass objects and collisions between infinite mass objects.<br /> ** Decide how to handle two infinite mass objects squeezing another body between them (irresistable force and an unmovable object). Disallowing infinite mass objects from moving is a valid solution.<br /> * Bodies will be realistically simulated assuming constant acceleration between frames.<br /> * No tunneling will be permitted. No matter how fast a body is moving, it should be impossible to incorrectly pass through another body. An adaptive integration step will be used for bodies where necessary to resolve collisions.<br /> * Stacking of arbitrary depth will be stable. Create a stacking matrix representing all the forces at work and invert to find the reaction forces.<br /> * Figure out how to handle sliding. If necessary it is permissible for all objects to have infinite coefficients of friction (eg: no slipping).<br /> * Figure out how to handle rolling. (No ideas here).<br /> * It must be permissible for a body to be ''inside'' another body. For instance, all bots must be inside the rectangular bounds of the simulation.<br /> * All forces on a body during a timestep need to be enumerated and browsable. This will be important for touch senses for bots, as well as handling bots &quot;breaking&quot; under load.<br /> * Shapes changing size are for another milestone.<br /> * Joints and articulated bodies are for another milestone.<br /> * Destructable shapes (for ant tunnels, etc.) are for another milestone.<br /> * Fluid simulation (for smells) are for another milestone.<br /> * Fluid simulation (for swimming) are for another milestone.<br /> <br /> === Graphics ===<br /> * Vector graphics will be used.<br /> * In order to use modern 3D hardware, each bot will really be a polygon. Be sure to adaptively subdivide as relative size increases.<br /> * Try out XNA and GDI. Maybe even allow the user to switch which one is being used in an options panel somewhere.<br /> <br /> === Substances ===<br /> * nrg - The currency used to pay for actions and stay alive<br /> * muscle - Used to strengthen actions. There is an upkeep involved every cycle.<br /> * fat - Used to store nrg.<br /> * chloroplasts (leaves?)- Used to convert sunlight into nrg<br /> <br /> === Veggies ===<br /> The system to feed veggies will be in place and mostly finalized. Veggies will receive nrg based on their surface area and how many chloroplasts they have.<br /> <br /> === Combat ===<br /> * A simplified combat system will be supported to allow for bots to eat each other and veggies. This does not need to be the final system. Depending on the state of the physics engine, this can either be shots, ties, or phagocytosis.<br /> <br /> === GUI ===<br /> * When loading the program, the user is presented instantly with a dialog to that effect.<br /> * The main simulation window is a MDI child of the main program.<br /> * User options panel:<br /> ** Add a species based on a DNA file on disk.<br /> ** Add a zerobot species with a user supplied length<br /> ** Edit mutation rates on a species<br /> *** This should propagate to all currently existing bots of that species. Or prompt the user if it doesn't. Or prompt the user with a choice about which way to do it.<br /> ** Set the starting properties, numbers, and distributions for the spawn of a species.<br /> ** Autosave frequency<br /> ** Simulation settings. In the future these will be attachable to shapes to allow for different properties in the same sim. So keep this in mind when implementing.<br /> *** Ability to change properties for veggies: sunlight flux.<br /> *** Ability to change physics properties like gravity and drag.<br /> *** Ability to set costs for bot actions and DNA upkeep, etc. Reasonable default values will be provided.<br /> *** Ability to set field size. Ability to set field size to infinity.<br /> *** Ability to set a random seed for simulation determinism.<br /> ** Ability to zoom in and out on the main simulation display.<br /> *** Using the mouse wheel<br /> *** Using the keyboard<br /> *** Using a GUI widget<br /> ** Ability to turn on/off graphical display, as well as set an update frequency.<br /> ** Graphs will be done in a later milestone.<br /> <br /> <br /> === Disk operations (serialization) ===<br /> * Save/load simulation settings<br /> * Save/load an organism (a bot with information on its body levels, etc.)<br /> * Leverage organism save/load and settings save/load routines for simulation save/load.<br /> * All saved files should be parsable by external utilities (XML maybe)<br /> * All saved files should be tiny (compressed XML maybe)</div>

Numsgil