Physics, AI, Networking, etc... support

Aug 23, 2007 at 1:49 AM
Edited Aug 23, 2007 at 1:56 AM
Hi,

You think about integrate a new service, like a rigid body, AI? You will use another framework like a http://www.codeplex.com/xnadevru to physics and http://www.codeplex.com/animationcomponents to animation using shader? Or you don't make anything about this?

why you don't crete a service basic interface inside of core engine like Elephant.Core.Services.IService
Elephant.Core.Services.IInputService
Elephant.Core.Services.IPhysicsService

All interfaces must implements basic IService interface, to allow inicialization like a plugins. You wolud put each service in a separated project.


Sorry my poor english.
Coordinator
Aug 23, 2007 at 11:30 AM
Hi,

Implementing some basic components wrapping functionality of, for example, a physics library is definitely a possibility and likely a good idea. However, as of now I prefer to have Elephant and Elephant.Utility as "lightweight" as possible, meaning they will only contain the most standard stuff.

As for the idea about InputService, I have actually done that and was using such a service for my editor application (it had a property letting me know if focus were on the window or on a dialog). But using such a service requires that the user always adds this service, and always uses it in his components instead of just polling Mouse/Keyboard.GetState() directly. If only there were a way of hiding/replacing Mouse/Keyboard it would be way more plausible having such a service.

I'll mark this as a work-item, to keep myself reminded. :)
Coordinator
Aug 23, 2007 at 11:31 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 23, 2007 at 2:11 PM

shrt wrote:
Hi,

Implementing some basic components wrapping functionality of, for example, a physics library is definitely a possibility and likely a good idea. However, as of now I prefer to have Elephant and Elephant.Utility as "lightweight" as possible, meaning they will only contain the most standard stuff.

As for the idea about InputService, I have actually done that and was using such a service for my editor application (it had a property letting me know if focus were on the window or on a dialog). But using such a service requires that the user always adds this service, and always uses it in his components instead of just polling Mouse/Keyboard.GetState() directly. If only there were a way of hiding/replacing Mouse/Keyboard it would be way more plausible having such a service.

I'll mark this as a work-item, to keep myself reminded. :)


Hi,

i agree with you about InputService. The architecture aggregation based simplify, but i have a question about this, several time, we need detect mouse collision with mouse, you think in simplify this work? Or you will create a Gui service like a http://aaronkm.blogspot.com/index.html?