Code center > Darwinbots3

SVN Source

(1/2) > >>

Cyberduke:
Is the code in SVN (Revision 22) up-to-date?
What is the plan for modularizing the different components?

How about a (and I use the term loosely) plug-in architecture,
Create a physics interface and a visualisation interface etc.

So you can just build each module in isolation working to an interface. Then at run-time, load in the relevant assemblies whereby you could swap between different implementations on a whim.

Note: This would also allow for self-patching, your boot module can check the versions of the assemblies download and patch them before loading and running them. (If it found an update for itself it would have to restart itself then start over)

The simulation module would implement an interface which exposes enough information such that any GUI implementation can be passed a reference to the simulation and draw the current state of the simulation (in any style it wishes), retrieve basic global stats and data for graphs etc, the job of interpreting and expressing the data in some useful form would be down to the GUI implementation. That way we could just build a very quick and dirty GDI+ display for testing that would suffice for now.
The simulation itself would have a reference to an object implementing the physics library interface.
(Obviously existing physics libraries would need an adapter to adhere to our interface) If you did want to build your own then it can implement that interface directly.

I think this is basically what you had in mind, but I couldn’t find anything laying things out in detail.

Also this way you *could* more easily run everything in its own thread thus totally separating the running of the simulation and the rendering of the simulation’s state, this also means that your graphics card’s performance does not cap your ‘cycles per second’ potential, you could be running your simulation at 50cps and rendering it at 30fps, obviously it just means that it would skip drawing some cycles. And conversely simulating at 5cps and still render at 30fps repeating the drawing of some cycles (but would appear much smoother to the user if you were also rendering superfluous data like information about the cell the cursor was over for example)

Numsgil:
It's not up to date.  I've done some work on it since that lives in a new repository (moving around lots of files and setting up various folders).  I'll get the wiki up to date Monday hopefully.

Yeah, my present thinking involves interfaces like that.  I haven't written it up anywhere.

There was an abortive C++ version I worked on a few years ago that worked like that: the graphics thread ran at some fixed FPS, and the core engine thread ran as fast as it could.

Cyberduke:
I have just been reading about minerals and 'flavoured' smells, bots using the shells from corpses, etc
Will the new wiki updates contain a list the currently agreed features?
Or is it all still very much ‘up in the air’?

Numsgil:
Everything's still pretty much up in the air.  I have some feature goals I enumerate, look here and here(at the end, under long standing feature requests and feature list for 3.0).

The what-I-have-at-the-moment code can be peeked at here.  At the moment I'm stuck trying to learn XSLT to transform NUnit's console output into something readable.

Hopefully I'll update some wiki pages when I have a free second, but truthfully I'm pretty exhausted so things outside of work, food, and sleep aren't high priority

Cyberduke:
Well, for now until I get better acquainted with the project and while you’re still mulling over some of the fundamentals, I’ll work on some of the more generalised aspects of networking the project, and have a play with creating an GUI that can auto patch, load in other modules and connect to the network, browse a bestiary etc.

I think we will have to create two lightweight GUI  ‘clients’ one for windows and one for the X-box due to the differing requirements of the UI and features we could actually use, including differing approaches to networking, aka X-box Live (unless you’re a large company and can get on MS’s good side), everything behind these lightweight UI’s  would remain the same. For now we would just work on the Windows client and forget about the X-box, when we have something up and running, we can think about how an X-box version would work. Just keep everything in managed code.

I am still debating whether or not to create a custom XNA GUI or use ‘winforms’ with a handle for XNA, unfortunately doing so actually requires scraping a part of the XNA code base (the ’Game’ class) and requires you to write your own Graphics Device implementation.
Of course if you ever wanted to get this running on an X-box in any shape or form you have no choice but to write your own basic GUI anyway (There are number of GUI libraries out there though).

And on the subject of GUI’s I thought It would be cool to have separate mini environments with their own settings accessible from the main UI you could use as ‘holding cells’ So when you feel like playing god in a evo sim you can drag and drop some bots in to a ‘refugium’ to feed them up or get them to mate, or a ‘ring’ to have one-on-one fights.  

Navigation

[0] Message Index

[#] Next page