Code center > Darwinbots3

P2P Internet Mode

<< < (11/12) > >>

Numsgil:

--- Quote from: Cyberduke ---
--- Quote from: EricL ---You are assuming the thing Nums is calling DB3 is a project that will someday supplant the current code base  That is a big assumption, one that is not shared by everyone.  It is much easier (and more likely to happen) that I simply port the current code to VB2008 to get threads and move the code base forward from there.  I have a version limping in VB2008 as we speak.
--- End quote ---
Ah now that’s interesting you say that, Yes I made the assumption (again) that since the wiki points DB3 in the direction of Nums C# page and you said you where not going to be continuing the project in the long term that Nums C# version was going to eventually become the next generation of Darwinbots

--- End quote ---

Just to be clear, I don't think most users care what the program is coded in one way or another.  Eric has a great vested interest in the current code base, so the "That is a big assumption, one that is not shared by everyone" is probably code for "That is a big assumption, one that is not shared by me".  From my experience going from 2.37 to early 2.4, stability is more important to end users than features, so if the C# version is always buggier than the current 2.4X code, it'll never catch on.  If it's more stable, it'll catch on.  Part of the problem with the current version is that if something breaks it's not always immediately apparent, since most of the time people aren't using the program so much as writing bots to use the program.  So bugs can sit there for a loooong time.  Which gives the impression to users that the program is buggy, and is an impression that I think isn't too far off the mark.  So I think in this regard there's a lot of room for improvement and thus a lot of leverage for a hypothetical new C# version to convert current users.

With extensive unit testing and a highly modular design I'm hoping bugs will be fewer and further between, and less likely to crop up again in the future (a big problem with the current code base is that it's so brittle that the same bugs seem to get fixed again and again and again).  But I've been working on it a long time and progress is slow since I keep backtracking when something doesn't actually work (lots of work on physics that had to be abandoned, for instance), so it's entirely possible for DB3 just to be vaporware and never realized.  It's also possible it'll get to a somewhat finished state and it'll be too buggy to compete with the current, semi-stable version and all that work will be for naught (though I don't think this particular scenario is likely, again because of unit testing and proper design).

Another scenario is that, assuming Eric can successfully migrate the current code to VB 2005/8, and thus allow .NET interop, the two projects might blend, with newer parts slowly supplanting older parts (or not, depending on their individual merits, of course).  But I'm not holding my breath

Really, it's sort of appropriate, since those are the options for new species to supplant older species.  Either one dominates the other or they interbreed (or they form separate niches.  I guess that's possible, too).  Natural selection will eventually choose a program as the winner in whatever happens, as is entirely appropriate, I think.

So just to reiterate, there are really two versions you could work on.  The current version is in VB, and is used by lots of people.  You can do things and have feedback from end users in very short order, which is a neat experience.  A future speculative version is in C#, and while it might never actually see the light of day, it's far easier to work in and with (unit testing again, plus the C# is easier to understand than VB if you come from a C++ background), and you don't have to worry about backwards compatibility.  Any contributor is free to chose either (or both I suppose) to work on.  All so far, other than Eric, have wanted to work on the C# version.  Admittedly most burn out after a few days or maybe a week or two, with little to show for it, but there you are.  I have no ego to be bruised in this regard, you're free to chose as you see fit

Cyberduke:
Well yes ok I realise my wording of “going to eventually become the next generation” was a little strong, it was meant in the context of “has the intention of becoming...” due to the perceived wind-down of the current 2.4X code base (formed from comments on the wiki and forums).  
I am familiar with concept of vapourware having worked on a few Half-life mods in the past.

I didn’t appreciate however that both code bases had the intention of continued active development and that “DB3” was actually a branch. Not that it makes a huge difference I suppose, nothing wrong with a bit of healthy competition, but with only two main developers branching off does seem a bit of a waste.

I would be unsure of my competence editing/writing VB6 code and to be honest not that willing to learn, so I don’t mind helping with any .Net work though personally having no current investment in either project would be more tempted by the C# clean re-write, if there is support for one.

Numsgil:
There's a bit of a history here, actually, that will at the very least provide some backstory.

Originally I was the only active developer (I took over from PY.  There was very little overlap between the two of us working on the program at the same time).  After a handful of versions, I spent the summer after my sophomore year at University to implement some brand new things.  New physics based on springs that was a vast improvement over the old system, which involved lots of bail wire and duct tape.  (This is largely the physics the current version uses, I believe.  Eric has done some tuning and such, but the core is probably pretty much what I built that summer).  I also revamped the DNA to be less structured.  It used to be that genes were rigidly defined as a cond-start-stop triplet.  I spent some effort to allow for more complex or even nonsensical DNA.  There were lots of other changes, too, but those were the big two.  This new version was packaged as 2.4

2.4 had some problems.  Lots of problems, and lots of bugs.  It was really almost entirely unusable.  2.4 was really a failure on my part, having underestimated the amount of time it takes to go from a "feature complete" milestone to something that's stable and ready for end users (and lacking a lot of experience coding for an audience at all).  School had started back up and I was extremely busy and frustrated with the VB code.  Not just fixing bugs that I really should have caught in the first place, really the whole way the language worked.  It made trying to implement various "advanced" features exceptionally hard (there was an abortive attempt at a bucket system to sort bots by buckets (eg: sectors) for faster collision and vision code that was made much harder by the limitations of the language and my ability to adapt to them).

