Darwinbots 3 Progress

[Moonfisher]

Branching a project this size can be a real pain if you ever plan to merge again.
I would definately recommend committing to trunk and just run a lot thorough tests before commiting. Unless it's for a mod you want to keep seperate.

[Numsgil]

Yeah, merging doesn't seem to be SVN's strongpoint.  We used perforce at work, and that was about the only thing I liked about it.  It could merge pretty intelligently.

[Prsn828]

IMO, any sort of mod should be able to be incorporated as an option.  The idea behind DB3's coding design is to allow for interchangeable modules to be used.  What this means is that you could choose, for example, from two different physics engines, or perhaps add support for neural-network bots by simply adding in the new module that provides the support.  Another case is the use of different graphics implementations.

Actually, this is one of the primary features of the DB3 code.


Also, here is a quick screen-capture showing the first tab for the settings window, as well as all the pop-ups you can open from it (except for file selection windows):

[attachment=1183:Settings...een_cap1.bmp]

[Moonfisher]

I'll be happy as long as it's object oriented.
Made a neural network mod for the current source (Or I think it was 2.43.h or something) and it was a real pain just finding my may through the source.
To make a long story short the current source is a spagetti monster and it took me a lot longer than expected to do the things I wanted, had to make changes in all sorts of places.

So the more generic DB3 is the happier I'll be
For instance it would be very nice to have a class for serializing a deserializing, and it would generaly be nice to be able to just inherit a class and overload whatever you need to make your mod.
A mod should never (Or atleast very rarely) need to change the base classes.
This way mods could also easily be developed as a branch and merged with trunk when ready (Provided the trunk hasn't changed too much). And if theres a common interface for adding a mod then they could just be enabled from the gui instead of having to build a new drop.

And as DB3 grows it would also be very nice if there where some guidelines for development, atleast a bare minimum code standard and some good tips on making propper OO code. And code reviews would be great if it's actualy possible to uphold, since theres a lot of less experienced programmers who may be checking in code that will cause a lot of trouble in the long run. If the code standard isn't too strict then a code review shouldn't take long, just enough to make sure the code or it's general structure doesn't cause problems in the long run.
The thing is, you can't just make the whole source generic enough to support any new features that may come that would take too long and in the end it would just end up being harder to read the source and harder to tell what it's real purpose it  So the structure needs to be expanded as the source grows, and some people may not know exactly how to do this. So if it's possible to uphold a quick code review for new source it would probably save us a lot of trouble in the long run. Possibly ask people to submit a simple class diagram or update the apropriate one, with a brief explanation of what has changed, this way it would be easier to tell right away if it would be enough to just give this new code a quick glance of if you need to read it more thoroughly.
On a not so unrelated note, does anyone know if theres a free version of FogBugs or maybe another similar program we could use for free ? Would make some of the things I'm suggesting a lot easier to manage.

[Prsn828]

I'll be happy as long as it's object oriented.
Made a neural network mod for the current source (Or I think it was 2.43.h or something) and it was a real pain just finding my may through the source.
To make a long story short the current source is a spagetti monster and it took me a lot longer than expected to do the things I wanted, had to make changes in all sorts of places.

So the more generic DB3 is the happier I'll be
For instance it would be very nice to have a class for serializing a deserializing, and it would generaly be nice to be able to just inherit a class and overload whatever you need to make your mod.
A mod should never (Or atleast very rarely) need to change the base classes.
This way mods could also easily be developed as a branch and merged with trunk when ready (Provided the trunk hasn't changed too much). And if theres a common interface for adding a mod then they could just be enabled from the gui instead of having to build a new drop.

And as DB3 grows it would also be very nice if there where some guidelines for development, atleast a bare minimum code standard and some good tips on making propper OO code. And code reviews would be great if it's actualy possible to uphold, since theres a lot of less experienced programmers who may be checking in code that will cause a lot of trouble in the long run. If the code standard isn't too strict then a code review shouldn't take long, just enough to make sure the code or it's general structure doesn't cause problems in the long run.
The thing is, you can't just make the whole source generic enough to support any new features that may come that would take too long and in the end it would just end up being harder to read the source and harder to tell what it's real purpose it  So the structure needs to be expanded as the source grows, and some people may not know exactly how to do this. So if it's possible to uphold a quick code review for new source it would probably save us a lot of trouble in the long run. Possibly ask people to submit a simple class diagram or update the apropriate one, with a brief explanation of what has changed, this way it would be easier to tell right away if it would be enough to just give this new code a quick glance of if you need to read it more thoroughly.
On a not so unrelated note, does anyone know if theres a free version of FogBugs or maybe another similar program we could use for free ? Would make some of the things I'm suggesting a lot easier to manage.

First and foremost, what in the world is fogbugs?

Second, yeah, once I know what it is, I say there is a 90% chance I can get my hands on it (or something like it).

Third, you should download the source and take a look yourself.  Almost all these suggestions are already (more or less) there.  We also use (although I need to start catching up with this, since I have slacked off a little) Unit Testing, to ensure that all classes do what they should, how they should, including throwing exceptions and the like.  We also want to use a code profiler, but can't find one for free (well, actually, I think even something under $100 would be acceptable at this point.)

Honestly, if anyone has been making poorly coded classes, I am probably the culprit   I am still learning the ins and outs of C#.  On the other hand, I am also probably the most capable of identifying and correcting errors, so I redeem myself quite quickly (and I, unlike many programmers, have no problems with people rewriting my code in better, or clearer ways.)

Actually,  might you be interested in joining the project?  I could use a sidekick in my quest to unravel the workings of Numsgil's mind.  He leaves me hanging a lot on what needs to be done, and I don't want to make any executive decisions on my own (he was the originator of this whole project after all).  Even if you don't want to do the coding, you at least seem to be thinking along the same lines, so it would be helpful to have you available for consulting (not that big questions won't end up here anyway.)

Getting myself back on track; we did indeed attempt to make all of the classes that one might override easy to extend.  For instance, the robot class contains two objects of importance, a robot body, and a brain.  One could extend the robot class to have multiple bodies or brains, or could extend the body or brain class to change the shape of the robot, or the behavior.

Also, there is an IShape interface that can be used to describe any shape in the simulation.

One final thing: when writing the code for the mask over a robots memory, a clever thing occurred to me.  I realized that in later versions it might be useful if, for instance, on bot in a multibot could apply its mask over the memory of one of its connected bots, effectively allowing the connected bot to act using data from the bot whose mask is being applied.  Sort of a "If I were you, this is what I would do" situation, but in this case "I think I am you, so now I will do that which I would do if I were you".

[Moonfisher]

Ehm, my bad, it's spelled FogBugz :
http://www.fogcreek.com/FogBUGZ/

It's for managing tasks and documentation in a project. It works sort of like a wiki, you form a case for something that needs to be done then assign it as a task to one or more people. Then you'd usualy assign the task of code review to someone else. Point is links are formed to create a wiki like network in between related areas, some are made automaticaly but you'll also want to add your own, both for resources used during development and documentation and such. Kinda hard to explain, but I think theres a good introduction video on the site to get an idea of how it works.

Haven't tried a code profiler before, but I'm pretty sure it can't replace code reviews, it's better than nothing ofcourse, but if poeple are willing to spend the extra time then code reviews are probably a lot safer.
And if we have strict tests it'll be easier to review the code fast and there will probably be far less that needs to be corrected. And when doing a code review and you find yourself having to fix a lot, then don't think of it as extra work, think of it as saving a lot of time by fixing this before it becomes a problem. Its also a great way to learn, even for those who find themselves teaching everyone else (Since teaching is the best way to learn). And who knows it could help draw more developers if people feel they're making real progress as a programmer.

And I think I should have the time to look at the project, I can start by going through the wiki to see how far you guy's are along. That and actualy get the DB3 source and Visual studio
But got some things I have to see to first...

And I'm not sure it's a great idea to allow a bot to just override all the memmory of another bot, that would be a realy powerfull weapon. Maybe if the tie has to stiffen first it wouldn't be a big issue...

[Numsgil]

To make a long story short the current source is a spagetti monster and it took me a lot longer than expected to do the things I wanted, had to make changes in all sorts of places.

That's flying spaghetti monster

And as DB3 grows it would also be very nice if there where some guidelines for development, atleast a bare minimum code standard and some good tips on making propper OO code. And code reviews would be great if it's actualy possible to uphold, since theres a lot of less experienced programmers who may be checking in code that will cause a lot of trouble in the long run.

We have a coding standard (meaning mostly a naming standard) that we've adopted from here.

I don't have any formal code reviews or proper OO guidelines.  Mostly I'm hoping we all just keep an eye on each other and red flag when things look fishy.

On a not so unrelated note, does anyone know if theres a free version of FogBugs or maybe another similar program we could use for free ? Would make some of the things I'm suggesting a lot easier to manage.

There's a Trac that comes with my SVN account we can use.  I just have to figure out the permissions so that it's publicly visible.

[Prsn828]

And I think I should have the time to look at the project, I can start by going through the wiki to see how far you guy's are along. That and actualy get the DB3 source and Visual studio
But got some things I have to see to first...

Let me be blunt.  We are very close to something that can actually run.

Let me be blunt again.  The wiki is nowhere near up to date.  In fact, the only updates (for the progress of the DB3 project) have been to the guidelines for the M1 version, and that was only out of necessity when having to rethink the bot design.

Like I said, we could always use a hand.  Just because it is almost usable doesn't mean it is almost complete.  Actually, this will probably be worked on for many years to come (hopefully it will be workable for much longer than DB2).

And I'm not sure it's a great idea to allow a bot to just override all the memmory of another bot, that would be a realy powerfull weapon. Maybe if the tie has to stiffen first it wouldn't be a big issue...

Of course, only bots in the same organism would be allowed this ability (and maybe virus?), as it is definitely powerful.  I was also thinking it could be invoked by the bot that will be masked by targeting in some way the bot whose mask will be used.



Also, as far as a profiler goes, what it would do is tell us how many times each line of code was executed, and how long the execution took.  This would be used mainly as a way to find possible speed-bumps in the DB3 program highway (well, metaphorically).  We use unit testing to find most of the errors, and when errors are found, we figure out the solution on our own.  No program currently in existence can do much in terms of fixing another programs source code .

As for the FogBugz program, we could easily build that into the internet mode of the DB3 program.  All it is is a glorified, automated message delivery and sorting system.  I could write the whole thing over in Java in about a week if I wanted to (but trust me, I don't want to).

[bacillus]

I had a look at the repository, and I'm pleased to see so much progress has been done. If there's anything that you want implemented in particular, I'll be keen to get back into DB3.

[Numsgil]

Sure, that would be great.  Most of what's left is really technical, though, so it might be a hard nut to crack.  I'll try my best to help you figure out any of these tasks.  Here's some thoughts:

1.  Set up the graphics code to draw ovoids (distorted circles).  I'd like to do it through a shader so the edges are smooth and it doesn't use any more vertices than a square.  A shader is basically a special computer language to program the graphics card with.  You could copy the shader code I have for drawing quads (it's pretty simple), and modify it to use the texture coordinates to draw a circle in texture space.  Or even combine squares and circles in the same shader.

2.  There's a demo app that draws shapes so I can test the graphics capabilities.  There's a menu on the side of the window which isn't really set up, but the idea was that it would let you add shapes to be drawn at run time.  The work would be playing with the code to allow "picking" (detecting that the user clicked on an object), picking and then dragging an existing object, adding new objects at the mouse cursor, resizing objects by dragging vertices, and setting up the interface to let you add a shape into the draw field.

3.  Set up the actual .exe.  here's a crude UML of how the modules might fit together (I think the arrows are backwards maybe).  Basically all the modules get packaged together into a single core.dll file, with version numbers attached to the modules.  Like Core1.0.dll might be the code for Darwinbots3 1.0.  The .exe is designed to do absolutely nothing except search for core.dll files, and dynamically load them and pass command line arguments into them.  The idea being that a new version of Darwinbots just has to add a new core.dll file and not overwrite any existing files.  The Darwinbots3.exe will determine which core.dll is the latest version and load it.  And with any luck we should be able to use the same core dlls with the XBox and just not call the unsupported features.

4.  Implement a GDI graphics module.  Right now the graphics system is set up so it can dynamically choose the graphics API to use.  You'd just need to write an implementation for GDI (the graphics API used to paint windows and stuff in C#), and maybe modify some of the Graphics.Core code as needed.

5.  We still need to figure out code coverage.  I've been putting it off.  Basically all the options either suck or are expensive, and one of my goals for Darwinbots is to make sure all the needed tools are free.  You'd probably have to find one of the sucky free ones (there was a free, early version of NCover on sourceforge), and hack on it until it worked right.

6.  You could work on the physics.  But it's really quite math intensive.  The good news is that there's a free book online that explains most of the math I'm using (I could at least point you to the right chapters).  The bad news is that the book assumes a certain level of math that most people don't have (need to be comfortable with calculus and linear algebra (ie: matrices)).

7.  You could try setting up an XBox exe if you have an XBox.  You'll also need a creators club membership, which can be expensive (like $50 for a few months, or $100 for a year).  Though microsoft also tends to give out free membership for various competitions and the like (check out Dreamspark).  Mostly just setting up the project.

8.  Or you can look at milestone 1 and see if anything there looks interesting.  Quite a bit of it is actually done already, though.

[Prsn828]

Ah the physics...

Well, I suppose I should commit what I have of it so others can build off of that.

I'm positive it still compiles because I hate not being able to compile after finishing a section of code, so I will send what I have done.

[bacillus]

I would probably be best at getting the physics engine set up. I've been writing one myself, and although it's still primitive compared to the stuff you posted on the wiki, It'll give me a background on how the functions are derived.

 To be honest, C# is new territory for me. I understand how the syntax works, but calling up specific functions like UI and stuff like that is a bit of a mystery for me. I started an unrelated project to familiarize myself as I go along...

[bacillus]

I'm trying to complete the collision physics code atm, but a few questions popped up:
1-Is the collision normal a positioned vector perpendicular to the collision interface, or is it measured from the center to collision interface?
2-I'm guessing j0 is equal but opposite for both mass systems. Anything wrong with this assumption?
3-Is there any auto-complete function in C# Visual Studio?  

[Numsgil]

1.  Suppose you have a collision between a vertex and an edge.  The collision normal is usually perpendicular to the edge.  In more convoluted cases it's just a best guess.  For the collision response code, assume that you are given the normal as part of the input into the function.

2.  This is technically true.  However to allow for the system of equations to be solved easily you assume j0 is equal to the impulse along n, and then just remember to negate it when you apply it to the second body.

3.  You mean like intellisense?  There should be.

So I'm guessing you found this page, right?  The case of one-on-one collision should be not too hard.  Make sure to add a bunch of tests for it for weird cases (0 or infinite mass, etc.).

Multiple collisions is more speculative.  This is really something I've figured out on my own just from first principles, so I'm not totally sure what I'm doing

[bacillus]

I see how you got that from FP, but I think it's just a case of each object resolving each of its collisions as though they were different single collisions. Remember that the other masses can be reduced to a single mass as they are all external of the concerned mass.

Okay, so j0 represents the scalar exertion upon an object, and n the direction of change, so therefore should have a magnitude of 1. mass/moment of inertia convert the 'force' into an 'instantaneous' acceleration/torque. j0 is acting perpendicular to the center about a point, eg. a tangent.
Okay, that makes sense. But is the code for calculating the normal/tangent/impulse already in place?

EDIT => Are the Azimuth files corrupt? I've tried to update several times at revision 304, but TortoiseSVN still marks it as a deprecated version.