Topic: Anybody wants to test UDP networking code?

Hi,

I have just added networking code to my game project, would anybody like to help test it?

Info about the game here: http://projects.tuxfamily.org/group.pl?name=critters

Currently there's a few objects moving around, synchronized over the network. That seems to work good locally, now I want to test how good the UDP connection works with remote peers.

You can get the code with this command:
svn checkout svn://svn.tuxfamily.org/svnroot/critters/critters/trunk

In the 'trunk' directory, you can try this:
./test-listenserver.sh & ./test-client.sh localhost

That should give you 2 windows with identical stuff moving around... It starts a listen server and a client which connects to it via loopback.

Now if you want to help testing, you can start a listen server and let me connect to it (and vice versa). To make a server reachable from the net you have to open/NAT-forward your UDP port 9999. Then we have to exchange IP addresses. You can reach me via jabber at johannes(at)deshalbfrei.org (or here).

Thanks! :-)

PS: The binary in SVN is for Linux/32bit. To recompile for other platforms you need Code::Blocks.

Re: Anybody wants to test UDP networking code?

Works for me ;-)

Explosions with the fading out are really nice.

By the way, you are not supposed to upload binaries to a subversion repository.

Sylvain

Re: Anybody wants to test UDP networking code?

Thanks for trying it.
About the binary: I hope this is no problem? It just makes things easier. All the source code is there, so you can compile the program yourself if you prefer. But you need to install Code::Blocks for that. I would provide a Makefile but C::B can't export Makefiles yet. (And I'm too lazy to write&maintain one myself :)

Re: Anybody wants to test UDP networking code?

Hi,

jkroll wrote:

Thanks for trying it.
About the binary: I hope this is no problem? It just makes things easier.

There is, your binary is already using 832 kB of disk space, so you are uploading 832 kB of data on each commit. This is binary so just keeping the diff with the previous commit is not possible so it takes 832 kB of disk space on the subversion database for each commit. Let's think with a binary of 10 MB, which is quite common, and 1000 commits, which is quite low, 10 MB * 1000 = 10 GB. Let's think about dialup users who are going to download 10 MB of data that can be easily build, what a pain.

This is good for images, because there are not updated as often as the compiled binary, this is needed to run the software and you need to keep them in sync with the software.

However, you can provide statically-compiled binaries on release, to let people try your game without compiling it, this is not that common for apps but quite common for games. Release early, release often ;-)


All the source code is there, so you can compile the program yourself if you prefer. But you need to install Code::Blocks for that. I would provide a Makefile but C::B can't export Makefiles yet. (And I'm too lazy to write&maintain one myself :)

Well, you need to use autotools or such to expect being packaged by distros, packagers dislike softwares that don't build easily ;-)


Sylvain

Re: Anybody wants to test UDP networking code?

SVN uses a binary diffing method.

from http://subversion.tigris.org/faq.html#binary-files
Note that whether or not a file is binary does not affect the amount of repository space used to store changes to that file, nor does it affect the amount of traffic between client and server. For storage and transmission purposes, Subversion uses a diffing method that works equally well on binary and text files; this is completely unrelated to the diffing method used by the 'svn diff' command.

http://svnbook.red-bean.com/en/1.5/svn- … -and-trans


@Topic, I tested with 2 people and it seems like depending on the uplink of the server, the connection works fairly well, but it's not good enough yet. It looks like the packets sometimes reach the client out-of-order, even if ordering is enabled. I'm now working on a "display-less" version which I can run on a remote server, so I don't always have to bother people to NAT-forward the port, etc.

Re: Anybody wants to test UDP networking code?

Hi,


jkroll wrote:

SVN uses a binary diffing method.

True, but a compiled binary might change a lot, depending on how you are compiling it, optimisations, debugging, etc... which might change from one commit to another.


jkroll wrote:

@Topic, I tested with 2 people and it seems like depending on the uplink of the server, the connection works fairly well, but it's not good enough yet. It looks like the packets sometimes reach the client out-of-order, even if ordering is enabled. I'm now working on a "display-less" version which I can run on a remote server, so I don't always have to bother people to NAT-forward the port, etc.

Yes, almost every user computer are NAT-ed today, this is not relevant to ask users to forward a port to play ;-)


Sylvain

Re: Anybody wants to test UDP networking code?

True, but a compiled binary might change a lot, depending on how you are compiling it, optimisations, debugging, etc... which might change from one commit to another.

For the Debug binary I've uploaded for testing, I always use the same settings: Debugging on, optimizations off.

If you are concerned about size, you should forbid binary files altogether, especially pictures & sound. If i change a sound, e. g. add a simple echo or other effect, the diff to the last revision will be much larger than changes to a few bits of an executable. And I plan to use sounds in critters sooner or later.


Yes, almost every user computer are NAT-ed today, this is not relevant to ask users to forward a port to play ;-)

If you want to run a server, you have to forward the corresponding port. It's just like any other networked game.