So I stopped working on the VB version, and most people continued to use the older 2.37 version.  Instead, I started porting sections of the code to C++.  This wasn't a rewrite, it was very close to a straight port.  I fixed a few bugs in the process as I worked through the code, but the C++ version would have looked very familiar to someone working on the VB source.  You can probably find the C++ version in some repository somewhere linked on the wiki.  It got pretty far, but I ran in to a brick wall with the physics.  I wasn't using any external libraries or anything, it was a rigid body simulator (rigid bodies being limited to circles exclusively) I'd implemented entirely on my own.  What I wanted to do with multibots just didn't work with the new version (or old version for that matter).  Plus there were some threading issues.  Also, the code, being almost a direct port of the VB code, was still a pain to work with.  Something like the robot class was thousands of lines of convoluted code, with lots of interdependencies between disparate classes (the shots class was a friend to the robot class, and vice versa).  So I gave up on the C++ version and spent some time working through how to actually achieve the sort of physics I wanted.  This was the end of my junior year at University.

Sometime during this process, Eric joined the community and decided he wanted to try and fix issues with the 2.4 source, since it did have some nice features even if it was a bit buggy.  After a few months of effort he was able to get even the hardliners to move from the 2.37 version to the new 2.4X version.  And he's been supporting that version ever since(roughly two years), adding features and fixing bugs as people suggest them/find them.

I, in the mean time, decided to start over with a complete rewrite from scratch.  Because of its similarity (in a good way) with VB, I chose to try again in C#.  To get the ball rolling I wrote about 75% of a DNA module in C# (actually wrote it twice.  The first time to get a taste of the language).  This was right when I first learned about unit testing (maybe a year and a half ago), so the vast majority of the DNA code is unit tested and, I think, pretty stable and bug free.

Then I spent about 8 months working on an entirely different project (A 3D version of something like SimEarth).  Obviously not a lot happened with Darwinbots during that 8 months.  Eventually Darwinbots coding started to interest me and I put my other project aside.  After some abortive attempts at using existing libraries (most didn't last more than a few weeks) I thought I'd try my hand at building my own physics engine again.  Unfortunately, most of what I wanted to do had never been attempted before, so there was a lot of original research on my part.  That started about a year ago maybe and continued until maybe 3 months ago.  During the 4th of July weekend I scrapped the physics work I was doing and concentrated on getting re-acquainted with my code, reorganizing the file structure and fixing various annoyances with Visual Studio project files and temp directories and such.  Lots of meta programming kind of stuff.  I got my present job as a junior programmer for a video game company last March.  When you program 50-60 hours a week for a job it's hard sometimes to drum up the mental effort to work on part time coding projects, so progress has been... glaciatic.  I've put maybe 100 hours of work in during the last 3 months (though I finished a major milestone last week, so I can relax and go back to 40-50 hour weeks for a while.  Plus I have a 3 day weekend coming up which I'll probably spend, at least in part, working on Darwinbots).

During the time I was either not working on Darwinbots or working on physics, Eric's been supporting the 2.4 code.  He takes a few months off during the summer, but otherwise puts a lot of time and effort in to supporting the current version for users.  He tends to work slow and steady, where I've always been of the burn-out super nova explosion of coding school, where I spend about two weeks doing a massive sprint of thousands of lines of code then do nothing for several months   So Eric's understandably a little skeptical of any claims I make.

Heh, that's a little long winded, but that's how things ended up where they are.

EricL:
A very fair summary.

Understand that my skepticism regarding DB3 is not a statement about Nums coding skills or tenacity or anything like that.  It's just that I've spent 25 years in the software industry and in that time I've formed some opinions about how to move code bases forward.  Total re-writes never work.  It  sounds great to start clean and do things right from scratch "this time around" but the details and difficulty are always underestimated.  We tend to underestimate how much is really invested in the older code base, all the little things w.r.t. usability or features or hard-won lessons about the way things should work that are embedded in the code and present barriers to people moving.  It's not the rocket science core stuff that kills projects.  It's the million little simple things that add up to a usable program.  This is why is was so difficult for people to move to 2.4 even long after the basics were in place.   Sure, you can get there if you throw enough hours at it for long enough (I did) but in my experience, that is always the most expensive route to take.  

Understand that I've probably doubled the number of lines of code since I took over.   There are a lot of details, a lot of features, a lot of nuances.  Even were DB3 working today, it would take a long time to get to critical mass such that people could move.  I prefer the incremental approach.  One rule I learned the hard way and have followed in the large software projects I've managed is that you never, ever change more than 30% of the code from major release to major release.  You can do re-writes, but you do it of individual modules.  You move forward, incrementally, maintaining stability while you do.  Not doing so is the fastest path to vaporware.

So, I'm skeptical not only of "DB3" but of any project that does not start from the current code base and move forward incrementally.

EricL:

--- Quote from: Cyberduke ---My original thinking was really coming from the direction of combining multiple sim instances to achieve a distributed computing effect, in order to provide a larger more diverse environment for evolution to act upon.
--- End quote ---
This is exactly why (well, one reason at least) I implemented private teleporters.  Unlike the IM teleporter, inbound private teleporters do not randomly distribute incoming bots across the field.  Bots stay where the teleporter is.  It's a doorway for incoming bots just like outbound teleporters are an exit.   They can be made stationary, perhaps surrounded by shapes, to create different fiefdoms or whatever other effect you want or they can be made to drift, ignoring or respecting shapes as you like.  They can filter bots to restrict or allow veggies or corpses and such.  You can have multiple pairs connecting multiple sims in whatever topology you want.   And, it is on my list to unify shapes and teleporters to provide greater flexibility on size including making entire field edges themselves act as teleporters.  So you see, we think very much alike here...

Navigation

[0] Message Index

[#] Next page

[*] Previous page