I’m certainly not a multiplayer expert, but as far as I know physics is a tricky thing to do over network. In a perfectly deterministic game world, all you need to send between client and server is the initial game state and all actions that are performed by the players (user input).
While physics and game logic should in theory be deterministic, they in fact aren’t as soon as a variable time step is introduced during simulation. Duality’s update logic is based on a variable timestep, as well as its physics simulation – so you’ll have to keep an eye on client and server sync regularly.
You can also activate fixed timestep physical simulation in Duality. You’ll find the setting under the “Settings / Application Data” menu in the editor. But be warned: Even though physical simulation will now be deterministic on one machine, as far as I know, this does not hold true for different machines in .Net due to floating point calculations probably being performed differently.

I’d suggest googling a lot before beginning. You should be able to apply any knowledge you find concerning XNA / Farseer Physics to Duality as well.

Regards,
Adam

And i was planing to use Duality or XNA. I wold prefer duality because it has nice editor and stuff that i find very helpful.

Do you have any general idea how to pull that off, physics and multiplayey?

Thanks

klar, dein Nickname sagt mir noch was. Was StarTrade angeht muss ich dich aber leider enttäuschen, da ich nach so vielen Jahren mich leider erst selbst wieder einarbeiten müsste, um dir die Frage beantworten zu können – und dafür fehlt mir gerade (hauptsächlich studienbedingt ) die Zeit. Da musst du wohl selbst ein wenig Forschungsarbeit betreiben

PS: Nächstes Mal verwende für sowas besser das Kontaktformular unter “Contact”, thematisch passt dein Post hier ja nicht wirklich hin

I think a very nice control would be a DataGridView that looks exactly like the PropertyGrid (at least except for the property selection column), to fall immidiately into a mainstream accept of visual style, but allows custom adding of properties by any non-marked-up class. And which handles basic types, like for example Color to pop up the full ColorDialog, as it’s a real drag that does not show on the PropertyGrid.

Anyway, thanks for the code!

Component based ftw

Never heard of the Unity 3D approach -> reading.

And major props at your reaction time btw oO

An alternative would be not having any Program class or even Main function as all the code a user needs to write will be located in custom Components or classes directly or indirectly triggered by engine-wide events. The engine would load the users code as a .dll file, then some general .ini data followed by the initial game scene. That game scene may be a main menu or intro. In this approach (Check out Unity3D, that’s pretty much it) the main device for developing the game is the engine’s editor, although strongly linked to the users IDE of choice.

It might also be a combination of both. I haven’t spent much thought about that yet as it doesn’t yet affect any design descisions.

But ofcourse that has to be proven by tests.

A question in general (as I’m not that experienced with engine design and c#):

How would a Programm class in your Engine look like?

I would have a construct like (btw is there a code tag here?)

[code]
namespace MyGame {
class CoolGame : EngineGame {

public void Main(){
//blabla
}

}
}
[/code]

With OpenTK EngineGame would be GameWindow or some engine class inherited from it. The rest of the engine would be used like Physics.DoStuff().

Whats your opinion on that?

Thanks, very interesting blog and sry for the very long comment ^.^