Maybe I will implement UDP hole punching or Rendezvous later, which will make setting up a server much easier than with most other games.

But this thread is about testing Alpha software. As you can see, the game is not playable yet. I'm testing raw networking code. So comments about ease of use or packaging are not relevant right now. Thanks anyway for your hints.

Re: Anybody wants to test UDP networking code?

jkroll wrote:

True, but a compiled binary might change a lot, depending on how you are compiling it, optimisations, debugging, etc... which might change from one commit to another.

For the Debug binary I've uploaded for testing, I always use the same settings: Debugging on, optimizations off.

For now.


jkroll wrote:

If you are concerned about size, you should forbid binary files altogether, especially pictures & sound. If i change a sound, e. g. add a simple echo or other effect, the diff to the last revision will be much larger than changes to a few bits of an executable. And I plan to use sounds in critters sooner or later.

The problem is not about binary files, you need to keep revisions of pictures and sounds, this is not wasted space, keeping revisions of an ELF binary that can be easily built is purely wasted disk space.


jkroll wrote:

Yes, almost every user computer are NAT-ed today, this is not relevant to ask users to forward a port to play ;-)

If you want to run a server, you have to forward the corresponding port. It's just like any other networked game.

Of course yes, you misunderstood me (perhaps I wasn't clear ;-). I mean that a network game without standalone servers running on publicly available hosts have low chance to be played nowadays. As well as doing a meeting-only server.


jkroll wrote:

Maybe I will implement UDP hole punching or Rendezvous later, which will make setting up a server much easier than with most other games.

Sounds great ;-)


jkroll wrote:

But this thread is about testing Alpha software. As you can see, the game is not playable yet. I'm testing raw networking code. So comments about ease of use or packaging are not relevant right now. Thanks anyway for your hints.

;-)


Sylvain

Re: Anybody wants to test UDP networking code?

For now.

Yes. If I want to turn optimizations on and debugging off, I use the Release target. This creates a different executable which is unversioned.

Anyway, I put the binary in because it makes it easier for people who might want to help me testing the network stuff. I didn't expect this to be such a big deal.


The problem is not about binary files, you need to keep revisions of pictures and sounds, this is not wasted space, keeping revisions of an ELF binary that can be easily built is purely wasted disk space.

You have a point... Somewhat. If I have a PNG which is created from an SVG, why should I keep revisions of the PNG? So the PNG revisions would be wasted space? ;-)


Of course yes, you misunderstood me (perhaps I wasn't clear ;-). I mean that a network game without standalone servers running on publicly available hosts have low chance to be played nowadays. As well as doing a meeting-only server.

Okay, maybe I wasn't clear, either. I never said that I won't make a dedicated server later. I just checked this code in recently. It's all very new. There *is* no dedicated server, yet. I first have to get the network code to work. And for that, I need some way to test it. You see?

Re: Anybody wants to test UDP networking code?

jkroll wrote:

For now.

Yes. If I want to turn optimizations on and debugging off, I use the Release target. This creates a different executable which is unversioned.

Anyway, I put the binary in because it makes it easier for people who might want to help me testing the network stuff. I didn't expect this to be such a big deal.

Actually it depends if you wish a clean svn repository or not. But this is also looked over if you ask for more disk space, well, we never go that deep, we only blame when there is an obvious non-understanding of how subversion works, then svndumpfilter does the job ;-)

jkroll wrote:

The problem is not about binary files, you need to keep revisions of pictures and sounds, this is not wasted space, keeping revisions of an ELF binary that can be easily built is purely wasted disk space.

You have a point... Somewhat. If I have a PNG which is created from an SVG, why should I keep revisions of the PNG? So the PNG revisions would be wasted space? ;-)

Yes, same problem, you should convert svg to png at build time. (So the svg to png converter is a build dependency). For now this is not very important but it will be ;-)

jkroll wrote:

Of course yes, you misunderstood me (perhaps I wasn't clear ;-). I mean that a network game without standalone servers running on publicly available hosts have low chance to be played nowadays. As well as doing a meeting-only server.

Okay, maybe I wasn't clear, either. I never said that I won't make a dedicated server later. I just checked this code in recently. It's all very new. There *is* no dedicated server, yet. I first have to get the network code to work. And for that, I need some way to test it. You see?

Make sense. I wrote about obvious advices ;-)


Sylvain

11 (edited by jkroll 2009-02-18 14:00:55)

Re: Anybody wants to test UDP networking code?

gradator wrote:

Actually it depends if you wish a clean svn repository or not. But this is also looked over if you ask for more disk space, well, we never go that deep, we only blame when there is an obvious non-understanding of how subversion works, then svndumpfilter does the job ;-)

Fair enough.

Yes, same problem, you should convert svg to png at build time. (So the svg to png converter is a build dependency). For now this is not very important but it will be ;-)

