Difference between revisions of "C plus plus version"

Revision as of 12:53, 8 March 2006

News and Updates

(05 Feb 2006) The C++ version is nearing completion. It might even be possible to have a beta done by the end of the month, but it means Numsgil needs to really put some effort in, and he's sort of tired of programming. If you know any C++ and want to help, I assure you we'll welcome you with open arms!

Reasons for Language switch

1. If you're wondering why we're switching, it's because VB is for relatively simple, GUI based programs. Darwinbots is neither simple nor gui based. C++, on the other hand is a powerfull language, but it has a higher development cost. Visual Basic controvercy
2. Visual Basic does not intrinsically support pointers. As such, complex data structures become something of a chore to try and make.
3. Numsgil knows more about C++ than he knows about Visual Basic.
4. C++ can be made to be portable (say, we could make a Linux version). And presently the code is being developed with portability in mind (though as yet untested).

Accessing the Current Code

The code is in an online version control system called SVN

To access the SVN, you should download a SVN client. The one I found that I like the most is called Smart SVN. Its basic (and more than adequate) version is free.

The SVN for Darwinbots is located at:

• http://opensvn.csie.org/Darwinbots
• https://opensvn.csie.org/Darwinbots secure server

Read only access is open to everyone. If you want to contribute to the code, you'll need Numsgil to give you a username and password. He can be reached at Numsgil2002@yahoo.com

Code Dependencies

To get the code to compile and work, you'll need the following:

1. A C++ compiler. Dev-C++ is free, but there have been some issues with it conflicting with Microsoft Visual C++ 6.0 (which Numsgil uses, and hence is the officially supported environment). If you don't have MSVC++ 6.0 and would like it, contact Numsgil at Numsgil2002@yahoo.com
2. OpenGL libraries. Specifically, the code must link to glut32.lib, opengl32.lib, and glu32.lib. You probably have these on your computer somewhere, but if you don't, this site will help you
3. Fox GUI Toolkit. This is the library which allows Darwinbots to have a GUI at all. FOX GUI Homepage.
4. The STLport for MSVC++ 6.0 if you have MSVC. Dev-C++ won't need this. It can be found at The Ogre 3D engine download page. It should be listed at the bottom of the page. This makes MSVC a bit more ANSI compliant, among other things. There are some rather nitpicky specifics you need to address to get the stlport working properly (that is, working without compile or link errors). At the time of this writing (March 2006) This Ogre wiki page on building the Ogre source demonstrates what you need to do to get the stlport working properly. Just scroll down to the section called "stlport".
5. I don't know how it works for Dev-C++, but if you run MSVC you must be sure that you select the Multithreaded libraries or you'll probably get an error. To set this, inside MSVC in your project go to project->settings. Go to the C/C++ tab, change category "General" to category "Code Generation". The new upper right hand corner drop box will let you set if you're using multithreaded/singlethreaded libraries.

If you have any problems at all with any of the above steps, or want to help Numsgil make the process a bit smoother and have some ideas, contact him at Numsgil2002@yahoo.com.

Coding Style

The official policy is that as long as Numsgil understands what's going on in your code, your style is fine. If you want to have a more uniform coding style throughout the code, this is the style Numsgil uses:

for(unsigned int x = 0; x < 10; x++)
{
    cout << x; //notice the 4 space tab
}

You are welcome to follow it.

Coding Doctrine

The goal of the code is two things:

1. Speed
2. Readability

Wherever speed is not an issue (as in 97% of the code) coders are encouraged to make the code as readable to newbies as possible. Imagine your mother's life depends on her deciphering your code and you won't be around to help. That means no clever programming tricks, and sparing use of any standard libraries and especially templates and inheritance and polymorphism and other "advanced" concepts.

To Do List (updated sparringly)

Feb 05 2006

Updated Feb 25 2006

Presently, the following needs to be finished before a "BETA" can be achieved:

• The GUI needs to be finished and integrated with the options data structure
• Physics for robots needs to be finished (specifically, velocity limiting code and non-in-elastic collisions)
• -3, -4, -5, and -6 shots need to be finished, as well as viruses (though viruses may be disabled in the initial release depending)
• Ties need to be coded using the new Tie paradigm discussed here
• The Robot Debugging window and robot mouse selection need to be finished.
• The graphics and engine need to be made thread safe.
• Mutations code needs to be finished (currently Sprotiel is working on this)
• Forward and backward compatible save/load routines for Simulation Settings, Simulations, and Robots. Preferably ascii over binary, except where size is an issue (as in Simulation settings), where some sort of file compression would be nice.

These would be nice, but aren't 100% necessary for the "Beta" label

• Scripts. PY was working on the idea of what they should be, so he should be consulted.
• Error Database. Basically, on an error an automatic report could be sent to one of the MYSQL databases available through our webspace and a notification sent to anyone working on the code automatically. Also, some sort of error viewer inside Darwinbots would be nice, so users could see how many other users reproted the error they recieved and wether or not it's been addressed by the coders yet.
• Bot Database. A way to upload and download bots from a central database from inside Darwinbots itself. Also using a Database as described above (we have 10 of the things, we won't run out :P)
• Statistical tools. This would involve everything from collecting data from the sim (and analyzing it according to proper statistical tests) to building a graph form and deciding how to draw it to exporting the data as per user specs into a spreadsheet program (like Excel). It is prefered that whoever works on this have some statistics background so they know what sort of stats users would want to collect and test.
• The vision testing algorithm is presently O(n^2), as it uses the "brute force" method. See: Vision_algorithm for more inofo. It can be made nearly linear O(n) by using uniform grid cells. see:

This resource which exmines the issue

This resource which describes the implementation and problems associated with it

Collision detection could use a similar technique, though its gains would be complicated by the fact that bots are not uniform in size.

This would mean an absolutely insane boost in speed for large sims, but also would take some work.

• Since graphics are now using OpenGL, some pretty sweet graphics could be made. Admitedly spheres/circles shooting dots and lines at each other doesn't really inspire great art, but I think there's definately potential for some sweet demos. Maybe move it to 3D graphics instead of 2D and use some fog effects. Maybe use a shader.

Long standing feature requests

Anyone who managed to implement these in a way that didn't drastically increase memory and CPU requirements would be a hero in the Darwinbots community.

• Environment Grid - Basically the idea that bots should be able to interact with their physical environment. Things like leave poop behind for other bots to deal with, polute their environment, leave pheremone trails for other bots to follow, etc. There are, unfortunately, some gigantic memory and processing problems that beg for some smart, algorithm-savy programmer to address.

• Metabolism - The idea that bots should be able to generate nrg or use nrg based on their own unique bio-chemistry (or is it darwo-chemistry :P). This involves creating a system (or letting it emerge) of bio-chemical pathways and materials. Closely tied with the Environment Grid and likewise inter-related with the memory and processing problems.

• Specialization and Speciation - The idea that bots should be able to become more efficient as they limit the number of activities they participate in. The primary hurdle isn't in coding it, but in designing the basic system to everyone's desires. It must respect multicellular specialization as well as single celled speciation. Not an easy task.

• Sexual Reproduction - Some way for two bots to, with consent (although 'rape' might have a place as well), produce offspring that robustly intermarries the two parents' DNA.

Contact

If you would like to help with the code, and any of the above sound interesting or do able, feel free to contact Numsgil at Numsgil2002@yahoo.com to discuss your ideas.