• 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

169 Neutral

About Waverider

  • Rank
  1. So I missed one small detail. I said it was a rookie mistake. From the NAT punch-through doc (which I did read, as I stated earlier): "The server may repond from the same port that the client sent to (such as in this situation) or it may repond from some other port. Thus, most useful, working NAT boxes must not keep a table of where the inboun packets are supposed to be coming from; it is sufficient and necessary to only keep track of the local masqueraded addreses." According to this, it SHOULD have worked. But apparently, I was dealing with fickle routers. Change text to "Thus, most useful, working NAT boxes keep a table of where the inboun packets are supposed to be coming from; it is necessary to preserve the destination port on the return message." Trusting that doc wasn't going to help me. Unless you'd like to point me towards something more specific. In the next section I do see the small blurb where the destination port is preserved (which is derived from reading it and understanding it entirely... that part isn't expressly stated) on the return message to keep the "server from being surprised", but you know, there are clearer ways to explain things when it could really have been ANYTHING I was doing wrong. This is a learning site, after all. [Edited by - Waverider on September 30, 2008 12:19:51 AM]
  2. SUCCESS! I made a rookie mistake. It wasn't my router. Actually my router was working as a client because it's older. Today's routers apparently have two-way validation, meaning they keep track not only of where local packets came from, but also where they are going. And the only packets they will allow back are the ones addressed from the same IP:port that the client sent the first UDP packet to! I was sending host responses through a separate socket that I allocated to each client that connected instead of the port-bound socket I was listening on! That means the port number didn't match the router's record, so the client's router blocked it! *Falls down* I recompiled it to send everything out through the host's bound listening packet and everything works! I discovered this by downloading some UDP Chat C# code that worked. The only difference from my code was that the host sent responses out through the listening socket! Whew, glad that's over. I'm off and running now... Thanks for the help! [Edited by - Waverider on September 29, 2008 8:29:31 AM]
  3. I tried to get port forwarding set up, but for some reason my router continues to reset to its current values. Frustrating. I'll keep fiddling with it. If I discover anything, I'll be sure to report back here. If it's solved with programming I'll definitely be writing an article.
  4. I took a look at WireShark. I'm assuming to get it to work I would have to install it on my sending machine behind my router, and have it installed on another machine just outside my router but before my cable modem? From a programmatic standpoint, the problem just doesn't make any sense. All I use for communication is recvfrom() and sendto() with address parameters. That's it. Any concept of "connection" is only how each program just holds on to the address info for each send, and how routers open that temporary tunnel for "solicited UDP". Why would it work on my router when it's closed and I'm a client, but not when it's open and I'm hosting? Wouldn't I notice other difficulties on my machine, like DNS lookups failing or something?
  5. On the plus side, I allowed my tester across the net to host (which always worked) and ran 3 instances of the app on one of my machines and 3 more on my laptop, both machines on my LAN. All 6 processes received their respective messages. So my router is NATing quite well. Looking more at the NAT articles, I'm still not seeing how they apply to me. I usually recommend that someone open up a port through their router if they want to host anything at all. NAT Punch Through seems to be only for machines that can't establish a connection either way. With my app, once one machine receives a UDP packet successfully (which always happens through the opened port), it attempts to reply to the client with the address and port in the sent packet (which works when he hosts, but not when I do).
  6. I've read up on NAT, I'm just not sure it applies to me. If the client's router is using NAT, then the UDP packets I receive from him should have an IP:port for me to reply to, which I do. The client's router, using its NAT that it filled in when that client sent his first UDP packet out, should route my response back to the correct machine. It works great when I'm a client. I even connected up with two machines from my LAN, and the host out on the internet sent the corresponding packets back to each of my machines correctly. To further investigate, we both enabled logging on our routers and looked at the IP:port's being sent and received. When I was hosting, I received and sent packets just fine to their expected destination. On the client's side, he saw that he was sending packets to me, but he had no log of the packets I sent to him. Further testing this, I blocked everything on my router and continued. His chat messages no longer showed up, but my router log still recorded his packets, even though they were blocked. This is really a mystery. This almost, ALMOST suggests that my outgoing UDP packets as a host are being blocked at my own router. But that doesn't make any sense, because as a client, I can connect to him, which shouldn't be possible if my router is blocking my outgoing packets. I'll continue reading up on NAT for more clues. At this point, I don't think the clients that have connected with me (3 so far, none can see my packets) are ALL using more than one router in their networks. It would seem to me the NAT vulnerabilities shouldn't be this prominent.
  7. Quote:Original post by Captain Griffen There is no real way around this apart from for the host to have the router configured to allow it, I think. If there was, then I suspect that commercial games would use it - as it is, pretty much every game requires a correctly set up router in order to be able to host behind it. Hosting isn't the problem. The problem is getting the client router to accept a response UDP packet via "solicited UDP". It works when I'm a client, but not when someone else is, so far.
  8. I just tried hosting with someone else... same problem. Curses.
  9. I just tried it again with my router NOT DMZ'd with him hosting, and it worked. So something about his setup prevents my host from sending a packet to him, but my router allows solicited UDP just fine. How is he browsing? (DNS requests are UDP, that's how I found out about "solicited" in the first place). Oh well, at least I learned something! Thanks!
  10. After our little troubles, he opened up the port it hosts on and we reversed roles. I DMZ'd my machine so that I would be sure to receive the responses. That part worked fine. By the way, UDP packets above 1k size fragment often enough to not bother with... :P
  11. UDP is connectionless, so I'm just replying using a reserved socket (not one directly generated from the client connecting as TCP would, just one I allocated space for) and the address info sent on the login request. It works locally and on my LAN, so I was assuming it would work on the internet as well. However, I could see where a router with its DMZ set to a different machine would route the packet incorrectly. Routers might do some things automatically, but I don't expect they would be able to predict where a UDP packet is REALLY meant to go... Frustrating. Maybe I should just try the app with someone else. Perhaps that first user's setup is just being difficult.
  12. Quote:Original post by Evil Steve The problem is that you need to be able to get through on one side before you can send a reply. Thanks for the link, I'll take a look at it. In response to this comment, I didn't make it clear that I did in fact see login information and chat messages from the client, he just wasn't getting them back from me. Will NAT punch-through still help?
  13. Greetings, all. I've been fiddling with Winsock 2.2 programming with some success. I've written an app that uses TCP, and it functions rather well. Recently, however, I've attempted some UDP programming. In order to get an idea what kinds of troubles I'll have to deal with over the internet, I wrote a small chat program that also sends packets to the other machine to perform an analysis on packet loss and overall data rate. It entirely uses UDP, which of course, presents its own difficulties... The one I want to ask about here is the concept of "solicited UDP". Apparently, some routers that otherwise block UDP packets will recognize an outgoing UDP packet and will temporarily allow a response through the sending packet's port. This allows the host side to send a response back and allow the sending machine to receive it. However, in my initial testing, the client's machine was failing to receive my packets at all (I was serving as the host). The client connects by first sending a UDP packet with username information. Then, when the client types in a chat message, that request is sent to the host which then sends the chat message back to the client to be echoed on their screen. The client wasn't seeing those messages, so this apparently wasn't working. I've tested it on my LAN, and my local machine, and it works fine. * My primary question is: Is there a way in Winsock to flag a sent UDP packet as "solicited", or is this entirely an automatic router function? Any links to articles or mention of Winsock functions and flags to set would be appreciated. I've been combing through MSDN and various other google attempts to no avail. Thanks for any insight! [Edited by - Waverider on September 28, 2008 9:33:32 PM]
  14. Alpha objects are usually drawn last from back to front. That way they don't occlude each other, don't interfere with everything else, and properly blend on top of anything already rendered. To make a glowing effect, you'll probably have to go with a specialized texture that has a bright center and fades a lot at the edges. That way, when you render a lot of them layered against each other, you'l get an intense center with a glow effect around them. It's likely that the example you posted involves more than just the same texture layered with multiple particles, though. You may need special flare textures that you can render last. [Edited by - Waverider on September 5, 2007 10:16:06 AM]
  15. You could try integrating the win32 commands into your source, like this: Declare Function GetCursorPos Lib "user32.dll" (lpPoint As POINTAPI) As Long Declare Function SetCursorPos Lib "user32" _ (ByVal x As Long, ByVal y As Long) As Long ... and just use those as you see fit. I know this works for VB6, haven't done it with VB 2005.