It is no short feat getting users to adopt your game engine, especially closed source. How did you manage to do that so well so far with the gallery of games you have on your site? Are those just a few friends or is there a pretty active community?
Show HN: I'm open-sourcing my game engine
11–20 of 94 posts
Re: Show HN: I'm open-sourcing my game engine
#12Earlier quoted context omitted.
I don’t see why. Connection-wise, the node event would loop make I/o blocking from the http request / response side a non issue. I doubt the backend is doing physics heavy stuff for the front end.
You must perform physics calculations on the backend if they are significant features that influence player positions. Node also only works off a single core.
I see. That makes sense.
Re: Show HN: I'm open-sourcing my game engine
#13Impressive project, thanks for sharing!
Re: Show HN: I'm open-sourcing my game engine
#14It is no short feat getting users to adopt your game engine, especially closed source. How did you manage to do that so well so far with the gallery of games you have on your site? Are those just a few friends or is there a pretty active community?
A combination of good capabilities, ease of learning, and low commitment (casual, a few days or even hours of effort to meaningful result) can go a long way. Remember Flash.
Re: Show HN: I'm open-sourcing my game engine
#15Earlier quoted context omitted.
I don’t see why. Connection-wise, the node event would loop make I/o blocking from the http request / response side a non issue. I doubt the backend is doing physics heavy stuff for the front end.
You must perform physics calculations on the backend if they are significant features that influence player positions. Node also only works off a single core.
Node of course can work on multiple cores, using worker threads [1]. You can even share large data efficiently using a SharedArrayBuffer.
Re: Show HN: I'm open-sourcing my game engine
#16Earlier quoted context omitted.
You must perform physics calculations on the backend if they are significant features that influence player positions. Node also only works off a single core.
Node of course can work on multiple cores, using worker threads [1]. You can even share large data efficiently using a SharedArrayBuffer. [1]: https://nodejs.org/api/worker_threads.html
There is still considerable overhead turning things into buffers and back. Was there ever a good reason given as to why passing an object to a worker normally has to convert everything to string and back? It is just so completely idiotic.
Re: Show HN: I'm open-sourcing my game engine
#17I've had some hobby projects that seem like a good fit here. The low-code and interactive editor make it nice for a hobbyist, even though I can code... there's a certain concentration I just don't feel like when I'm doing a hobby project.
For me personally the thing I've excited about is generating maps and worlds. It looks like the best way to do this is to export the game as JSON, programmatically edit it, and then import?
I'm a little intimidated though... the unedited tutorial world is 3500 lines of JSON. There's a lot to try to understand there.
My first idea at how to do that is to make deliberate edits and see how that changes the JSON (I also need to look up a nice JSON diff viewer). This will help point to the parts I want to touch. I'm also guessing I'll do things like collect assets and map tiles in the interactive editor.
Is this a reasonable approach? Are there tools to help here?
Re: Show HN: I'm open-sourcing my game engine
#18Re: Show HN: I'm open-sourcing my game engine
#19Earlier quoted context omitted.
You must perform physics calculations on the backend if they are significant features that influence player positions. Node also only works off a single core.
Node of course can work on multiple cores, using worker threads [1]. You can even share large data efficiently using a SharedArrayBuffer. [1]: https://nodejs.org/api/worker_threads.html
It isn’t trivial to just split up a game into múltiple worker threads and keep everything in sync. With Go, it’s much easier.
Re: Show HN: I'm open-sourcing my game engine
#20I'm surprised it's not written in Rust :thinking: