• Content Count

  • Joined

  • Last visited

About Aurium

  • Rank
  • Birthday 09/13/1979

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  1. You must try the game server done to provide the infrastructure to the server category of this competition: (The Pong example game is working on desktop and smartphone browsers)
  2. Yeah! We can do a lobby for all games on the game server:
  3. 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.
  4. 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! :-)
  5. Thanks ooflorent! I believe we must not to mix the ststus. :-( Ok! I was thinking in a websocket only app, but, why not a basic http server too? Adding to my TODO. 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 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?
  6. end3r and all interested ones, please read: ;-)
  7. 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 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 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 See the first answer. The server zip package must be less than 13kb. Sanctioned dependencies (only can be installed using "npm install", which parses package.json. If I include the library (client and server side), does it count against my 26k (13k*2)? The 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 package ships the browser files as well. So it's ok to use that? So that we can load "/"? The client side library for is required to use it, as 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}{game-name}/index.html'>http://{year}{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: The idea is: make it easy to write and deploy server code, focusing on usage. The developer will have a Node.js sandbox with a configured 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}{game-name}/index.html'>http://{year}{game-name}/index.html?wsp={srv.port} allowing the client side to discover where to connect, on this same domain. The client lib for must also be provide by http://{year} 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 server. The client-side lib for is located at http://{year}{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?
  8. end3r, do you have the list of "server questions" sent to you through the multiple channels? I want to start a discussion with all recognized problems. Thanks!
  9. end3r, I would love to participate with a multiplayer game. May we start a topic in this forum to discuss the rules about the server side code, for 2015? First point: I think that must run in a server built to the competition, inside Node.js sandboxes. That will help to control the features allowed on server side. What you think?
  10. You may also read this post: