What I Learned Coding X-Wing vs TIE Fighter (1999) | Hacker News Reader

What I Learned Coding X-Wing vs TIE Fighter (1999)

gamasutra.com

166 pointsdpeck24 comments

Man, brings me back to my childhood. It's still disappointing to me that there hasn't been a game in the x wing/tie fighter mold - for me it would be a killer app for vr.

How about FS2Open? Fantastic series of games, even more fantastic engine. Someone should get on VR support, would be a good Elite:Dangerous competitor.

FS2Open "Getting Started": http://www.hard-light.net/wiki/index.php/Getting_started

Demo of the associated kickstarted game "Overload": http://playoverload.com/playable-teaser/ Copied from that link: The teaser includes VR support for the Oculus Rift only. The final launch of Overload will support other VR devices.

Apparently newer Overload demos include eye tracking support: https://youtu.be/jcXWpL9CMps

Descent: Underground Early Access claims VR support and is $15 (50% off) on Steam right now: http://store.steampowered.com/app/360950 Reviews say there's not much there yet though.

I got E:D and FS2 for Christmas and I'm spending all of my time with FS2. Single Player is great and even with crazy settings it runs great.

I would highly recommend the VR demo that you can download for free if you have Battlefront and Playstation VR. Played on it at a friend's over Christmas and was absolutely blown away. The resolution isn't awesome but it's so well done: there's literally no perceptible lag when you look around so it's a much more immersive experience than, for example, demos I've played on the Oculus Rift.

Went home and immediately ordered a PS4 Pro and Playstation VR on the strength of it. Wondering how hard it would be to start hacking around with it. Honestly, I haven't been blown away that much by a game since I the first time I played Doom way back in 1994.

I've had great moments with VR, but realize that in the end its just a tech demo and feels rather shallow. There's nothing I can see myself spending more than a few days with.

Give me a team star wars game with mission objectives and voice chat for your squadron and for me, the future will have arrived.

what about House of the Dying Sun? (http://store.steampowered.com/app/283160/)

Eve Valkyrie?

I had high hopes but it's just not quite there.

Interesting link but definitely needs a [1999] qualifier in the title.

The obligatory http://fabiensanglard.net/quake3/network.php

Thanks for posting that - it's basically a case study on how to do a good job of implementing the communication for a networked multiplayer game. Extremely handy.

The only bugger of it is that there's still no across the board UDP support in browsers(1) which means if you're building games with HTML5 and JavaScript, whatever you do, you're still using TCP, which is a PITA. It's actually even worse: WebSockets obviously a bunch of HTTP guff on top so it's not even like you're using vanilla TCP. At present I don't think there's any way to use raw TCP from JavaScript.

This obviously isn't a big problem for slower paced or turn-based games but it's a total pain in the neck for anything that has real time dynamics (FPS, many types of 2D arcade game, etc.).

(1) There is WebRTC, which is apparently UDP-based, but it's not yet supported across all browsers: http://caniuse.com/#feat=rtcpeerconnection. It's also meant for peer to peer so may or may not be a good fit for the kind of client/server/master game state comms you'd need for a multiplayer game. (I suppose you could utilise one of the clients for the master state but this is obviously open to abuse given that JS runs in a completely insecure execution environment - anything can get injected in there.)

So would it have worked better to send the entire game state every frame/every N frames/etc so that a dropped UDP packet would not totally trash the game? I don't know what the maximum frame size is for UDP.

You can only assume a MTU of about 1500 bytes, unfortunately. However, instead of sending each packet effectively twice as in the original article, you can use FEC to require only 2 of 3 packets to be received for example [1].

But yeah, WebRTC for example also effectively implements resending the whole state - if you get too far behind, the receiver can request a video keyframe from the sender.

[1] https://tools.ietf.org/html/rfc5109

That's what Valve is doing for their games (see their Source engine docs.)

However, you don't always send the entire "world", but a delta-encoded version of it (the server keeps a history of the world state and a timestamp for each client, so it can send only what has changed since the last acknowledged packet.)

Depending on the game you have to do a bit more work (interpolating changes so it always looks smooth even if packets are dropped, latency compensation, etc.)

The whole bit about TCP being evil and hopelessly broken made me laugh - its funny to imagine these guys as complete network beginners :)

Its also ironic that people building networked games today are making the same mistakes - and it all starts from a huge misconception of how the internet and its protocols really work.

For as much as we like to think of ourselves "clever", networking is one area where intuition usually leads to terrible implementations :)

I made a tribute to these games: http://aeonalpha.com, it uses TCP/HTTP and the backend is open source: http://fuse.rupy.se/fuse.html

"[TCP is] why we would see latencies in the 5-second range." So much has changed. :)

Well, the writer's bio lists his game making achievements, but the take on networking reminds me of the phrase "Let the cobbler stick to his last" ( http://proverbhunter.com/proverb/let-the-cobbler-stick-to-hi... )

Are you saying that he didn't know what he was talking about? Because in 1999, the internet was terrible for games. Most people were still on dialup!

It is interesting to compare this to congested public wifi (congested internet connection behind the wifi). Or Comcast in some (many?) cases for that matter... Congestion is worse these days but when things go well bandwidth and latency are much better. UDP is also a "if there is any congestion drop this first" flag (first attempt retry via a tcp connection that is kept open but normally not used might be an interesting tactic to try these days).

With bittorent and browsers opening a zillion connections at once, a single connection can be easily swamped. For those of us using a VPN past the ISP, that means everything, but a game with a single connection is likely just as vulnerable. These days (if not using a server) having clients each send their data and what they received from everyone else to all other clients might be more likely to work.

Damn right. I remember playing the original Unreal Tournament and if you had a ping time under 350ms you were doing incredibly well. It was about the slowest you could have whilst still having any chance in the game.

And that was of course fine until these people with cable or DSL broadband started getting in on the act with their 70-80ms ping times, and wiped the floor with all us saddos still on dial-up connections. (Or equally, you'd get some cocky sod jump on from their university network and, equally, annihilate everybody else.)

"TCP is evil. Don’t use TCP for a game. You would rather spend the rest of your life watching Titanic over and over in a theater full of 13 year old girls."

OK, I giggled at this! :D

I'd add a condition to that to say don't use TCP for a realtime game. For turn-based games, it works great and the inherent benefits of TCP (retrans, in order, etc) can be used to simplify the netcode.

On a related-but-not note, I wonder if 13 year old girls react the same to Titanic now as they did when it was in theaters? I'll find out in about 11 years myself but curious if anyone has anecdotal evidence.

Reply on news.ycombinator.com