mirror of
https://github.com/giongto35/cloud-game.git
synced 2026-07-24 02:27:32 +00:00
300th commit: Update REAME + ice timeout
This commit is contained in:
parent
34995a5d1d
commit
a9b4e310a6
26 changed files with 68 additions and 36 deletions
7
document/designdoc/README.md
vendored
7
document/designdoc/README.md
vendored
|
|
@ -1,13 +1,13 @@
|
|||
# Web-based Cloud Gaming Service Design Document
|
||||
|
||||
Web-based Cloud Gaming Service contains multiple workers for gaming streaming and a coordinator (Overlord) for distributing traffic and setup connection.
|
||||
Web-based Cloud Gaming Service contains multiple workers for gaming stream and a coordinator (Overlord) for distributing traffic and pairing up connection.
|
||||
|
||||
## Worker
|
||||
|
||||
Worker is responsible for streaming game to frontend
|
||||

|
||||
|
||||
- After Coordinator matches most appropriate server to the user, webRTC peer-to-peer handshake will be conducted. Coordinator will exchange the signature (WebRTC Session Remote Description) between two peers over Web Socket connection.
|
||||
- After Coordinator matches the most appropriate server to the user, webRTC peer-to-peer handshake will be conducted. The coordinator will exchange the signature (WebRTC Session Remote Description) between two peers over Web Socket connection.
|
||||
- On worker, each user session will spawn a new room running a gaming emulator. Image stream and audio stream from emulator is captured and encoded to WebRTC streaming format. We applied Vp8 for Video compression and Opus for audio compression to ensure the smoothest experience. After finish encoded, these stream is then piped out to user and observers joining that room.
|
||||
- On the other hand, input from users is sent to workers over WebRTC DataChannel. Game logic on the emulator will be updated based on the input stream.
|
||||
- Game state is stored in cloud storage, so all workers can collaborate and keep the same understanding with each other. It allows user can continue from the saved state in the next time.
|
||||
|
|
@ -22,5 +22,4 @@ Overlord is loadbalancer and coordinator, which is in charge of picking the most
|
|||
2. Overlord will find the most suitable worker to serve the user.
|
||||
3. Overlord collects all latencies from workers to users as well as CPU usage on each machine.
|
||||
4. Overlord setup peer-to-peer handshake between worker and user by exchanging Session Description Protocol.
|
||||
5. A game is hosted on worker and streamed to the user .
|
||||
|
||||
5. A game is hosted on worker and streamed to the user.
|
||||
|
|
|
|||
40
document/implementation/README.md
vendored
40
document/implementation/README.md
vendored
|
|
@ -3,21 +3,41 @@
|
|||
## Code structure
|
||||
```
|
||||
.
|
||||
├── cmd
|
||||
│ ├── main.go
|
||||
├── cmd: service entrypoint
|
||||
│ ├── main.go: Spawn overlord or worker based on flag
|
||||
│ └── main_test.go
|
||||
├── emulator: emulator internal
|
||||
│ ├── director.go: coordinator of views
|
||||
│ └── gameview.go: in game logic
|
||||
├── overlord: coordinator of workers
|
||||
├── games: roms list, no code logic
|
||||
├── static: static file for front end
|
||||
│ ├── js
|
||||
│ │ └── ws.js: client logic
|
||||
│ ├── game.html: frontend with gameboy ui
|
||||
│ └── index_ws.html: raw frontend without ui
|
||||
├── overlord: coordinator
|
||||
│ ├── handlers.go: coordinator entrypoint
|
||||
│ ├── browser.go: router listening to browser
|
||||
│ └── worker.go: router listening to worker
|
||||
├── games: roms list, no code logic
|
||||
├── worker: integration between emulator + webrtc (communication)
|
||||
│ ├── room:
|
||||
│ │ ├── room.go: room logic
|
||||
│ │ └── media.go: video + audio encoding
|
||||
│ ├── handlers.go: worker entrypoint
|
||||
│ └── overlord.go: router listening to overlord
|
||||
├── emulator: emulator internal
|
||||
│ ├── nes: NES device internal
|
||||
│ ├── director.go: coordinator of views
|
||||
│ └── gameview.go: in game logic
|
||||
├── cws
|
||||
│ └── cws.go: socket multiplexer library, used for signalling
|
||||
├── webrtc: webrtc streaming logic
|
||||
└── worker: integration between emulator + webrtc (communication)
|
||||
│ └── cws.go: socket multiplexer library, used for signaling
|
||||
└── webrtc: webrtc streaming logic
|
||||
```
|
||||
|
||||
## Room
|
||||
Room is a fundamental part of the system. Each user session will spawn a room with a game running inside. There is a pipeline to encode images and audio and stream them out from emulator to user. The pipeline also listens to all input and streams to the emulator.
|
||||
|
||||
## Worker
|
||||
Worker is an instance that can be provisioned to scale up the traffic. There are multiple rooms inside a worker. Worker will listen to overlord events in `overlord.go`.
|
||||
|
||||
## Overlord
|
||||
Overlord is the coordinator, which handles all communication with workers and frontend.
|
||||
Overlord will pair up a worker and a user for peer streaming. In WebRTC handshaking, two peers need to exchange their signature (Session Description Protocol) to initiate a peerconnection.
|
||||
Events come from frontend will be handled in `overlord/browser.go`. Events come from worker will be handled in `overlord/worker.go`. Overlord stays in the middle and relays handshake packages between workers and user.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue