js13kgames / js13kserver

js13kGames Server category files and rules

js13kgames.com Game Server

Game server for the js13kGames Competition.

Install

Download the skeleton. Extract the files and install the third party libraries with npm.

npm install

Running

You can run the server locally with the following command:

npm run start:dev

You can reach the test server at http://localhost:3000

The dev server uses nodemon to auto restart when you change some source file. If you want to pass some parameter to it, just add an -- after start:dev. An example:

npm run start:dev -- --inspect

Code structure

All your code must be in the public folder. Put your server side code into the server.js file. The shared.js file is loaded at the begining of the server.js file. You can also use this code on the client side.

The server.js is a standard Node.js module. You can use the following structure to create new Express routes or Socket.io connection handler.

module.exports = {
    // Express route to /hello
    hello => (req, res) { ... }
    // Socket.io connection event handler
    io => (socket) { ... }
}

Persistent storage

The server category entries can use 13kByte persistent storage. The key and value size also counts into the limit!

The storage uses SQL database to save the key/value pairs. By default it's SQLite but on Heroku you have to use the Postgres add-on!

In the server.js file you can access the storage interface. The API documentation is inside the lib folder.

Deploy to Heroku

All server category entries must be hosted on Heroku. You can either use free or paid plan.

1. Push your files to your GitHub repository
2. Create new WebApp on heroku
3. Add Heroku Postgres add-on (optional)
4. Connect your WebApp with the GitHub repository
5. Deploy your code

You can find more information about the platform on the Heroku Dev Center site.

Submit your entry

1. Zip all files in the public folder.
2. Submit your entry on the js13kgames.com site.
3. Add [email protected] games as collaborator to your Heroku WebApp.

Server category rules

• Sandbox server

  • You can find the official sandbox server at https://github.com/js13kGames/js13kserver.

• Package size still below 13 kB

  • Game package will contain all the game code and assets, for the client and the server.
  • That also means you must not use the server database to store extra code or assets, that was not created by its users. If your game needs to seed the DB, your 13k code must do it.

• Sandboxed environment

  • Your game will run in a node.js based sandbox environment. That means you will not really use node. You cannot require modules and your own modules shipped by your 13k pack.

• Do not leak the sandbox

  • This is not a hacking competition. This is a way to help the competition admins, the site persistence, and you. Do not touch the procfile and the skeleton code.

• Socket.io client lib

  • You can use it. Simply add <script src="/socket.io/socket.io.js"></script> to your HTML and that will be loaded. No server configuration will be needed. The sandbox already did it.

• Google's free STUN servers are the only allowed external services:

  • stun.l.google.com:19302
  • stun1.l.google.com:19302
  • stun2.l.google.com:19302
  • stun3.l.google.com:19302
  • stun4.l.google.com:19302

• Can I test the sandbox before submitting?

  • Yes, you can and you must! Installing and getting it running is simple. Visit the project page at https://github.com/js13kGames/js13kserver.

• Is there any example? How do I develop my game using the sandbox server?

  • There's a simple "Rock, Paper, Scissors" example in the public folder.

• I have more questions!

  • Feel free to send them to [email protected].

FAQ

• Can I minify the server side code?

  • Yes, but you have to keep the readable code also.

• Can I add more npm packages?

  • Yes, but you cannot use them in your game code.

• What files count in the 13kb limit?

  • All files in the public folder.

• Can I deploy new code after I submited the entry?

  • Yes, but you have to resubmit your entry on the site also.

• Can I modify the procfile or the skeleton code?

  • No

js13kserver's Issues

Thoughts on a PocketBase app category?

PocketBase has gained tremendous popularity and momentum in the past year (~25k github stars). It's a great micro-backend that I think aligns with the spirit of js13k.

Here's my proposal, and I'd be happy to discuss or put a repo together:

• 13k limit for combined frontend and backend logic, and any seed data/assets. Initial data schema migrations are free.
• Repo includes Dockerfile to build the server AND create a zip file to prove all starting assets are <13k. Dockerfile is not allowed to be modified.
• Deploy Dockerfile anywhere, but fly.io has a strong free tier and is recommended
• Unlimited persistent storage for user-generated content (ie, we don't attempt to track this)
• Official PocketBase JS SDK is free

I think this would be a great category because it would support a fantastic open source project and also modernize the server category to be more aligned with current tooling and deployment approaches.

Disclaimer: I run pockethost.io.

Heroku's free tier is dead - where do we go?

The current rules for the Server category still define Heroku as the service we expect Server games to live on. With its free tier dead, that's no longer an option (not to mention that past Server games in the compo are effectively "dead" currently, and need to be revived somehow).

The next edition of js13kGames is up in 2 months, so those rules need to be revised.

We need to...

• Decide which host to move to. At the very least we need one new host that's free with sufficient resources for our typical games to run, and that's as easy to set up as Heroku used to be;
• Decide whether we stick to one host as in the past, or allow several;

And if we settle on multiple, then this begs the question whether to simply allow people to host them wherever they want, merely providing guidance on the options they have. I don't see why we couldn't/shouldn't, though I recall @end3r mentioning "validation reasons" for why Heroku was mandatory. Still, I don't see how we can reliably guarantee that someone's server continously runs the same code that was submitted to the competition initially, so let's not try not to make this obvious issue a blocker.

In any case, we need that decision no later than mid-July to leave some headroom.

---

I've done some preliminary googling and narrowed down my personal alternative picks to:

• Render
• Cyclic (is actually akin to serverless, not persistent, e.g. does not support websockets)
• Railway (free tier actually has insufficient monthly allowance to run an entire month)
• Glitch (lacks external DBs, but appears to support SQLite just fine, which should be sufficient)

Additional options suggested in this thread that are viable:

• Fly.io (sufficient allowances; some caveats WRT getting databases running)

There's more options out there, of course. All of these seem appropriate at first glance, and have roughly the same operating model on their free tier as Heroku had (i.e. the instance spins down after an extended period of inactivity, and then takes a while to spin back up on-demand). However, I've used none of them in practice and have limited time in the next 2 months to actually try them out properly.

Input on host experiences from folks who run small, low-traffic (with occasional spikes) Node.js apps would be very welcome.