Quick Start Guide
To get up and running as quickly as possible with your own Homegames application, check out our Hello World example on GitHub.
How it works
As opposed to more traditional game systems, Homegames runs on a webserver that broadcasts game data to clients over a network.
Game data is generated on the server and sent to clients, which then render the state of the game on the screen.
Client inputs are sent back to the game server, which then updates game state and broadcasts changes to all connected clients.
A bit more technical
The Homegames game server broadcasts game data to clients connected via WebSocket in a binary format generated by Squish.
Homegames is written entirely in JavaScript. The webservers use Node.js and Squish is written in vanilla JavaScript.
We support multiple game instances on the same machine by spawning new web servers from a kind of "main" server that starts when you run Homegames. In other words, moving between game sessions is actually moving between servers, all of which are running on the host machine.
Our browser-based client is the only one that we know of at the moment, but we technically support any client that can receive and render the data. If you're interested in building your own client, let us know using the contact form at the bottom of the page because that sounds nuts.
Why JavaScript?
We like JavaScript.In addition to that and it being incredibly popular, JavaScript was the clear choice for a few key reasons:
Shared code between server and client
Writing the server and our initial client in JS allowed us to share libraries between the two. Having our servers, libraries, and infrastructure scripts written in JS also means someone only needs to know one language to have an understanding of how our entire system works.
Websocket support
Websockets are natively supported in modern browsers and there's a great websocket library for Node.
Learnability
A primary goal of Homegames is to help other people build cool stuff, even if they don't know where to start.
We just need one thread
The design of Homegames hinges on the idea that a game's state should only live in one place at one time.
Clients can get a view of the game state and send inputs to update it, but the game's true state is always on the server.
We needed something that could process user input and manage game state while making sure clients don't get of of sync with eachother.
Node's single-threaded event loop works pretty well for this, since we don't need multiple threads updating and reading from game state at the same time - we just need one thread repeating these steps as fast as it can:
- Read input from a client
- Update game state (if applicable)
- Tell clients about new state (if applicable)
Supported features
- Layers - We support multiple game "layers" with a simple 2D grid system to represent the overall visual state of the game
- Images - Upload your image files (PNG, JPG) to the Homegames website as assets and use them in your game
- Audio - Upload MP3 files as assets and use them in your games to add music & sound effects
- Physics - Simple geometry & collision detection
- Gamepad support - Add gamepad support to your game with Homepad
- Multiplayer - Designed with multiplayer in mind for out-of-the-box multiplayer support
- Spectators - Players can drop in & out of spectator mode at any time
- Public games - In addition to playing games with people on your network, play games over the Internet via room codes on public.homegames.link