headers
John Edward | 6 Feb 2008 14:12
Picon
Favicon

Draft paper submission deadline is extended: SETP

 

SETP-08 Draft paper submission deadline is extended

 

The 2008 International Conference on Software Engineering Theory and Practice (SETP-08)  (website: www.PromoteResearch.org ) will be held during July 7-10 2008 in Orlando, FL, USA. We invite draft paper submissions and deadline for submission is extended until February 19 2008 due to several requests from the authors.

 

The conference will be held at the same time and place where several major events (please see below) are taking place. The website contains more details.

 

Sincerely
John EdwardT>

 

 

·         International Conference on Artificial Intelligence and Pattern Recognition (AIPR-08)
·         International Conference on Automation, Robotics and Control Systems (ARCS-08)
·         International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-08)
·         International Conference on Enterprise Information Systems and Web Technologies (EISWT-08)
·         International Conference on High Performance Computing, Networking and Communication Systems (HPCNCS-08)
·         International Conference on Software Engineering Theory and Practice (SETP-08)  
·         International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-08)

Looking for last minute shopping deals? Find them fast with Yahoo! Search. 
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 0 comments |
headers
John Edward | 12 Feb 2008 04:22
Picon
Favicon

SETP-08 Draft paper submission is deadline is just few days from now

Dear Colleagues and Friends

 

Kindly share the announcement below with those who may be intereste d: thank you in advance. 

 

Sincerely

John Edward

 

SETP-08 Draft paper submission deadline is just few days from now

 

The 2008 International Conference on Software Engineering Theory and Practice (SETP-08)  (website: www .PromoteResearch.org ) will be held during July 7-10 2008 in Orlando, FL, USA. We invite draft paper submissions and deadline for submission is extended until February 19 2008 due to several requests from the authors.

 

The conference will be held at the same time and place where several major events (please see below) are taking place. The website contains m ore details.

 

Sincerely
John Edward

 

 

·         International Conference on Artificial Intelligence and Pattern Recognition (AIPR-08)
·         International Conference on Automation, Robotics and Control Systems (ARCS-08)
·         International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-08)
·         International Conference on Enterprise Information Systems and Web Technologies (EISWT-08)
·         International Conference on High Performance Computing, Networking and Communication Systems (HPCNCS-08)
·         International Conference on Software Engineering Theory and Practice (SETP-08)  
·         International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-08)

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. 
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 0 comments |
headers
scott wakeling | 22 Feb 2008 13:27
Picon

deterministic simulation - networking

I would like to gather opinion/experience on deterministic simulation,
especially as it relates to networking/multiplayer.

Has anybody here implemented multiplayer as a fully determinstic
process? i.e. sync every frame, server main authority, client fires
but doesnt do so until the server acknowledges it's happened etc. So,
no client side prediction, clients just send commands to the server
and wait to receive command streams back before triggering any
actions. In order for this approach to work the game has to be
completely deterministic. More lag is suffered than with client-side
prediction schemes, or peer to peer, but there are benefits too;
easier test during development and from a QA point of view being the
biggest.

The server would have to time stamp all commands, so all clients
execute them in the same order (to remain deterministic). Clients will
stutter if starved of command packets, and be forced to wait for the
packets to come in and get processed in order to get back on track.

I've heard some recent console titles employed this scheme to simplify
testing, but have not found anything concrete in the form of
articles/papers covering their experiences.

And some discussion on what can affect the determinism of your
simulation? Here's a start:

- threaded jobs need to officially complete on schedule instead of as
and when they are actually done, to remain deterministic..
- maths must be deterministic (so favour instruction set vs. C++/trust
the chip/compiler - is this entirely possible if you are careful?)
(leads to deterministic physics)
- no game logic affecting game state to rely on non-deterministic
behaviour (i.e. anything frame rate dependant) ... real world
possible? implications? experiences?

-scott
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 21 comments |
headers
Alex_Clarke | 22 Feb 2008 14:11

Re: deterministic simulation - networking


Unless I'm missing something, it sounds like you're describing a system that  will only run as fast as the slowest client.  Such a system would be fine on a LAN but probably not over the internet...

Re determinism, in theory it's simple to playback a level based on the recorded key presses (which is somewhat equivalent to what you're suggesting), but in practice this can turn out to be really quite tricky since there are a lot of subtle ways that non-determinism can be introduced.   You need to be particularly careful to ensure any PRNGs you use don't diverge (I've seen games which use separate graphics and game play PRNGs for this reason).   For the PC platform, can you trust floating point maths to be deterministic across all the different CPUs out there?

Alex Clarke


sweng-gamedev-bounces <at> lists.midnightryder.com wrote on 22/02/2008 12:27:59:

> I would like to gather opinion/experience on deterministic simulation,
> especially as it relates to networking/multiplayer.
>
> Has anybody here implemented multiplayer as a fully determinstic
> process? i.e. sync every frame, server main authority, client fires
> but doesnt do so until the server acknowledges it's happened etc. So,
> no client side prediction, clients just send commands to the server
> and wait to receive command streams back before triggering any
> actions. In order for this approach to work the game has to be
> completely deterministic. More lag is suffered than with client-side
> prediction schemes, or peer to peer, but there are benefits too;
> easier test during development and from a QA point of view being the
> biggest.
>
> The server would have to time stamp all commands, so all clients
> execute them in the same order (to remain deterministic). Clients will
> stutter if starved of command packets, and be forced to wait for the
> packets to come in and get processed in order to get back on track.
>
> I've heard some recent console titles employed this scheme to simplify
> testing, but have not found anything concrete in the form of
> articles/papers covering their experiences.
>
> And some discussion on what can affect the determinism of your
> simulation? Here's a start:
>
> - threaded jobs need to officially complete on schedule instead of as
> and when they are actually done, to remain deterministic..
> - maths must be deterministic (so favour instruction set vs. C++/trust
> the chip/compiler - is this entirely possible if you are careful?)
> (leads to deterministic physics)
> - no game logic affecting game state to rely on non-deterministic
> behaviour (i.e. anything frame rate dependant) ... real world
> possible? implications? experiences?
>
> -scott
> _______________________________________________
> Sweng-Gamedev mailing list
> Sweng-Gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

**********************************************************************

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster <at> scee.net

This footnote also confirms that this email message has been checked for all known viruses.

Sony Computer Entertainment Europe Limited

Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom

Registered in England: 3277793

**********************************************************************

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 1 comment |
headers
Kris Lamb | 22 Feb 2008 15:01
Picon

Re: deterministic simulation - networking

If you want to be deterministic don't use threads, it makes it a lot easier.

On Fri, Feb 22, 2008 at 7:27 AM, scott wakeling <scott.wakeling <at> gmail.com> wrote:
- threaded jobs need to officially complete on schedule instead of as
and when they are actually done, to remain deterministic..
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 5 comments |
headers
Bjoern Knafla | 22 Feb 2008 15:37
Picon

Re: deterministic simulation - networking

Alex Clarke wrote:

> Unless I'm missing something, it sounds like you're describing a  
> system that  will only run as fast as the slowest client.  Such a  
> system would be fine on a LAN but probably not over the internet...
>

The way I am interpreting some post mortems and Game Programming Gem  
gems it is possible to build a peer-to-peer system using a lockstep  
approach (the one described by Scott) that allows up to 16 players to  
work via the internet. Performance might become a problem though.

To fight latency it might prove successful to keep the idea of sending  
high-level actions from a client to a server that then distributes the  
actions to all connected clients but to replace the time- 
synchronization mechanism of the lockstep approach by another system.  
One idea is that all actions initiated by players or high-level AI  
have a specific delay and are therefore scheduled for a future  
execution which allows to hide the client-server-client-roundtrip  
latency.

Clients use visual feedback to hide the latency (for example an entity  
starts to prepare for the action but mostly waits on the action from  
the server).

Client time needs to be synchronized to enable comparable simulations  
on all clients based on the future time stamped actions arriving at  
them.

To hide latency client might use client side prediction which can be  
completely overthrown by the server-send actions but might be enough  
to hide latency. A sort of world state rollback would be needed or the  
client side prediction could be completely graphically without  
touching simulation content.

Clients with high latency and/or low bandwidth connections or slow  
computers that can't keep up with the simulation and the netword  
actions would suffer and might not even be able to influence the  
simulation with actions they send if the server rejects actions whose  
execution time-stamps are too far back in time. However fast computers  
with good connections won't have these problems.

Regarding pseudo-random-number-generators: when entity execution is  
done by tasks that are scheduled to threads in unpredictable ways I am  
giving each entity or processed entity aspect its own PRNG (which got  
seeded in a deterministic way at level-/game-initialization time).  
This way the sequence of entities that draw random numbers can't  
produce non-determinism as every entity (aspect) draws its own  
sequence and the entity or entity aspect simulation is (must be)  
itself deterministic.

By the way, don't forget to record simulation steps/time stamps when  
recording the key presses.

