Game Engines 2021W Lecture 17

From Soma-notes
Revision as of 15:33, 16 March 2021 by Soma (talk | contribs) (Created page with "<pre> Lecture 17 ---------- ccr - https://www.cs.unm.edu/~ackley/#rh-ccr Big idea - can we make a virtual world truly peer-to-peer? What does this mean? basically all vir...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Lecture 17
----------

ccr
 - https://www.cs.unm.edu/~ackley/#rh-ccr

Big idea - can we make a virtual world truly peer-to-peer?  What does this mean?

basically all virtual worlds are client server
 - server may be distributed, but all are controlled by the same entity
 - so, who has the power? the server.  All of it

So, peer-to-peer virtual worlds have to share power, somehow
 - my stuff is my stuff?
 - my power is "equal" to that of others?

Closest to this is custom servers
 - i.e., run your own minecraft server
 - person running the server has absolute power but can
   grant powers to arbitrary players

A truly peer-to-peer world means that everyone is running their own
custom servers
 - peer to peer!
 - client is the server
 - connect worlds to worlds
   - we can walk from one world to another
   - but it depends on the peer-to-peer relationships
   - social graph is reflected in the physical graph

The most interesting part of ccr was its approach to code
 - normally, the developer of the client & server determine everything
 - but with ccr, "players" should control how their worlds work
   - code was mobile, to a degree
 - to make anything work, you need code
   - code is also fundamentally dangerous
 - you would limit the "physics" of the world to limit the abilities of code
   - more than sandboxing
 - recognition that communication is fundamentally dangerous
   - so you better limit it at the lowest level

one problem of ccr was it was really slow
 - shouldn't be so much of an issue now
 - but maybe it would be because ccr was designed to be slow (simulating
   "physics"