Rules proposal for js13kGames Server Category

[Aurium]

Andrzej end3r Mazur explain that he don't add the server category right now because he received to many questions about this category rules, and because he need somebody to help in this category. If we come with a conclusion, he said that is ok to back with the server category, allowing multi-player games, even now for 2014.

This was the 2013 rules about the Server Category:

• 6 - Server development
  When participating in the Server category you have 13 kB for the server and 13 kB for the client, so it's a total of 26 kB. You can use Socket.io to ease your development and help you with the online communication.
• 11 - Sending submissions
  ... If you have a Node.js game you can deploy it on Nodejitsu - read the walkthrough in this blog post.

This was the 2013 FAQ about the Server Category:

How will the size of a server game be measured exactly? Should the server side + client side code together zipped into one file be 26kb?
Since the Socket.io was chosen as sanctioned multiplayer lib, it should not be counted in the allotted 13kb. A submission should not contain the node_modules directory. Instead, it should have a valid package.json file, defining the dependencies. This way, we can unzip the server files, run "npm install", and be ready to go. Since the dependencies are in JSON format, it can easily be parsed to see if only allowed libraries are used. If node modules are used that aren't on the sanctioned libraries list, they must count for the 13kb, so the node_modules directory must be included, containing only those. Combining the server/client into a single zip file would make it possible to create a 20kb server with a 6kb client, which is not what we want. Participants have to submit separate zip files for client/server.

---

Can we use a public STUN server for WebRTC? Will still implement the signal server in Node.js.
Please remember that the WebRTC is still in the early stage. Google offers free STUN/TURN servers, and the technology would be nearly impossible to use without them (implementing your own STUN server will place an unfair burden on your server code size).

---

The code for server side, to calculate that would I zip up everything but the node_modules folder containing Socket.io?
See the first answer. The server zip package must be less than 13kb. Sanctioned dependencies (only Socket.io) can be installed using "npm install", which parses package.json.

---

If I include the Socket.io library (client and server side), does it count against my 26k (13k*2)?
The Socket.io library is itself larger than 26kb, so no. You can't count it as part of the 13kb submission.

---

Is the client side Socket.js lib allowed as well or only the server side packge? Just found out that the server side Socket.io package ships the browser files as well. So it's ok to use that? So that we can load "/socket.io/socket.io.js"?
The client side library for Socket.io is required to use it, as Socket.io implements its own protocol inside websocket (or fallback carrier). Alternatively, the "websocket" module does not require any client side library.

---

Can I create my own REST APIs on the server to let the user save and load custom game data, as long as it's <13kb? I just persist a JSON created by server.js on a file to preserve user data on crash/reboot. Does it go against rule 3?
Creating your own REST APIs doesn't count as an external dependency, so it does not conflict with rule 3. However, all server-side code must be included in the 13kb server zip. The data itself does not count for the game size limit, as it is created at run-time (in the same way that procedural graphics can be generated and cached at runtime).

---

---

Well, my proposal starts changing the deploy mode for the competition. All single-player or browser-only games are deployed at http://{year}.js13kgames.com/games/{game-name}/index.html'>http://{year}.js13kgames.com/games/{game-name}/index.html, however, in 2013, the server based games was deployed on developer defined servers, what may not to be good enough for a fair competition. The js13kgames may have its own game server, so all entries will have the same url structure and fully controlled by the competition staff.

I did this proof of concept: https://gist.github.com/aurium/e75117c21c142c5d9ba1

The idea is: make it easy to write and deploy server code, focusing on Socket.io usage.

• The developer will have a Node.js sandbox with a configured socket.io server, ready to use.
• The responsible to deploy will do it as easy as deploying a browser-only game.
• The new url structure may be http://{year}.js13kgames.com/games/{game-name}/index.html'>http://{year}.js13kgames.com/games/{game-name}/index.html?wsp={srv.port} allowing the client side to discover where to connect, on this same domain. The client lib for socket.io must also be provide by http://{year}.js13kgames.com to not weigh in the developer package.

A good question may be: in a sandbox the node require will not work as it is, so that will not to be a real node application. Right! However that is not a node competition, it is a javascript competition. Meanwhile... modularization still possible, implementing a simple require for the sandbox.

This game server loader may be easily used by the developer, to ensure the closest environment between dev and deploy.

---

So... I propose this rules for server category:

Server development
When participating in the Server category you have 13 kB for the server and 13 kB for the client, so it's a total of 26 kB. You must code it to run on our game-server loader <link for the git repo>, where you will found a pre-configured Socket.io server. The client-side lib for Socket.io is located at http://{year}.js13kgames.com/{somewhere} and you can freely point to this on your client-side code.

You can install the game-server loader on your machine to test your development. See this post <link to a post about the game-server loader instalation and usage>.

All other server dependences of your code must be provide by your server-side package, and must fit the 13 kB limit. As it be to the client-side package.

Sending submissions
<client-side guidance>. If you have a server-side code, you must remember to provide a second package on the appropriate field.

 

---

A interesting question: Can we use a STUN server for WebRTC? What about the signal server?
Someone wants to add the server-side dependences for a WebRTC application on the game-server loader proposal?

Open question: Public STUN must be understood and forbidden as any other external assets?

 

---

