Decentralized, Self-hosted cloud gaming/cloud application service.
CloudMorph is a decentralized, self-hosted cloud gaming/cloud application service. User can host their cloud gaming app with minimum configuration. By leveraging the ease of deployment, CloudMorph goal is to build a decentralized cloud-gaming network with app providers and consumers.
To bring a scalable and generic cloud gaming solution, CloudMorph has to cope with various challenges in video streaming optimization, Windows application Virtualization in headless server or P2P mesh network structurization.
Video Demo: https://www.youtube.com/watch?v=fkOpOQ-HwFY
| Screenshot | Screenshot |
| :----------------------------------------------------: | :-------------------------------------------------------: |
| Diablo II | Photoshop |
| RoadRash | Starcraft |
Demo Hosted by CloudMorph
Cloud Diablo SG (Demo of Collaborative play Diablo running on Singapore server using CloudMorph)
Cloud Diablo US (Demo of Collaborative play Diablo running in US server).
Switch Applications using the sidebar on the left.
Simplicity: No API/ interface integration needed from application. One line script deployment to a public server to get work done.
Mesh network: Providers-Consumers over Peer To Peer communication. After joining the network, Provider's Application is discoverable and launched with one click.
Modularizable: A concise technical stack to develop/deploy for cloud gaming/ cloud application service.
Generic/Cross-platform: Run on web browser, web mobile. Target Windows App instead of relying on gaming framework/emulator (like CloudRetro).
Scalable: Be able to scale on headless machines cluster horizontally.
Unlike CloudRetro, a Completed Cloud Gaming solution on Retro Game hosted on dedicated cloud infrastructure, CloudMorph generalizes the system to bring any offline Windows application to a cloud mesh network. The deployment is simplified with a concise tech-stack and codebase. The goal is to create a distributed cloud application system when anyone can contribute their offline application on the platform, and other people can consume it.
- Experience playing/hosting Cloud Gaming on their own.
- Plugable Cloud gaming module: The cloud gaming core is packaged and virtualized to be easily extended to different tech stacks.
- Multi-platform: be able to run web-browser, mobile web.
- Collaborative Gaming: Multiple people plays the same game. Ex. Twitch play pokemon, or http://clouddiablo.com/ - A cloudmorph demo.
- Playable Teaser: Application's teaser is playable,
Foremost, you need an Ubuntu instance with a public network firewall. For example, you can use the given
script/create_do.sh to create a digital ocean instance.
We need 3 in the same folder:
apps: a folder contains the app you want to deploy. For example,
config.yaml : app config, the app configuration on cloud-morph
setup_remote.sh: a script to deploy your application to server
setup_remote.sh $ip $mount_path. Ex:
./setup_remote.sh 188.8.131.52 /apps/DiabloII
- Tutorial Video: https://www.youtube.com/watch?v=w8uCkfZdHVc
Deployment with setup file
There are configuration examples without applications. You can search the app and put it in the same configuration folder.
The service is based on Golang, C++, and Linux X11 utility tools (Xvfb, ffmpeg).
You can set up all dependencies with
setup.sh. After that, you can run the go server with
Access to your local at
Note: the wine application is run in Docker. You can run it without docker by changing
server.go for easier debugging.
When Webserver starts, Wine Application is spawned inside a container at the same time. However, in the future, Wine Application needs to support multiplex to run multiple applications in the same VM.
Input captured from Client is sent to Virtual Machine over Websocket.
A C++ script (syncinput.exe) will listen to the event and simulates Windows OS event to Wine Application through WinAPI.
Application screen is captured in a Virtual Display Frame Buffer, which is later piped to FFMPEG.
FFMPEG will produce the screen stream to a VPX RTP stream.
In the end, the core module receives Input as WebSocket event and Output as RTP stream. You can check the interface at
Webserver interacts with Virtual Machine using these Input and Output format.
Why do I pick Linux Stack and Wine?
- First, I consider writing the whole system in Windows. However, Windows lacks programming utilities, and Linux is more comfortable for me.
- Wine is a Windows Virtual Machine. Its performance is proven in Steam PlayOnLinux. Lutris.
- Headless server is a server without display. When you acquire any cloud instances from AWS, Digital Ocean, GCloud..., it is headless because there is no monitor attached to it.
- One of the most challenging problems is to deal with Headless when your application/game always requires a graphic monitor, graphic driver. Being able to run on a Headless server is a goal. We can improvision new application instances and scale gaming sessions properly.
Why XVFB, not X11VNC (Remote access)
- XVFB is a Virtual Frame Buffer. There is no monitor attached to the server, so XVFB is a virtual buffer that can capture image frames going to DISPLAY.
Why TCP socket for interaction between Server and Wine Application.
- Even though Wine application and server stay in the same machine, they theoretically run on different OS. Internal Process Communication becomes challenging and not suitable. Network communication using Websocket over some defined ports can help in this case.
Why Golang, FFMPEG, C++
- FFMPEG is used to grab XVFB Display (built-in functionality) and convert it to the VPX video stream. It can be substituted with GStreamer or any custom encoding solution.
- C++ is chosen because it has good support for WindowsAPI.
- Golang is not really a crucial part of this design. It helps spawn Webserver conveniently. With Pion library in Go, WebRTC streaming becomes really handy.
Road Map - Request for Help
- UI improvement - I'm not frontend developer, so really need help on this.
- Full Dockerize for easy local experiment.
- Port C++ Window API to Rust.
- Audio - With PulseAudio virtualization.
- GPU acceleration. - Integrate with FFMPEG job.
- Multiplex application sessions. Currently, only collaborative mode is supported, which serves all application's sessions from the same single instance.
- Performance optimization.
- Web Mobile controller supprt. Currently, mouse click is already simulated.
- Packaging frontend as a plugin that can be imported in any Webpage.