I am unsure how to handle floating-point inaccuracies between  
different platforms. Basing the simulation on fixed-point-numbers or  
using a scheme of sending absolute game state data from time to time  
to regenerate possible errors might work. I am eager to hear about  
experience fighting floating-point problems in practice!

Cheers,
Bjoern

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 0 comments |
headers
Bjoern Knafla | 22 Feb 2008 15:55
Picon

Re: deterministic simulation - networking

Kris Lamb wrote:
> If you want to be deterministic don't use threads, it makes it a lot  
> easier.
>
> On Fri, Feb 22, 2008 at 7:27 AM, scott wakeling <scott.wakeling <at> gmail.com 
> > wrote:
> - threaded jobs need to officially complete on schedule instead of as
> and when they are actually done, to remain deterministic..

Threads itself are not a problem but every asynchronous operation with  
non deterministic scheduling can be used (for example asynchronous  
reading of data from the HDD if the data influences the simulation.

FIght such scenarios by only processing non-simulation-influencing  
computations asynchronously, by explicit blocking at a deterministic  
frame to wait on results (and by only using results that arrived  
earlier in that frame, too), by using incremental algorithms that can  
be executed in a very controlled way, and by using data- and task- 
parallel computation blocks that are kept inside / finish inside one  
simulation main loop cycle and by disallowing cycle-overlapping  
threaded computations if you are not using an explicit synchronization  
token (as described above).

Another problem for determinism might be the control over a script  
interpreter and the resources (PRNG, threads) used by the interpreter.

Cheers,
Bjoern

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 4 comments |
headers
Andrew_Ellis | 22 Feb 2008 16:01

Andrew Ellis is out of the office.


I will be out of the office starting  13/02/2008 and will not return until
25/02/2008.

I will respond to your message when I return.

**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify postmaster <at> scee.net
This footnote also confirms that this email message has been checked for all known viruses.
Sony Computer Entertainment Europe Limited
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom
Registered in England: 3277793
**********************************************************************
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 0 comments |
headers
Kris Lamb | 22 Feb 2008 17:18
Picon

Re: deterministic simulation - networking

In that case why not just use a state based main loop that calls all your modules.  It seems like to me that you are describing writing threads to wait in specific order and that is no different in my mind than just sequential coding.

On Fri, Feb 22, 2008 at 9:55 AM, Bjoern Knafla <mailinglists <at> bjoernknafla.de> wrote:
Kris Lamb wrote:
> If you want to be deterministic don't use threads, it makes it a lot
> easier.
>
> On Fri, Feb 22, 2008 at 7:27 AM, scott wakeling <scott.wakeling <at> gmail.com
> > wrote:
> - threaded jobs need to officially complete on schedule instead of as
> and when they are actually done, to remain deterministic..

Threads itself are not a problem but every asynchronous operation with
non deterministic scheduling can be used (for example asynchronous
reading of data from the HDD if the data influences the simulation.

FIght such scenarios by only processing non-simulation-influencing
computations asynchronously, by explicit blocking at a deterministic
frame to wait on results (and by only using results that arrived
earlier in that frame, too), by using incremental algorithms that can
be executed in a very controlled way, and by using data- and task-
parallel computation blocks that are kept inside / finish inside one
simulation main loop cycle and by disallowing cycle-overlapping
threaded computations if you are not using an explicit synchronization
token (as described above).

Another problem for determinism might be the control over a script
interpreter and the resources (PRNG, threads) used by the interpreter.

Cheers,
Bjoern

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 3 comments |
headers
Bjoern Knafla | 22 Feb 2008 17:48
Picon

Re: deterministic simulation - networking

I tried to describe a system where all simulation influencing work is  
done in a deterministic way. While I am not entirely sure what you  
mean by a state based main loop I interpret it as a main loop where  
every cycle iterates through a specified number of states in a  
specified order. Such states could (and if possible should) use  
threads or tasks of a taskpool internally as long as the internal  
parallelism starts and ends with the state.

If you also identify states that are order-independent or to put it  
differently, which can run concurrently because they have no direct  
dependencies, then you could also put them on different threads (or in  
different tasks of a task pool) as long as they are finished before a  
state starts to process which depends on both of them.

However, long text with short message - parallel programming is  
essential in the mid-term future and should and can be used while  
meeting requirements on determinism.

Cheers,
Bjoern

On 22.02.2008, at 17:18, Kris Lamb wrote:

> In that case why not just use a state based main loop that calls all  
> your modules.  It seems like to me that you are describing writing  
> threads to wait in specific order and that is no different in my  
> mind than just sequential coding.

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 1 comment |

Gmane