Open question: I believe the developer must to be able to read/write in some file or directory to preserve user data on crash/reboot. So, this ability must be add to the sandbox. Someone have a issue about this? A file to store JSON (where the read/write process will be oblivious) is the easiest way, or we have a good argument to give a directory for free-form rw?

 

---

The final question:
end3r needs someone to help him to organize the server category and answer participant questions. Who wants to help on this?

[ooflorent]

This year I wanted to submit an MMOG to the competition. I have experience developing node.js games using (or not) socket.io.

I could help or assist during the JS13KGame unless it is incompatible with the contestant status.

 

Regarding your gist, several things are missing:

• You should expose the Server or a wrapper otherwise contestants will not be able to implement web services or fetch server data
• The new require function is way too restrictive
• what about file system access? Contestants may need to store data on disk

[Aurium]

Thanks ooflorent!
 

I could help or assist during the JS13KGame unless it is incompatible with the contestant status.

I believe we must not to mix the ststus. :-(
 

You should expose the Server or a wrapper otherwise contestants will not be able to implement web services or fetch server data

Ok! I was thinking in a websocket only app, but, why not a basic http server too? Adding to my TODO.
 

The new require function is way too restrictive

Yes. I don't try hard... may you help me with this. I believe the require() inside the sandbox must only be able to load modules inside the game dir. If we can't use the require() from node.js, we may implement something like http://wiki.commonjs.org/wiki/Modules/CompiledModules
 

what about file system access? Contestants may need to store data on disk

Yes! That is may last proposal. Please, read the last open question. You believe a abstracted JSON store is enough, or we need a free-form dir?

[ooflorent]

Are there any updates about the server rules?

I would be glad to help!

 

Feel free to send me a PM if you want my contact informations.

[Zolmeister]

Perhaps we can simplify this?

At the submission deadline, a script clones all GitHub repos.

Then after the winners have been chosen, their code is examined and game run locally (on a VM) to verify that the game runs the same locally as remotely.

 

This requires the least amount of work for everyone involved, as only a few games will have to be run locally.

The setup requirements for server code should be:

npm install --production

npm start

 

And that's it

[ooflorent]

I'm not sure about sandbox mode.

Is there any valid reason about it?

 

Abstracted JSON store is great.

FS access is not mandatory if there is a way to store JSON payloads.

 

What would be the node version?

Please, use 0.11 with harmony flag!

 

 

Perhaps we can simplify this?

At the submission deadline, a script clones all GitHub repos.

Then after the winners have been chosen, their code is examined and game run locally (on a VM) to verify that the game runs the same locally as remotely.

What about development scripts? I don't want to commit generated / minified code!

Moreover, we can submit a 13kb zip. How do you evaluate the zipped code size of the repository?

 

The setup requirements for server code should be:

npm install --production

npm start

I like this.

What about sanctioned libraries?

[Aurium]

Thanks Zolmeister!

 

I agree with ooflorent on the submission issue. Because the personal organization of dev scripts, and because sometimes we use external tools... On my first game i did some corrections by hand on minified code to restore utf8 special chars, somebody may use a minifier service on the web.

 

About the setup requirements for server, i join it to ooflorent's question about the sandbox.

 

Well, the sandbox proposal is an attempt to simplify the server-side development and the competition deploy.

• In this proposed sandbox we can write less code to use enabled libs, so, we have more space for game logic.
• With this proposed sandbox the competition admin can deploy the game in the game server with no fear.
• All games will be on the js13kgames server. Not only the single-player/browser-only games. (if you see we already lost some multi-player games from last year)

Why not the "npm install --production; npm start" strategy? First because the sanctioned libraries. In this case the admin must to evaluate package.json before. But, the most important: we can't put it in the server without understand all the code. That can write sys files, can open ports in conflict with other games, can force requires by other methods... So, we will not have the multi-player games on the js13kgames server with this strategy. :-(

 

ooflorent, thanks about the JSON store feedback. So, if no one comes with a argument for free form dirs, we can implement this storage and make the game development easier inside the sandbox. :-)

 

...And ES6 through harmony will be nice! :-)

[ooflorent]

I see one problem with the sandbox: we are exposing too much but we can't do it differently.

User scripts may bind ports through a Server instance or a socket.io one.

// Outside the sandboxvar Server = require('http').Server;var server = new Server();server.listen(3000 + userID);// Inside the sandbox (if we expose the server)server.listen(3000 + otherUserID);    // Bind another portserver = new (server['constructor']); // Create a new server// Inside the sandbox (through socket.io)socket.server.listen(3000 + otherUserID);

Conclusion: we have to proxify everything...

[Aurium]

Good ooflorent!

We must test it!

 

A solution may be:

onConn: function(callback){ io.on('connection', function(socket){ callback(wrapIt(socket)) )) },

wrapIt can expose a minimum useful attributes.

[Zolmeister]

 

What about development scripts? I don't want to commit generated / minified code!

Moreover, we can submit a 13kb zip. How do you evaluate the zipped code size of the repository?

 

I agree that committing minified code is not best practice, but in this case I think it's fine.

We could say submissions must have a '/dist' folder with minified assets, and 'npm start' must call into it.

The zipped (or included zip extracted) md5sum of the files should match.

 

As for sanctioned libraries, I'm fine leaving it only to built-ins and socket.io

So the code should run after:

npm install socket.io

npm start

 

I'm happy to create a boilerplate example of the package.json as well