You serious? o.O So i should find a SVG-to-PNG commandline converter and use that in the makefile?
Another program that users have to install, if they want to compile my program...
Also, the PNG output quality of inkscape is better than other converters. (e. g. gqview rastering looks worse.) Inkscape does commandline conversion, but it's huge. MUCH larger than critters... :-) I hate it when some tiny source package needs gigabytes of other stuff to compile. I guess many users do...
My PNG files are really small.

(But you gave me an idea: I can integrate inkscape into the build process so I don't have to export the SVGs by hand...)

Re: Anybody wants to test UDP networking code?

jkroll wrote:

Yes, same problem, you should convert svg to png at build time. (So the svg to png converter is a build dependency). For now this is not very important but it will be ;-)

You serious? o.O So i should find a SVG-to-PNG commandline converter and use that in the makefile?

Yes, exactly :)


jkroll wrote:

Another program that users have to install, if they want to compile my program...
Also, the PNG output quality of inkscape is better than other converters. (e. g. gqview rastering looks worse.) Inkscape does commandline conversion, but it's huge. MUCH larger than critters... :-) I hate it when some tiny source package needs gigabytes of other stuff to compile. I guess many users do...
My PNG files are really small.

There is nothing wrong about having inkscape as a build dependency ;) In hugeness this is almost the same of having a build dependency on docbook, which is very common.

Users are not supposed to compile your program, and users who are able to do that are smart enough to understand why inkscape is needed ;-)


jkroll wrote:

(But you gave me an idea: I can integrate inkscape into the build process so I don't have to export the SVGs by hand...)

;-)


Sylvain

Re: Anybody wants to test UDP networking code?

There is nothing wrong about having inkscape as a build dependency ;)

Yes, there is. Many developers get this wrong. "Why should I put the PNG into the source tree? I can just depend on inkscape and even save 2 kilobytes of disk space on the SVN server." Or: "Why should I write these 10 lines of code myself? I can just link to this 500MB-sized library instead. Users just have to install it. Disk space is cheap."

Disk space is cheap, yes, but people's time isn't. :-) And not everybody has a T1 link to the net, either. If I have to install (and maybe compile) GBs of software just to check out a tiny program, I often just skip it.

Re: Anybody wants to test UDP networking code?

Hi,

jkroll wrote:

There is nothing wrong about having inkscape as a build dependency ;)

Yes, there is. Many developers get this wrong. "Why should I put the PNG into the source tree? I can just depend on inkscape and even save 2 kilobytes of disk space on the SVN server." Or: "Why should I write these 10 lines of code myself? I can just link to this 500MB-sized library instead. Users just have to install it. Disk space is cheap."

Disk space is cheap, yes, but people's time isn't. :-)

Disk space is not cheap, this is the most expensive cost on TuxFamily, far far far away from any other cost.


jkroll wrote:

And not everybody has a T1 link to the net, either. If I have to install (and maybe compile) GBs of software just to check out a tiny program, I often just skip it.

You forgot about releases, a subversion repository is a working area and shouldn't contain redundancy (.o from .c files, .png from .svg, .jar files, .tar, configure from configure.in, Makefile from Makefile.am, ELF binary, etc...). This is why you usually have to "bootstrap" after having fetched a svn tree and not after having fetched a release. You are free to do releases with the pre-compiled .png files, you can also do releases with statically linked ELF binary for those who don't know how/want to compile, and I personally recommend doing that for games ;-)


Sylvain

Re: Anybody wants to test UDP networking code?

Okay...

Maybe you misunderstood me or something...

You're (still) talking about releases. There is nothing to release yet (no playable version of the game).

I don't put .o files into a repository.

I put PNG files there which are generated from SVG files, because else I would have to have a build dependency on Inkscape, which is a relatively large program with a lot of dependencies. I don't want that everybody who wants to compile critters (maybe developers, or users who want to compile for a platform which I can't make binaries for) has to install Inkscape. The PNG files are tiny (most are smaller than 2 kilobytes). There are just a handful of them. I think it's reasonable to put them in SVN.

Is it OK with you if I keep the PNGs in svn, as long as they stay small? I will remove the binary once the first release is there.

Re: Anybody wants to test UDP networking code?

jkroll wrote:

Okay...

Maybe you misunderstood me or something...

You're (still) talking about releases. There is nothing to release yet (no playable version of the game).

I don't put .o files into a repository.

I put PNG files there which are generated from SVG files, because else I would have to have a build dependency on Inkscape, which is a relatively large program with a lot of dependencies. I don't want that everybody who wants to compile critters (maybe developers, or users who want to compile for a platform which I can't make binaries for) has to install Inkscape. The PNG files are tiny (most are smaller than 2 kilobytes). There are just a handful of them. I think it's reasonable to put them in SVN.

You are only talking about your project while I am talking more generally :-) I always see things with a wide angle, it helps understanding.


jkroll wrote:

Is it OK with you if I keep the PNGs in svn, as long as they stay small? I will remove the binary once the first release is there.

I never said it wasn't OK ;-),  but this is redundancy and this should be avoided in svn repositories.


Sylvain