|
Internet Janitor posted:You double the computation budget per player. Have the player send key input to the server, and have the server run a local instance of the client. Both run in realtime and you can hash states or do whatever sanity checking floats your boat. It's infeasible today for most games, but eventually it may be fine. (And for simple turn-based games it could still work today.) With unlimited bandwidth and server-side compute capacity you can basically just make the client use a VNC protocol and run everything server-side. Well, sadly, you can't ever, even in a million years, just simply use a VNC-like protocol because real-world distances produce noticeable latency even at the speed of light. The idea of just totally mirroring player input for verification is pretty interesting, but one issue is that you don't necessarily know the state of the player 100% at the time of input because of dropped and inconsistently-arriving packets; and theoretically the client could cheat (a little) by pretending to drop packets that benefit it. I think this is probably more or less the eventual solution though. E: For example the round trip for a photon Shanghai to New York is ~80ms, which is enough to feel laggy, even if routing and computing were instant. E2: You could probably get a reasonable VNC-like pure solution if everyone interacted with a city-local 'node', and then those nodes did client side prediction for other nodes. That'd be fun to make. E3: This is essentially what you have today, but everyone has a room-local node. Either way someone has to be doing 'client side'-prediction to hide latency, even with 0-cost routing and computing. VVV 
Unormal fucked around with this message at 02:54 on May 10, 2012 |
#
?
May 10, 2012 02:43
|
|
|
|
| # ? May 25, 2024 00:17 |
|
|
Good point. You could, however, have actual users run a VNC-style thin client a short hop to semi-local servers (which are trusted), and then use a conventional network architecture that doesn't have to worry about cheating between those servers. OnLive uses a very similar approach. Based on what I've read, the latency is noticeable but not enough to destroy gameplay. For turn-based games, where latency on the order of seconds can be acceptable, you're golden even with my pie-in-the-sky thin clients. Edit: Haha, we're on the same wavelength here. ^^^ Main takeaway is that the multiplayer approaches that are feasible absolutely depend on the style of game.
|
|
#
?
May 10, 2012 02:52
|
|
|
Unormal posted:Well, sadly, you can't ever, even in a million years, just simply use a VNC-like protocol because real-world distances produce noticeable latency even at the speed of light. I kind of have to  this a little. The circumference of the globe is about 40K km, and the speed of light is about 300K km/s. So assuming a worst case distance (which is unlikely) of halfway around the world, a player with a game connection at the speed of light would only be experiencing input lag of ~120ms. Assuming a player is within 2000km of a server, a speed of light line would have 6ms lag time.Heck, look at a service like OnLive, that is actually providing VNC-like game playing experiences. When I played during the beta I was able to play twitchy platforming titles without ever noticing input lag. I can only imagine they've improved their infrastructure since then.
|
|
#
?
May 10, 2012 02:53
|
|
|
If we want to be entirely theoretical rather than present-day practical, we actually can assume that computation is close to instantaneous if we're traveling along a sufficiently long path. Just make the cables out of unrolled pipeline stages! Every part of the computation that is a pure function can be computed by a DAG of logic gates, and provided sufficient parallelism you could allow an arbitrary window for recurrent computation. Another wildly impractical approach would be to use a Reversible programming language to model the evolution of game state. At any time you could request that clients send their state snapshot and attempt to roll them back to confirm they match earlier views.
|
|
#
?
May 10, 2012 03:15
|
|
|
Pfhreak posted:I kind of have to Unfortunately the internet runs slightly slower than the speed of light. The bits may move at the speed of light, but there's a delay created when computers route those packets. It's been a long time since I've worked for a large network, but back in 1998 the best case (that is, an otherwise unused chunk 'o fiber that we were adding to the network) delay between our data center in NYC and one in San Francisco was 12ms. Straight line between the endpoints was ~2500 miles. I imagine in the intervening 14 years they've shaved some time off that but I would have doubts they've reached actual light speed.
|
|
#
?
May 10, 2012 03:24
|
|
|
Unormal posted:The only workable option I've really seen is to trust each client A LOT when it comes to the world physics, basically making the player a server for any physics object they 'grab' first. This minimizes snapping, at the cost of having to place a lot of trust in the client. Just checked UT3 against a laggy server and it looks like it does indeed not predict vehicles at all, so I guess it's playable.
|
|
#
?
May 10, 2012 03:36
|
|
xzzy posted:Unfortunately the internet runs slightly slower than the speed of light. The bits may move at the speed of light, but there's a delay created when computers route those packets. Actually, it's not even that good. The "speed of light" generally refers to the speed of light in a vacuum. The wave propagation speed through, say, coaxial cable is something like .6 - .8 (60-80% of the speed in a vacuum), and Cat5 is something like .7. This doesn't even include factors like speed lost to switching and routing.
|
|
|
#
?
May 10, 2012 04:23
|
|
|
So since we are on a network discussion, can someone explain to me what the realworld differences between UDP and TCP? I mean I understand all of the theory, but how much slower is TCP going to be under realistic conditions?
|
|
#
?
May 10, 2012 05:29
|
|
|
Well, the general consensus is that you shouldn't use TCP for real time games. I'm no expert but here's some reading from my past research: Here's gaffer's discussion on UDP vs TCP: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/ Here's a techy paper on TCP and why it sucks in games: http://mmnet.iis.sinica.edu.tw/pub/chen06_tcp.pdf ...also for the general discussion, I dug through my bookmarks some more, and here's a good list of more multiplayer articles: http://www.gameproducer.net/2006/12/16/planning-is-essential-in-writing-multiplayer-network-code/ e: also we could shave some time off our extreme future round trip VNC quake servers by drilling compute-tubes directly through the earth's mantle. e2: I guess this solves the question of why we can't see any huge civilizations out there. They all live in mega-dense compute planets dense enough that they're all within 70ms round-trip of each other, so futurequake isn't laggy. Unormal fucked around with this message at 05:53 on May 10, 2012 |
|
#
?
May 10, 2012 05:47
|
|
|
crazylakerfan posted:So since we are on a network discussion, can someone explain to me what the realworld differences between UDP and TCP? I mean I understand all of the theory, but how much slower is TCP going to be under realistic conditions? From what I gather, TCP always guarantees that the packets are received and that they are received in order, while UDP on has no guarantees at all on its own. So if you were making a multiplayer FPS and it used TCP then every packet would have to be received and acknowledged in order by each client, so basically the whole thing would grind to a halt pretty quick if you were sending a bunch of packets quickly. There are UDP libraries like lidgren that give you a lot more flexibility, so you can send a packet that is reliable and ordered like TCP, but you can have multiple channels so things don't get as clogged. You can also send things like unreliable sequenced packets that don't guarantee packets will get through, but if they do it makes sure they're received in sequence and any out of sequence packets are discarded which is good for things like sending player position where you send a lot of them but you wouldn't want to get any out of order. The bottom of this page has the different types of packets that lidgren supports.
|
|
#
?
May 10, 2012 07:07
|
|
|
crazylakerfan posted:So since we are on a network discussion, can someone explain to me what the realworld differences between UDP and TCP? I mean I understand all of the theory, but how much slower is TCP going to be under realistic conditions? When you run into that limit, or your ISP hiccups or something, your socket's queue will fill up and your sends will either fail or block and the other side will stall because the socket layer needs to figure out that it lost data, contact the other peer for a resend, and then wait for the resent packet. In the worst-case scenario, your side has to stop sending the most recent data because the queue is full. With UDP, adverse conditions cause packet loss instead, which means each side can continue sending their most recent data and doesn't have to wait for a resend when packets are lost. Unless, of course, that's what you want, in which case you can still build a reliable transmission protocol on top of UDP. OneEightHundred fucked around with this message at 22:01 on May 10, 2012 |
|
#
?
May 10, 2012 14:23
|
|
|
Lucid Dream posted:There are UDP libraries like lidgren that give you a lot more flexibility, so you can send a packet that is reliable and ordered like TCP, but you can have multiple channels so things don't get as clogged. You can also send things like unreliable sequenced packets that don't guarantee packets will get through, but if they do it makes sure they're received in sequence and any out of sequence packets are discarded which is good for things like sending player position where you send a lot of them but you wouldn't want to get any out of order. The bottom of this page has the different types of packets that lidgren supports. On the C++ side of things, I use RakNet for UDP. It does all of the "multiple channel" things that lidgren does, plus a plethora of other components for things like NAT punchthrough (for peer-to-peer games), lobbies, cloud servers, and even Steam support. At first it seemed quite daunting, but the tutorials and examples help illustrate things. It has a free license for hobbyists and those with less than $100K revenue.
|
|
#
?
May 10, 2012 14:25
|
|
|
An update on my RogueLike lighting engine, about which I posted earlier in the screenshots thread (1, 2, 3). Progress since my last post:
 Still to come:
