Live data from Hacker News

Show HN: I'm open-sourcing my game engine

github.com

51–60 of 94 posts

Re: Show HN: I'm open-sourcing my game engine

#51

A sure way to never finish a game is to start by writing an engine. You can absolutely make your own tech but at every step that tech should be tailored for your project, as opposed just a general game platform.

I'm going to start a blog! And by "start a blog" I mean write a whole new blog engine entirely from the ground up...

Maybe not a great example, you can make a simple blog from scratch in like 20 lines of PHP/MySQL. I did this as a young teenager by copy-pasting some example code from Tizag's MySQL tutorial (which amazingly is still up, in its original condition![0])

(I wish I could share the original code, but I don't have it here.)

[0] http://www.tizag.com/mysqlTutorial/

Re: Show HN: I'm open-sourcing my game engine

#52

The android app sign up page seems to want me to enter my Google username and password _inside the app,_ in what looks like a web form, but as a user I have no way to tell if the app is snooping on my password. It seems like Apps usually navigate away to a sign in, and then navigate back. Is that pattern hard to implement? Is the issue about cross platform support? Thanks

This is called OAuth 2.0 and is trivial to implement with something like Okta.

Re: Show HN: I'm open-sourcing my game engine

#54
post #36
post #32

Earlier quoted context omitted.

IO game is a catch all term for these types of mechanically simple, multiplayer, web-based games . The name comes from the fact that many of these games are hosted on .io domains. Well known examples are agar.io and slither.io.

And the biggest platform for them all, itch.io.

Itch is not exactly a platform for IO games, sure you can put them there, but it hosts a lot of other stuff such as experimental and "extremely indie" games, software tools... It is a platform, storefront and community for things game developers make.

IO games on the other hand are usually characterised by being (sometimes only allegedly) multiplayer web browser games with super minimal friction, just open a page and play.

Put differently, I wouldn't call a supermarket a toothpaste store even though that is indeed an item supermarkets sell.

Re: Show HN: I'm open-sourcing my game engine

#55

I joined one of the Brains server and was curious what the experience was for 50~ players. The movement was a bit janky, as expected from websockets. I was also curious about the networking compression, because I'm doing something similar. I'm not sure if just doing LZ-string compression is enough. 50 players use about 20KB/sec data. Comparing that to Warzone at 150 players uses only 48KB/sec data. Unless you have un…

>The movement was a bit janky, as expected from websockets

Could you elaborate on this? I played a few "io games" and it seemed pretty smooth (except for the occasional laggy player).

On the other hand, I did a bit of testing with WebSockets a few months ago. If I understand correctly, there are significant downsides to using TCP for games (or any latency sensitive communications for that matter): TCP header being >2x bigger than UDP, additional control packets, and TCP delays transmission of new data while old (stale) data is retransmitted. So WebSockets have these same downsides, due to being hosted over TCP.

Despite all that (TCP supposedly guaranteeing delivery of WebSocket messages), I was able to produce packet loss. So you have the downsides, and as far as I can tell you don't really have the upside, since if you actually want guaranteed delivery you still need to build your own thing on top of it (which you could have just done on top of UDP in the first place, at least for messages that need it!)

(Take this with a grain of salt, aside from a bit of dabbling I have close to zero knowledge and experience with networking.)

Re: Show HN: I'm open-sourcing my game engine

#57

I joined one of the Brains server and was curious what the experience was for 50~ players. The movement was a bit janky, as expected from websockets. I was also curious about the networking compression, because I'm doing something similar. I'm not sure if just doing LZ-string compression is enough. 50 players use about 20KB/sec data. Comparing that to Warzone at 150 players uses only 48KB/sec data. Unless you have un…

Movements pretty tight in our websockets: https://gooberdash.winterpixel.io/ It's all about the client side prediction & roll back networking algorithm. Our game states end up being ~1kb at 30hz, which typically fits into a single packet, so websockets aren't terrible. An unreliable protocol would be better, of course.

>client side prediction & roll back networking algorithm.

I need to look into this! I made a little networked 2D physics thing (just bouncing balls) and I was surprised how well it stays in sync, because of course both machines just simulate the same result.

I added some interactivity and simulated lag / packet loss, at that point I added an interpolation function so an entity could have a "target" and gradually slide there over a few frames. I've seen some other games do that as well.

I haven't gone very in depth on this, but VALVE has an excellent article on the subject, also covering input prediction and lag compensation:

https://developer.valvesoftware.com/wiki/Source_Multiplayer_...

Re: Show HN: I'm open-sourcing my game engine

#58
post #14

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?

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.

This is pretty much spot on. Having a low barrier of entry (no download/signup/paywall) + being easy to use certainly helps.

Re: Show HN: I'm open-sourcing my game engine

#59

The android app sign up page seems to want me to enter my Google username and password _inside the app,_ in what looks like a web form, but as a user I have no way to tell if the app is snooping on my password. It seems like Apps usually navigate away to a sign in, and then navigate back. Is that pattern hard to implement? Is the issue about cross platform support? Thanks

This is called OAuth 2.0 and is trivial to implement with something like Okta.

Or we could not encourage depending on a constantly-breached centralized “security” authority. https://hn.algolia.com/?q=okta
Post reply on HN