oliii

Members
  • Content count

    7312
  • Joined

  • Last visited

Community Reputation

2196 Excellent

About oliii

  • Rank
    GDNet+
  1. Understanding Peer 2 Peer

    You just need better authentication / encryption.   Basically, never work with raw sockets and IP addresses directly, if you can avoid. Negotiate P2P secure connections, preferably via a secure server, which can also help with the NAT punch-through and packet reflection.    Even then, don't trust the data send by clients. But it's more about game hacks and exploits, and how your game handles cheating, rather than a straight-up security issue.   Roughly how it looks in APIs such as XBox Live, PSN ...   1) player A creates a game session. That game session then resides on a secure server.    2) player A registers himself with the game session (probably part of the game session creation process anyway).   3) all communications between game server and player A are uniquely encrypted and secure.   4) player B searches for the game session.   5) player B finds the game session, then registers himself with the game session.   6) all communications between game server and player B are uniquely encrypted and secure.   7) player A gets notified by the game server that player B is registered with the game session. Received security information on how to connect to player B.   8) player B gets notified by the game server that player A is registered with the game session. Received security information on how to connect to player A.   9) Player A, or player B, or both then attempt to connect to each other. Their communications will be encrypted, and only decipherable by them (ideally).    and so on...   The game layer sees secure addresses being established under the hood, with payloads coming in. The game code doesn't really deal with raw IP's any more (on steam, it's just player Steam Ids). Which makes it a little bit tricky as far as debugging is concerned, but hey.
  2. i keep buying games and they're not what i expected

    BTW, The Wicher 3 is on sale on Steam right now (at least UK), £18. Well worth the price. 
  3. The first video game enemy you ever murder.

    I have 20,104 notches on my minigun that say you're way off the target.
  4. And the Best President for America is…

    As if a person's character has no bearing on their behaviour and, when in a position of power, has no influence on the amount of damage they can inflict. Recent history shows just that. And why people pay attention to what the guy who will be supposedly in charge says. Long gone are the days when voting equated to selecting between John Jackson and Jack Johnson. I guess now it's more between John Jackson and Mecha-Nixon, and I wish all the best to Bernie. I hope his bureaucrat sex-appeal and sensible fiscal policies swoon the electorate. Enough with demagogues and plutocrats! Feel the Bern 2016! Yay? Who's with me?!?
  5. Syncing Client/Server

    A coarser grain is detrimental. After all, you need to send those 'bitfield headers'. Assuming you do delta on single bytes, for the sake or argument, the gain will only 1/8th compression at best. A vector is usually atomic. One component changes, it's safe to assume the other components also changed to some degree as well. If you run into long lengths of bitfield headers (lots of little components changing all over the place), it can mean you need to optimise those components in groups based on their frequency and times of change. Thus reducing the header size, and the frequency of delta transmissions. You can even write meta-data statistics about it, and estimate how you could improve your traffic by bundling up components more efficiently. Something i actually experimented with before. The delta-encoding was on fixed-lenght byte buffers. I run a crude statistical analysis on the frequency of byte changes. I remapped the byte order in order of frequency of change. That gave me runs of contiguous bytes that would change and not change at roughly the same time. The static data that never changed, for example, up front. Then I ran a simple RLE to build up my delta packets. That gave quite a decent compression. Not optimum as more application-aware delta-compression algorithm, but hey.
  6. Syncing Client/Server

    The server shouldn't be building caches. Or to be more precise, he should be building caches for each client. SO, no client, no cache.   1) client connects. 2) The cache for that client is empty. Therefore the delta against an empty cache is a full state. Therefore the server sends the full state.  - NOTE : the server would eventually keep sending full states, until the client starts acknowledging something. - NOTE 2 : can have a blocking full state : Send the first / full state reliably, then wait for the client to ack the first state before sending him delta updates.  3) server can send delta to that client from now on, since he received a ACK from the client.    It's easier to see the client as an observer of the game state. What you send to the client is his view of the game. And subsequent updates are changes to that view. The SQN / ACK numbers are only there for 1-to-1 transmission, and are not a global number used by all clients. Although you can do that too, but from experience, unnecessary and quite messy. 
  7. Tire Slip Angle

    What's the velocity of a point at the contact patch? Vcp = Vcar + WheelDirection * WheelAngularVel * WheelRadius. 1) When a wheel is free-rolling, it means the velocity at the contact patch is zero. Meaning the rotation and direction of the wheel cancels out the car linear travel of motion exactly. Vcp = 0. 2) The steering starts turning the wheel. The wheel direction is not aligned with Vcar. So Vcp will now be != 0. 3) when you apply the handbrake the wheel rotation is now Zero. Therefore Vcp = Vcar. 4) when you apply too much power, the angular velocity of the wheel becomes greater than Vcar. It's the opposite effect. To calculate speed_y and speed_x, it's Vcp, but projected along the wheel direction vector, and the other component, perpendicular to it. That's the simplest version of tire dynamics, of course :)
  8. The first video game enemy you ever murder.

    A punk with a switchblade in some crappy text RPG game. He wanted my shoes. I had two choices : 1) run away. 2) kill him with the lead pipe I just found. > I choose the lead pipe. I moved on to bigger, better things in Ultima VI.
  9. What's the scope of what 1 person can do in gamedev?

    Mobile game development, or mobile-style game development (bigger market on mobile). Even then, it takes a lot of time, effort, and money, especially for single person. The biggest drain in time (and therefore money) is assets. If you can somehow make a good fun game with very few assets, or at least a prototype (E.g. Geometry Wars). Tetris, angry birds would be that kind of game I would aim at. Something that's basically doable as a quick game design competition entry (game jams), and can then be expanded on to a fully fledged marketable game if the concept has staying power. Even game jams can be a pretty tall order, and sometimes require a small team (couple of guys, artist and programmer).
  10. Could Trump make Video-Games 'Great Again' if elected?

    Defend Texas against hordes of mexicans! Build that wall! Man those watchtowers! Fun for entire family!   It has potential.
  11. How can I open my game to lan?

    It really isn't complicated to be honest. If you're used to sockets, it's just a regular UDP broadcast version. http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html#broadcast you can have a broadcast socket on the server, and regularly 'ping' the LAN (every few seconds) with packets containing the game server information (name, IP and/or port, number of players, or whatever you feel should be of interest to the clients). Clients listen to the pings, extract the game server information, and then can connect to the game server.    Or you can do the opposite, clients send pings through a broadcast socket, the server listens to client requests, and reply to the client with the game server information. In a small scale environment, it doesn't really matter which way you go.
  12. Driving AI - tips for a beginner?

    A few ideas... Although I'm not a specialist. Generate paths for your AI to follow, heading, position, and speed to target. If you use virtual inputs (brakes, steering, throttle), use P.I.D. controllers for smooth AI driver inputs. Have some idealised representation of your vehicle so the AI can anticipate (braking distance, lateral and longitudinal grip limits, weight transfer, mass and inertia). You can 'cheat' a little. For example, anti-lock braking systems, traction control, stability control, four wheel drive, and to each wheel independently, to keep the AI well behaved. Then you have other behaviours to 'unstuck' AIs. Like reversing away from walls, traffic, avoidance, ect... Note that driver aids can sometimes be more of a hindrance (by implicitly increasing the turning circle, for example).
  13. How can I open my game to lan?

    LAN matchmaking usually involves a broadcast socket, which is limited to a subnet. Or do direct connection to IP with a pre-determined port, if you know the DHCP-assigned IP of your phone (which should be behind the same NAT, so no public/private IP shenanigans).
  14. Typically, you serialise your data into a 'stream', writing into a binary container (a memory buffer), and you can do either bit stream (everything is compressed and indexed through bit position, e.g. adding a bool will require a single bit), or you can do it through bytes streams (everything is aligned to a byte. Adding a bool will require a whole byte). It's similar to a i/o stream if you will. Like when you do cout << position.x << position.y << position.z; Note that the stream can be either in binary form, or text form, which can be useful, for example debugging (text), or smaller size (binary). so you'd do stream << data_type << length_of_data << prop1 << prop2 << prop3. then send(stream.getByteBuffer().getData(), stream.getByteBuffer().getSize()); and do the reverse process on the receiving end. So basically, you could use the standard c# stream interface, then grab the buffer, and send that buffer as a raw packet, not worrying about endianness and that kind of stuff. Your protocol may require more thoughts, but that's the general idea. For starters, I also wouldn't worry about optimum packing efficiency, endianness, ect... Just keep it simple. If you really want something flexible, use a serialisation / marshalling library. But writing your own custom, 'flexible' protocol will take a long time (it's one of those 'reinvinting the wheel' type of dilema). And using an external library usually requires a lot of setup time. But you can whip up something simple (like the stream example above), that can be very quick to do.
  15. If you're data is that small and uncomplicated, I don't really see the benefit of JSON or some other complex custom protocol. Secondly, 16 kb/s is tiny. The target bandwidth for XONE TCR is I believe, 256Kb/s or there about (used to be 64Kb/s on the old 360). Thirdly, don't forget to take into account the packet overhead, which is quite chunky around (48 bytes for UDP/IP) if you do fast updates, or P2P (sending to multiple targets). The MTU (maximum transmission unit, or basically, how big your packets can be before being fragmented or dropped) is typically 1420 bytes. 1KB packet target is fine. And finally, you can compress (quantize) your vectors to optimise bandwidth usage, but that's only worth considering if it is actually a problem. This is from a C/C++ perspective, I'm not sure what C# can do to help you with serialisation / reflection and all that kind of jazz.