• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

oliii

Members
  • Content count

    7312
  • Joined

  • Last visited

Community Reputation

2196 Excellent

About oliii

  • Rank
    GDNet+
  1. 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. BTW, The Wicher 3 is on sale on Steam right now (at least UK), £18. Well worth the price. 
  3. I have 20,104 notches on my minigun that say you're way off the target.
  4. 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. 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. 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. 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. 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. 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. Defend Texas against hordes of mexicans! Build that wall! Man those watchtowers! Fun for entire family!   It has potential.
  11. 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. 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. 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.