Hello.I'm making a simple football game for 2 players over internet. Can you point me to some good network tutorial? Dosen't have to be pro or something, just enough to do it right (and when I say right, I mean in that way as you would do it for a game, not some technuiqe that is simple but nobody really uses it so I can forget about it after I'm done).Thanks.

I think it is by far the easiest to use since there's almost no learning curve to using it at all. There are other APIs by people on this board as well that you can find by searching if you want some more variety.

if I were to use this I wouldn't learn anything myself... and, well, that's the main point behind all thisPlus I think every game should have it's own network traffic control optimized for it, since generic solutions can't be best for all games right? Thank you anyway.

I don't think there are any tutorials at the level you asking for (at least not for java). If you're intending to make the game real time transmitting all the players all the time, I'd suggest implementing something similar to the Quake3 networking system using the standard Java APIs for networking.

However, if you haven't used the standard Java APIs at all I'd suggest looking at the standard Java trails for a starter at least: http://java.sun.com/docs/books/tutorial/networking/ and then you could use the JGN source mentioned in the previous post as examples of how to do stuff.

Finally, you might want to sit back and think about how the networking should work for a soccer game. I guess its quite a difficult problem if you want to keep synchronisation perfect. However, you could design your game based on accepting non-perfect syncing between players.

Kev

PS. It might be worth dropping a post in the Networking area. I'm sure there are a few (Herk, BlahBlahBlah, Jeff) who would also give you advice here.

I would disagree that a generic API can not be optimized as much as a custom solution. In fact, I would say it's more likely that a generic solution would provide more optimization since it's not a solution built for one case, but a solution designed to be useful in any situation with various features and bug testing. Whether you decide to use JGN or not is your choice, but I believe your premise is flawed. I hold nothing against the idea of wanting to learn this for yourself though, it's great to understand the principles even if you are using an API that simplifies the process.

BTW, I'm developing a soccer game myself (a little bit different from a normal soccer game, but the concept is still the same) and I'm using JGN with my PhysicsNetworking API wrapped around that.

You would need to have some sort of dead-reckoning implementation to do this well I should think.

@KevThanks, I'll read official Java tutorial I guess. About me thinking how should be done, well that's basicly the thing I wanted to learn properly, didn't ever do networking game (or any more serius game then dos-like console game) so I don't know what exactly are problems with networking or where to start. I was hoping there was a book or something that covers exactly that.

@sunsettI belive your JGN is very good, but how can it be best solution for every game? Surely networking for FPS, MMORPG, strategic games and others is different. I'm not going much into this since I don't have a clue about networking in games but still if you think my premise is wrong tell me why this is wrong. Your explanation how it's better since is not built for one case dosen't make sense to me from reasons I told above.

You would need to have some sort of dead-reckoning implementation to do this well I should think.

..sorry, don't know what dead-reckoning means

@JeffSocekts? OK, as long sockets are used for all networking... What I'm really trying to avoid is spending weeks / months learning something that would be no use later... like when I started with game programming, got a book Java Game Programming and learned and learned... about using threads for animation, active rendering and loading images, making start menues in swing... and then I came here and found out that using threads, swing or more listeners is one of most stupidest things you can do for a non-turn based game. I feel like I lost a year of my life. There's also a networking part in there... but guess what

What I'm really trying to avoid is spending weeks / months learning something that would be no use later... like when I started with game programming, got a book Java Game Programming and learned and learned... about using threads for animation, active rendering and loading images, making start menues in swing... and then I came here and found out that using threads, swing or more listeners is one of most stupidest things you can do for a non-turn based game. I feel like I lost a year of my life. There's also a networking part in there... but guess what

Ultimately the fundamentals are the important thing. APIs (Swing, Java2D, OpenGL) are a means to an end. You can carry the fundamentals across any API that comes around and, in fact, need to be able to. The same thing applies to networking. Common architectures and algorithms can be adapted to almost any networking API, be it java.nio or Berkeley Sockets. So when you are learning this stuff, you need to make sure you aren't just learning API calls. That will get you no where fast.

Definitely there are distinctions for each type of game implementation, but that doesn't mean an higher level API makes it any less efficient. For example, you aren't writing games in ASM are you? :-p C/C++ are higher level languages abstracting the fundamental instruction sets that directly compile to machine code. Even higher level is Java which compiles to byte-code and then has a VM that interprets that bytecode dynamically. In some ways you can definitely do more efficient calls with ASM than you ever could with Java. However, as someone that has done more than his share with assembly I'll just say that going so low level you'll often get so bogged down with just getting the code in there that after all is said and done it's less efficient than higher level languages because they've been tweaked over time to get the best performance in the majority of scenarios.

Sure, if you're doing direct TCP/UDP packet sending there is a definite potential to have a faster, more streamlined networking aspect to your game, but I would venture that rarely would you spend the time to add features like packet compression, time synchronization, packet encryption, null value handling, etc. Further, your code is typically far more complicated to maintain if you're trying to manage the networking code inline as well. I would say the majority of game writers on this forum have written their own networking implementation, but my goal in writing JGN was to put that to an end. I would much rather have an API that has all the features I could need in an easy to use API so I don't have to re-design the networking wheel for every game I develop and can spend the majority of my time developing games.

My networking API is designed to be a very short learning curve as it is all about basic beans....if you know Java, you know the fundamentals of my API.

Finally, I guess you could say a choice to use something like JGN is the same type of decision you have to make whether to use jME, Xith, or Java3D above going directly OpenGL and using LWJGL or JOGL. Sure, you can gain some advantages using straight LWJGL above jME, but jME has shadow support, Swing integration, cloth, BSP, model loading, and MANY other features that it would take years to write those features into my own game. That's my purpose behind JGN is to provide that level of features in networking and be able to re-use them in any scenario.

@sunsettvery good explained, but I think your parallel to ASM isn't very adequate. ASM took huge amount of time to have 30% faster (?) program, but since computers really speed up we sacrificed that. Situation with network today is different, network is still bottleneck of good, syncronized gameplay. Look at most popular game, WoW, ... I surely can say it isn't written in ASM and that their network system is optimized as it can be, Blizzard surely wouldn't go with anything else.To conclude, I'll use or at least try JGN, but first I think I'm compeled to write some of my own networking to understand it.

hehe, I can definitely appreciate that. I would recommend doing some examples on TCP and UDP. TCP is by far easier, but UDP offers the advantage of "fire-and-forget" where you don't care if it ever reaches its destination. Most fast-paced games are done with UDP (although some are not) in addition to TCP for guaranteed delivery of necessary messages. JGN is pretty stream-lined. It's taken an awful lot of coding to make it easy to use but powerful at the same time, but that's my concern, not yours. :-p

I'm sure Blizzard probably designed their own networking API that they use for the majority of the networked games they develop. Most games have just a couple types of messages they send: Messages that need to get there immediately or be discarded and messages that MUST arrive no matter how late they might be. In most cases the networking aspects are usually not that varied from game to game. In cases that they are JGN is highly customizable.

I would recommend going through the examples for NIO on the JavaDocs as NIO is really what you'll want for game development.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org