I’ve been working on a multiplayer archery survival game for the past 7 months called Bowdown. You can play it at https://bowdown.io
I recently made the git repo public: https://github.com/jacklaplante/bowdown
So please feel free to check out the code. I try and describe the general organization of the game in the README but don’t hesitate to ask me questions or give feedback.
I hope this can help someone. I might be taking the game down soon because the AWS bill is almost 200$ a month at this point and I’m not making any money from this project.
I seem to remember that AWS offers 1 year free package to new users, so if your friend registers… well. If you had single player mode, you could host directly on github ) And I would not have these:
I’m a bit confused, is it a multiplayer game?
Edit: nevermind, i just didn’t came across anyone yet
If the game doesn’t meet the intended scale, then why not switch to a cheaper service? Perhaps it wasnt advertised enough to attract a player base?
But to be perfectly honest the game doesn’t really seem ‘finished’ per se. While the style and vibrant colors are really pretty, the collisions and controls feel super clunky. Also I don’t really like the authoritative client.
Obviously its completely fine if its meant to be just a fun game for friends and some internet enthusiasts
However if your aim is to make money with it, then there is lots of room for improvement. Nothing wrong about that though. We’re all learning here. There are TONS of resources on MMO node.js games, so Im sure, with time, its gonna get much better. Keep at it
I like the concept, so I hope it achieves success
Trust me I know there’s lots of room to improve but as I tried to do more complicated things it started to feel like I was really going against the grain with my decision to not use a mainstream game engine. So I’m exploring Unity now (side note: the multiplayer support is surprisingly terrible so maybe I’ll try Unreal).
My breaking point was when I tried to add non player enemies to the game and trying to figure out how to do a server side nav mesh seemed impossible.
Thought I’d chime in about server costs. I have factored this into my development plans for every project I have worked on. Usually it’s a trade-off between development costs and up-keep. You can write a super-optimized server in C++ that will run on a 3$/month VPS, or you can write a node.js server that will require you 200$/month in hardware to run.
If you can write a server in that will be very cheap to run, but it will take you a year vs expensive to run, but 1 week to develop - it’s a tough call sometimes. Usually development speed wins.
That got me thinking: How would one go about making a Three.js world state in C++. I guess a completely different engine would be used for that, but how compatible would that be? How much more efficient?
Probably a matter for a different time (or thread)
I’ve put a bit of research into that topic and you can checkout my conversation about it here
I actually almost got a working solution too, but it was all so hacky and inefficient.
I saw c++ port of three.js a year ago, because someone hired me to compile a demo with it. It is still client side, but I mean, it is easy to do no-op renderer that only updates the matrices.
yes, it was something off the github. maybe 2nd one, I basically picked the one that had more examples at a time.
I just wanted to add that I realized that about half my server costs were due to the fact that my message size was way bigger than it needed to be. Each client was sending JSON messages every frame to the server. And the server was sending JSON messages to every client, 10 times per second. My messages could have been wayyy smaller if I made packets with a byte array.
Something worth thinking about!
or you can try to use RTCPeerConnection API to exchange the data (yes, it is not only for VOIP or streaming videos (no, I could not find a single working example :))
There are large scale projects out there working just fine, porting to c++ is really not required at all. I would rather recommend focusing on a reasonable optimized code and solving the actual problems, they don’t lie in js, websockets nor in THREE.
as I understood this, it was not much about porting (to make a desktop c++ client) but running the same (or very similar) logic on the server - and c++ port could help with that