Re: SuperTuxKart
Posted: Mon Jan 07, 2008 2:04 am
Hi,
We don't have too much in term of documentation. There is some documentation written in the doc/implementation.txt file, but esp. the physics part hasn't been updated for the new bullet physics. I guess it's 'read the source'
The main difference is that many attributes from TuxKart are still around (e.g. sgCoord m_curr_pos), but are kind of 'read only': the physics compute the new values, and converts the physics results into the plib data structures. This way we didn't had to replace too much code at once, since (e.g.) the AI which is using these attributes still works. If your code is just setting these values, nothing much will happen (or worse: the display will be different from the physics model, since the physics model will not know about the changed values).
Looking forward to hear from you!
Joerg
That sounds very interesting, since it should be portablemichaelth wrote:Well,I just use the udp socket to implement the P2P version and it is easy.
How did you implement it? Send the commands from all players to one computer acting as a kind of 'server' and distribute the position of the karts (etc) back? Or is it more 'distributed', e.g. all karts receive the positions (etc) of all other karts, and do their own physics computation? Or all computers receive all commands, or ... ?if you can provide me a easy way to understand your code,and the P2P version of it can be finished quickly.
We don't have too much in term of documentation. There is some documentation written in the doc/implementation.txt file, but esp. the physics part hasn't been updated for the new bullet physics. I guess it's 'read the source'
We have rewritten a large part of the TuxKart code, but the overall structure is somewhat similar. It basically depends on how you implemented it: if all computers are doing their own physics computation, it would be a bit more difficult to keep them synchronised (in bullet terms: 'remote' karts would become kinematic objects so that you could can set the new position you are going to receive, and you have to make sure that the positions are in synch (otherwise minor difference might cause a crash to happen on one computer, but not on another one)). If you are sending the commands to one computer acting as a server, that should be quite easy to port.Is your code mostly like the TuxKart?I means use the same Kart Class,the same control method,the same Global variables and the same GUI interface.And if your program's main flow as same as the TuxKart,the network job may be very easy.
The main difference is that many attributes from TuxKart are still around (e.g. sgCoord m_curr_pos), but are kind of 'read only': the physics compute the new values, and converts the physics results into the plib data structures. This way we didn't had to replace too much code at once, since (e.g.) the AI which is using these attributes still works. If your code is just setting these values, nothing much will happen (or worse: the display will be different from the physics model, since the physics model will not know about the changed values).
That would be great - let me know what I can do to help you! Contact me at hiker at luding dot org to discuss the details. I would be happy to help you porting your code - getting network multiplayer would be great!I always be intersted in networking a funny game.
Looking forward to hear from you!
Joerg