• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

103 Neutral

About Rells

  • Rank
  1. Same goes for knowing the player ID of another player I would think. However, what you say is worth some thought. It would require doing a mapping from source ip/port (which is 6 bytes in ipv4) to the player stream handler. Certainly doable. And since the port is likely to change with each client creation of the source socket, it might work. Would have to make sure the client creates a single datagram handling outgoing socket and uses that rather than comming from a dozen ports. Interesting idea.   Its still spoofable of course, everything non-encrypted is. And whether I can stack on encryption depends on a ton of other issues.
  2. Why do you think that the hash table that the OS is using to distribute different port traffic to different sockets would be any more efficient than your own hash table? Why do you think that the number of ports would change how much buffering space is in the kernel, or how much capacity your network card have? There's only one network card, right? And if you had 10 socekts with 1 MB of buffer space each, why couldn't you have 1 socket with 10 MB of buffer space just as well? It *may* be that those questions actually have answers that say you should use multiple sockets, but I would bet against it. Start with the simple solution. Complexificate things only when you *know* that you need to. There are many servers today that do hundreds of thousands of packets per second over a single socket with a single thread. (Although most of them I know of are using libevent and C/C++ rather than Java -- I don't know how much overhead Java adds.) Also, are you trusting a player ID provided in a packet? If so, players may cheat. The best identification of players is by source IP+port, which you get when you call recvfrom() or similar functions.   I am not saying multiple sockets is the way to go. I was asking for opinions. It seems the tone of your reply is blasting me for that.   As for the final deployment, I will probably use a data center managed by a third party rather than do my own network configuration and in that situation I would assume there would be more than one network card on the rack.   As for the overhead Java adds, I dont know if its incredibly relevant. If the clock cycles that the compiled code adds is the highest worry of the app, I will have both a very powerful system and a very big smile on my face. I think the IO rates across the net will introduce far more overhead. And I am using Java because I can take advantage of some tools rather than reinventing the wheel. I can also precompile the byte code to native (rather than using JIT) if the need arises.   As for the player ID, I will point out that its not that hard to spoof a header in an IP package and make a packet seem like it is comming from anther source. If you can alter the player ID in the live stream, you can alter the IP & port. The question then becomes one of potentially using encryption of the data stream. Is there an encryption tech out there that is sufficiently fast as to not introduce unmanageble overhead but yet provide good enough protection of the stream? I believe there are some alternatives to choose from. But really that is a worry I will tackle later. A journey must be walked a step at a time, not leaped to the end.
  3. Oh I am aware of the other issues. :) But one issue at a time. Thanks for the feedback.
  4. Greetings, this is my first post here so excuse me if I ask or say something stupid. :)   I am working on a multiplayer game and I am putting together a prototype implementation of the back end. I will be using UDP to provide support for the realtime aspects of the player interraction and I am having something of an internal dilemma. There are two different ways I could implement the realtime aspects and I am having trouble deciding between the two and would appreciate some opinions especially from those with experience.   Option 1: I can have a single server listener on a particular socket that recieves UDP messages and then has a HashMap of actual destinations inside the server. As a message comes in, it gets routed to the correct processor for that player using the encoded player id to identify the correct destination. The pros to this is that the implementation is relatively straightforward on the server side. My concerns is that the single port will become innundated with tens of thousands of packets per second and cause a bottleneck in processing. Also the routing algorithm itself, while very fast even in Java, will introduce some overhead as well. The overhead with the HashMap implementation should be O(1) but should not be entirely dismissed.   Option 2: I can create a complex system whereby the client sends udp messages to a particular port provided by the server and there is a server directly listening to that port. This would have the benefit of allowing the underlying IP protocol to do the routing and that would possibly be faster than the hash map implementation. Each player would have one of X number of dedicated ports to send UDP messages to and no post recieve routing would have to take place.   Option 3: Go for a hybrid system where there are many possible open ports and each open port will handle n clients.   Common: In either case the server will send data to the client on a single UDP port that the client has opened through the firewall (though I havent investigated how well this works with console systems). Since there would be no need of routing on the client side this should be efficient. Also there is a possibility, due to load balancing, that i might have to redirect the clients to connect to other servers in the cluster. That can be done with a UDP message changing the destination for client messages.   Other Concerns: I have already discounted TCP as being inappropriate for this application since strong realtime concurrency is required and old packets are irrelevant.   However, I would also like to find some way to encrypt the data stream between the client and server, possibly using Fast AES in a manner similar to the HTTPS handshake protocol. This would introduce decrypt overhead and put more pressure on the CPU resources of the single router.   Any opinions on the preferred strategy (especially if you have actual experience with the downfalls and benefits of implementing the strategies) would be appreciated.