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.

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.

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

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?

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.


(4 replies, posted in Thanks)

nano wrote:

Ok. I'll work on the German Wiki.

Don't translate it to Franconian though... Or else I will make an Upper Palatinate version ;-)

BTW: Thanks to the TF team. :-)

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.

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 :)


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.