|
|
#
?
May 10, 2012 20:16
|
|
|
Awesome, I was waiting for an update on this  So you'll be releasing it as an engine of sorts and not your own game?
|
|
#
?
May 10, 2012 21:12
|
|
|
I'm not sure if it'll be an actual engine, probably more of a "here's what I made, do whatever you want with it" sort of deal. I am starting to form an idea of the game I want to make with it, and the concept can be summed up as "top-down, turn-based Thief". Once I've released the lighting part I'll start working on a prototype, and hopefully from there on to a full-length game complete with a story and a level editor and all that jazz. But that's all such a long way off that I get discouraged even thinking about it, so for now I'll just focus on one thing at a time.
|
|
#
?
May 10, 2012 21:20
|
|
|
Unormal posted:Well, the general consensus is that you shouldn't use TCP for real time games. I'm no expert but here's some reading from my past research: I'm writing the code for multi-player networking in a game engine now and my main take away from those links were: quote:It probably warrants a blog article, but the reason Guild Wars uses TCP is that I felt the labor required to write a reliable transport layer on top of UDP would take too long: we’d run out of money fooling around writing transport code instead of writing a game. and quote:- their tests have also been performed with a loss packet rate of 4% ! I never encountered such high packet loss rate in my life (except if I unplug my network card ). Concretely, that means for their data sent 8 times per second (their testing base), something like one loss happend every 3 seconds ! This is even not coherent with their remark a few line before telling that some clients never encountered packet loss during the whole testing session.
|
|
#
?
May 13, 2012 15:37
|
|
|
OneEightHundred posted:On that topic though, one thing I'm still struggling with is how any modern physics engine interacts with this, especially for things that pretty much have to use the rigid body simulator (i.e. vehicles). Doom 3 went open-source recently, but its physics system is capable of iterating single objects which seems somewhat unusual. Bullet for example only iterates the full scene and has a fixed time step. From what I gather, this is pretty typical, and it looks like it MIGHT be possible to mass disable/enable objects to isolate the simulation, but I have no idea if this is true or not. An engine I've used had two physics systems built in. Havok and a home-grown one. Havok was run on all clients and handled tons of locally simulated object that wouldn't impact game-play. (In an office environment for example you could shoot computer monitors and keyboards and poo poo around all day and each client would simulate them on their own and who cares if they weren't all in the same place on the every system.) Anything that impacted game-play however was done on the server only and then position rotation were updated to the player through a prediction system that the player objects themselves used. This was mostly limited to projectiles and vehicles. Wasn't the greatest system, but it was a workable one.
|
|
#
?
May 13, 2012 15:49
|
|
|
I Was There... posted:I'm writing the code for multi-player networking in a game engine now and my main take away from those links were: Also building a reliable transport layer on UDP in a real-time game isn't that hard because both ends are constantly sending data, which means you can detect breaks just by tagging them with sequence IDs and checking if the one you got was in sequence. OneEightHundred fucked around with this message at 00:46 on May 14, 2012 |
|
#
?
May 14, 2012 00:38
|
|
|
The abstraction that TCP gives you is a reliable, ordered stream of bytes. If you do not need a reliable, ordered stream of bytes, you don't have to use UDP. Most real-time games do their own tracking (prediction with a ring buffer) so a packet being dropped isn't too a big deal.
|
|
#
?
May 14, 2012 00:56
|
|
|
OneEightHundred posted:I'd disagree that packet loss isn't a real-world issue or that TCP lets you just ignore it. At some point, you have to decide what to do when you call "send" and get WSAEWOULDBLOCK back and "disconnect the socket" is a bad answer. And I think that's what's meant by packet loss not being a real-world issue - not that there is no packet loss, but rather that intermittent packet loss is so rare as to not be an issue, and as such one of the major downsides of TCP (that in the event of a dropped packet there is more than a full round-trip delay to sort it out) is something that doesn't really come up. In a high-traffic situation you're right though, if you're pouring packets out as fast as they'll go then TCP is a disaster, and a custom UDP protocol can be better able to cope with that situation by being designed to catch up later if packets are missed - but doing that also introduces a wealth of extra considerations that make things more difficult, like avoiding setting up a situation where a player can deliberately intercept and drop packets to get an unfair advantage (effectively introducing lag to their opponents but not to themself). So for many products it might be preferable to just use TCP and make sure you're not sending an unreasonably high volume. (And let people get disconnected if they try to play while torrenting or whatever.) It's also difficult to detect, with TCP, whether you're approaching saturation of the connection.
|
|
#
?
May 14, 2012 01:15
|
|
|
Current WIP http://www.youtube.com/watch?v=kLbB-C_Weko&feature=g-upl I may or may not recode in XNA\Monogame when it's closer to being done. Torque2d has been good for prototyping and I haven't run into many issues with it yet. It has it's own scripting language which is decent enough. I've never done C# before, but hopefully it's similar enough to Java which I've done loads of. Back in the day I used C++ and SDL a lot. I'd rather focus on content and assets right now, and worry about coding an engine if needed later once I have a solid idea how everything's going to work. SSH IT ZOMBIE fucked around with this message at 06:12 on May 14, 2012 |
|
#
?
May 14, 2012 06:08
|
|
|
I had a pretty sweet weekend where I got my head around some big pieces and got them implemented in-game. I also got a family member to make some concept art for characters and sets which helps motivate me even more.
|
|
#
?
May 14, 2012 19:19
|
|
|
roomforthetuna posted:If your game sends very little traffic (bytes-wise), haven't you just set up a false situation with that question? In a low-traffic context, a WSAEWOULDBLOCK means nothing has gotten through for well over 5 seconds, in which case dropping the connection is probably what you'd end up doing with a custom UDP protocol anyway, because nothing getting through for that long probably means someone's computer has crashed or got disconnected.
|
|
#
?
May 14, 2012 19:54
|
|
|
OneEightHundred posted:If you're ever at danger of saturation, then TCP loses its main benefit since you'll have to implement an application-level resend mechanism.  Not entirely kidding, some non-twitch games could be good with that solution, so long as there's a "give up and drop the connection" timeout on it. (Though I'm not sure about a non-twitch game that has so much traffic that that would happen.)
|
|
#
?
May 14, 2012 22:15
|
|
SSH IT ZOMBIE posted:Current WIP Serious question: Is the editor/builder interface in Torque2D the same buggy, unreliable, nearly useless piece of junk it was back when it was still called Torque Game Builder? I've tried using Torque 2D dozens of times over quite a few years, and it's always been crashy and worthless. It's gone full circle from being called Torque 2D -> TGB -> Torque 2D, but it never seems to evolve. Do you find it reliable and user-friendly? Are the "not many" issues you've run into builder-related, or programming language-related?
|
|
|
#
?
May 14, 2012 22:26
|
|
|
Centripetal Horse posted:Serious question: Is the editor/builder interface in Torque2D the same buggy, unreliable, nearly useless piece of junk it was back when it was still called Torque Game Builder? I've tried using Torque 2D dozens of times over quite a few years, and it's always been crashy and worthless. It's gone full circle from being called Torque 2D -> TGB -> Torque 2D, but it never seems to evolve. Do you find it reliable and user-friendly? Are the "not many" issues you've run into builder-related, or programming language-related?
|
|
#
?
May 14, 2012 23:50
|
|
|
Centripetal Horse posted:Serious question: Is the editor/builder interface in Torque2D the same buggy, unreliable, nearly useless piece of junk it was back when it was still called Torque Game Builder? I've tried using Torque 2D dozens of times over quite a few years, and it's always been crashy and worthless. It's gone full circle from being called Torque 2D -> TGB -> Torque 2D, but it never seems to evolve. Do you find it reliable and user-friendly? Are the "not many" issues you've run into builder-related, or programming language-related? I guess I should say, not many issues I can't work around  The quirks are all over, builder, programming, and game related. But, thus far, everything is resolvable, and I have not seen any unexpected behavior. What I have been able to resolve in code has been reliable. The game editor is slightly buggy and unintuitive, but it's never outright crashed on me. For some things I end up not using the editor, and editing things directly in a text editor. Every problem I've run into, someone's resolved, since it has a somewhat active community and it's been around for so long. It's used in schools a lot it seems. I basically am using it because it's royalty free, and they support a lot of platforms. Also I'm on an Mac now. SPAZ uses Torque2d. If you've run into anything weird that you haven't resolved, let me know. I've seen and resolved a ton of crazy poo poo. - Text elements get set to NAN width and height if you change the camera's width and height before adding a text element - Don't copy paste tile layers. The pasted layer will inherit properties of the copied layer, like, what map file it's tied to, and when you save it you'll overwrite the data in the original layer. But you won't know that until you reload the project. - Weird white glitches around sprites - set filter pad on. It doesn't seem to do anything when smoothing is off, except fix the white glitches. - Physics on trigger boxes that make your physics applied t2dSceneObject wonky - VSync off by default - Weird frame-skipping, caused by the game loop having a big delay in it by default - If you set a t2DSceneObject on a path, it won't keep track of it's X\Y coords anymore I think that's all the major stuff I've run into.
|
|
#
?
May 15, 2012 00:29
|
|
|
I have a problem with SDL_mixer; When I load wav file through Mix_Loadwav, everything works fine, but if I load same file through Mix_LoadMus, I get "Unrecognized music format" error despite the documentation stating that Mix_LoadMus supports wav files. Mix_GetNumMusicDecoders returns 0 so apparently I have no functioning music decoders for whatever reason (perhaps I initialize the mixer wrong?). I probably could just play music through Mix_PlayChannel instead of Mix_PlayMusic but I'd rather use the proper functions. My code in question http://pastebin.com/UnuVNCfr Manager class that manages sound effects and music. http://pastebin.com/GQv0pF7A Handles music. http://pastebin.com/zAp2ehkS Handles sound effects.
|
|
#
?
May 16, 2012 12:33
|
|
|
Valtis posted:I get "Unrecognized music format" error despite the documentation stating that Mix_LoadMus supports wav files. Mix_GetNumMusicDecoders returns 0 so apparently I have no functioning music decoders for whatever reason (perhaps I initialize the mixer wrong?). Did you build SDL_mixer yourself? Looking at the docs, I think Mix_GetNumMusicDecoders returns the number of formats the library is capable of decoding at runtime, and then you iterate through them and fetch the descriptions from Mix_GetMusicDecoder. I imagine Mix_GetMusicDecoder returns strings like WAVE, etc
|
|
#
?
May 16, 2012 17:45
|
|
|
GetChunkDecoder at least returns wav & riff formats so I imagine it would function similarily if I had decoders. I did build the source files into static link library so perhaps I somehow managed to drop the support there? This is first time I use SDL_mixer myself so I'm probably making tons of elementary mistakes.
|
|
#
?
May 16, 2012 18:02
|
|
Nalin posted:They just changed the name to Torque 2D. GarageGames has said that they want to redo Torque 2D on the Torque 3D engine and use the T3D tools, but that hasn't happened yet. Their focus is pretty much entirely on T3D / iT2D at this point. This is their latest T2D update. It's been over a year since then. They've actually just changed the name back to Torque 2D. That's part of what makes me wary. Yeah, it looks like Torque 2D is the same borderline abandonware that it's always been, with updates spaced at just the right spots so they can keep selling it on their products page. SSH IT ZOMBIE posted:I guess I should say, not many issues I can't work around Thanks for the information, that sounds like just about what I was afraid of. There are just too many bugs in the Torque builder to make it worthwhile when there are so many options out there, now. In my opinion, Torque 2D/Torque Game Builder is one of the biggest disappointments, ever, in the indie programming world. Torque 2D has so much potential, and is actually kind of fun to use, but it is simply crippled by it's crappy design. It's been, like, the greater part of a decade, now, those bugs should be fixed.
|
|
|
#
?
May 16, 2012 18:35
|
|
|
Centripetal Horse posted:In my opinion, Torque 2D/Torque Game Builder is one of the biggest disappointments, ever, in the indie programming world. Torque 2D has so much potential, and is actually kind of fun to use, but it is simply crippled by it's crappy design. It's been, like, the greater part of a decade, now, those bugs should be fixed.  But at least they are focusing on making progress on one engine now, instead of making zero progress on a dozen engines.
|
|
#
?
May 16, 2012 19:30
|
|
|
Valtis posted:I did build the source files into static link library so perhaps I somehow managed to drop the support there? I would think so, SDL_mixer is not very monolithic and depends on a lot of other libraries to provide its decoding support (libvorbis, etc). I'd look into trying the pre-built binaries if possible, if not then investigate re-building the library with the additional libraries for the decoder support.
|
|
#
?
May 16, 2012 19:41
|
|
|
It looks like that the prebuilt binaries are available for linux and Visual Studio but not for gcc unless I badly misintepret the files here http://www.libsdl.org/projects/SDL_mixer/. I've downloaded all the files and there are *.a files in linux archives and *.lib file VC archive but no *.a files available for windows distribution. Why can't the C++ standard or compilers agree on name mangling so that I could use the VC libraries  .Edit: It actually does compile with the provided *.lib, so I think it's safe to say that I'm suffering from a massive case of retardation. Edit2: And other than 3 - 4 segfaults I had managed to introduce, it now works as it's supposed to. Valtis fucked around with this message at 21:24 on May 16, 2012 |
|
#
?
May 16, 2012 20:49
|
|
|
Valtis posted:Edit: It actually does compile with the provided *.lib, so I think it's safe to say that I'm suffering from a massive case of retardation. Which win32 gcc are you running? I've always had to resort to building libraries by running their configure scripts in MSYS
|
|
#
?
May 16, 2012 21:28
|
|
|
Latest MinGW, which I think is based on gcc 4.62.
|
|
#
?
May 16, 2012 21:34
|
|
|
It's pretty sweet that it can use .lib files now.
|
|
#
?
May 16, 2012 22:31
|
|
|
Now that I think about it, SDL_mixer is written in C and likely any libraries are compiled with C compiler so the names aren't mangled and there shouldn't (and isn't in this case) any compatibility issues. If only I had actually thought about that earlier.
|
|
#
?
May 16, 2012 23:11
|
|
|
Made something which might be slightly useful: https://code.google.com/p/lwmpeg/ Specifically, the mp2dec sub-library has an absurdly simple API and the integer decoder is very fast. You'll need to encode at a high bitrate though because MP2 kind of sucks. Also I think you might need to change <intrin.h> to <intrin_x86.h> if you're compiling with gcc.
|
|
#
?
May 17, 2012 03:37
|
|
|
|
| # ? May 25, 2024 00:17 |
|
|
I'm trying to draw a think line between two points in OpenGL. I'm figuring--for now--to use a cube mesh of 1 unit length on all sides and just muck with the position, rotation and scaling. Doing position and scaling is simple enough in its own right, but rotation is messing me up. My first impression was this was a job for atan2, doing something in the spirits of: X axis rotation = atan2(y, z) Y axis rotation = atan2(z, x) X axis rotation = atan2(x, y) But I see I'm doing some multi-axis rotation for things like, say, connecting (0, 0, 0) and (5, 5, 0). How should I approach this?
|
|
#
?
May 17, 2012 15:33
|
|
