Online "3d" chat (networking)

[Vsk]

Hi, I have some doubt that I'd like to ask you.

1)First, what tutorials do you recommend for hello world net gamming?
I've never touch this subject,alghtoug I've "done" some low level networking task. But I rather alwasy preffer high level (if this is possible for games dev , ofcourse).

2)What protocols ares used for newtwork games?

3)Do you know the chat "habbo"?, In case you do, how many time do you think need it to achieve some reduce demo version of that kind of "game". Having 3 developers, and art bougth it. ? Its 8 month enough?

4) Is irrlicht a good choice for that kind of game? or is better flash? or silverlight? or other one? (speaking always of data transfer, I would like to people with suckin internet conection can play it (700 kb) or at least some dinamic option to these persons..

5) What servers from cheap to expensive from low to heigh cocurrent players support do you recommend?

6)Any advice that it be not "you are crazy you need million budget!!!" .

Thanks

[CuteAlien]

1.) I would say working with low-level (sockets) is fine for most games. Writing the transport layer is a little work, but not much more than learning to use a new library. So the hello world is probably writing a client-server which sends a few textmessages around. Any tutorial about socket programming will help you to do that.

2.) tcp and udp. Unless you have a good reason you should avoid udp and use tcp. The reason for udp is usually either that you need streaming or that you can afford to ignore some messages. At least for the chat-part you will prefer tcp. On top of that you will use a custom protocol which depends on your game.

3.) Don't know it. Ask your developers. Tell them what features make up your reduced demo and ask them for a detailed timeplan. Multiply that timeplan by 2 and add 10% on top of it. Add some more time for every additional developer.

4.) Don't know the game.

5.) Don't use too cheap servers and unless you are as broke as me do avoid vservers. Calculate the expected traffic in advance - you should at least be able to do a rough calculation (per user) for a chat.

6. ) More important than the protocol is your network architecture. Do you only need to offer a connection service and the chats will talk peer-to-peer afterwards or will all messages go through a central server. Will you offer some ways to save messages to people who are offline. Will you display "is available" informations. That stuff will influence what sort of server you will need.

And no - you are not crazy and will need millions to write a chat. You are just crazy because there are already a million chats out there ;-)

[Vsk]

1.) I would say working with low-level (sockets) is fine for most games. Writing the transport layer is a little work, but not much more than learning to use a new library. So the hello world is probably writing a client-server which sends a few textmessages around. Any tutorial about socket programming will help you to do that.

2.) tcp and udp. Unless you have a good reason you should avoid udp and use tcp. The reason for udp is usually either that you need streaming or that you can afford to ignore some messages. At least for the chat-part you will prefer tcp. On top of that you will use a custom protocol which depends on your game.

3.) Don't know it. Ask your developers. Tell them what features make up your reduced demo and ask them for a detailed timeplan. Multiply that timeplan by 2 and add 10% on top of it. Add some more time for every additional developer.

4.) Don't know the game.

5.) Don't use too cheap servers and unless you are as broke as me do avoid vservers. Calculate the expected traffic in advance - you should at least be able to do a rough calculation (per user) for a chat.

6. ) More important than the protocol is your network architecture. Do you only need to offer a connection service and the chats will talk peer-to-peer afterwards or will all messages go through a central server. Will you offer some ways to save messages to people who are offline. Will you display "is available" informations. That stuff will influence what sort of server you will need.

And no - you are not crazy and will need millions to write a chat. You are just crazy because there are already a million chats out there

Thanks.
I've work with socket (thats the low leve that I've done), allthog the part that realy seem more difficult for me and my friend when did this work was not the "net" part but the error using pure C (malloc, size of ). So most time thing didn't work cause some byte more some byte less that we send on the package size or similar.

I've doubt about tcp y udp and people told about upd for games, but you said to me tcp and I am now confuse .
I undertand that for the chat part it is ok, but for the rest( you must see tha "game" for undertand it) the reste is just a game so (should I use some mixing or sometin like that?)

About the crazy part , no, is not a normal chat, is like a game that the principal use is chat (no, is not a "small massive game" :d) is very different and very lucrative ).

Thanks agin, if someone know the rest of the question will greatfull.

[Dorth]

Let's give a visual for udp vs tcp so everyone is on the same page:
What UDP is: a plain blanket. It covers your feet, it keep your heat inside, as long as you don't kick it in your sleep.

What's TCP: a winter, fireproofed, auto-adjusting and repositiong blanket with integrity check.

Most of the time, you'd be more than happy with a blanket if only it'd stay on you. Well that's it. That's why a lot of people use "upgraded udp", emulating tcp features, but only small parts of it. Because, contrarely to a stock application, when everything is going down in flames in a game, it's usually not so important that packets start to have problems because there's no garantee they are sane anymore anyway.

On the other hand, if you DON'T need that extra speed, if there will not be many people and thus you will not risk bottlenecking on a few, you might just be as well to stick with tcp, since the whole stuff is already built-in.

Now, the library vs protocol. I'm far from agreeing that it's as easy to learn one as the other. You see, a well designed library abstract nearly everything from the user, possibly leaving one line command to send and receive and minimal setup and cleanup. On top of that, if cross platform is something you're looking to support, you'll have to deal with the ENDIANs brothers (yeah, clever joke ) and just that is reason enough to prefer the ease of use of a library to do it for you...

[CuteAlien]

About that library - sure Dorth is right and a nice library will abstract that all away. But on the other hand every simple sockets tutorial (here the first I found on google and which explains the stuff rather well: http://beej.us/guide/bgnet/output/html/ ... index.html ) will tell you how to do that anyway, so avoiding the endian issues and knowing how to send&receive a package and doing the initializing can be learned in a day. Sockets are already abstracting the hard parts imho and everything that makes it even easier does usually take away some of your flexibility.

Still, if you prefer to add another layer just use a lib. Until you find one that's working for you (including a nice license) a good coder would probably have done it by hand, but well - whatever you like ;-)

Using UDP instead of TCP is usually done for speed reasons. Some games need that. The basic difference is that TCP guarantees that all messages can be received in order (or are timed-out), while UDP doesn't do that (it simply does not care if some packages get dropped on the way - you receive those that got through and they can arrive in any order). You can write a protocol on top of UDP to guarantee that yourself and still be a little faster than TCP. It's therefore often chosen in action games which either do that, or which simply don't care about dropped packages, as it allows to reduce the lag.

[bitplane]

You probably want to use raknet for network, it's cheap enough and very mature. TCP does what it's name implies, controls transport. TCP packets are routable, ordered and have some protection against corruption and packet loss. UDP does none of that so it has less network overhead but a hell of a lot more programmer overhead.
The reasons for using Irrlicht are similar to the reasons for using a network library, if you're trying to make a scene with actors in it then you don't want to deal with polygons and transformations if you can deal with scene nodes. If you want to send information between machines then it makes more sense to deal with connections and bitstreams than datagrams. TCP sockets make more sense, and with a network library you can abstract it even further, get the best out of both worlds and offload the work to someone that really cares about network performance.
If your goal is to create an end product, then use as many layers as abstraction as is possible to achieve your goals. If you're in it for the learning experience, then hard code it all in ASM!

[rogerborg]

1)First, what tutorials do you recommend for hello world net gamming?

I can only recommend the way that I learned: by hacking the sith out of an existing open source networked game. That's possibly not the best way to learn, but following Hello World tutorials won't teach you zip about actual network architecture or implementation tricks.

2)What protocols ares used for newtwork games?

Depends on the type of game. For any kind of twitch game, you'd rather staple your genitals to a badger than use TCP, but for a habbo clone, TCP may be fine. It's far easier to use raw TCP sockets than UDP ones, but a network library will abstract those differences away.

Something to note is that all extant network libraries that I know of (extant excludes the deprecated DirectPlay) use UDP exclusively, so if you go with a library, the decision is taken care of for you. I'll put in another word for Raknet.

3)Do you know the chat "habbo"?, In case you do, how many time do you think need it to achieve some reduce demo version of that kind of "game". Having 3 developers, and art bougth it. ? Its 8 month enough?

Insufficient data to draw a meaningful conclusion. In 8 months, you'll have whatever you've achieved in 8 months, no more and no less. All you can do is to define everything that you require, and only what you require, and to prioritise the work to give yourself the best chance of dropping the unimportant stuff and having a coherent application in your hands when you hit your deadline. That's project management in a nutshell, so now you can skip reading half a dozen useless books on the subject.

4) Is irrlicht a good choice for that kind of game? or is better flash? or silverlight? or other one? (speaking always of data transfer, I would like to people with suckin internet conection can play it (700 kb) or at least some dinamic option to these persons..

You seem to be talking about two completely unconnected issues. Irrlicht has no bearing at all on the bandwidth requirements. Two split it into two issues:

1) Yes, Irrlicht is suitable, but if you're really doing a 2D isometric game then it may be overkill. You could do it with SDL.

2) If you're doing a "hangout for teens" then it'll mostly be populated with 50 year old paedophiles who can afford fat pipes.

5) What servers from cheap to expensive from low to heigh cocurrent players support do you recommend?

Insufficient data to draw a meaningful conclusion. Do your requirements and design first, then you'll know.

6)Any advice that it be not "you are crazy you need million budget!!!" .

Requirements, analysis, design, test plan, then implement.

[Vsk]

well actualy, I have much to thgouth right. But I only needed superfcial thoguth about it (just like the ones I have now). (I hoped that kind of answer from you roderborg;) you choosed a good avatar ).

A little more information:

Demo version must have:

-Complete chat.
-Some basic interation with the "world". this is, open doors, chat some bots (what a nerd ), buy some stuff from a sell shop. Just that.

The game must be FULL WEB. No real game must be installed in client but maybe plugins that would be need.

-Must handle no more than 100 simultaneons players).

-People with sucking connection (like mine) 700 kbs must play it almost iwthout a problem.

Budget for networking service could be about NO MORE than 200 a month.(I don't know if such think that suppor that cuantity of player exists for this price ).

I realy don't know about what "consumes" more transfer data, thats why I ask to you tha know more about it.
Habbo is made in flash for some reason (maybe dogmatic, maybe well thought), that why I ask if a irrlicht would be good.

Well what do you think. (I know is little information, roderborg, I expect much the same of information from you all ).

Thanks.

[Dorth]

if you don't want anything downloaded, forget raknet and irrlicht
full web means full web. Whichever portal you'll use will already have it's tools.

[rogerborg]

The game must be FULL WEB. No real game must be installed in client but maybe plugins that would be need.

Then I can't even begin to imagine why you are considering Irrlicht as a viable renderer.

Flash, Java, or Shockwave would be far better suited for your purposes than any C based application. All of them will provide a full solution, including networking built in.

-People with sucking connection (like mine) 700 kbs must play it almost iwthout a problem.

700 kbs isn't sucky. People could and did and still do play MUDs and even MMOs using 55.6kbs dialup.

700kbs = 89.6 kBs and if only 1/4 of that is text chat, that's 22,400 characters of text per second that you could send to each client. Do you think that might be enough?

You know, I'm beginning to suspect that this is some sort of elaborate troll.

[dlangdev]

-Must handle no more than 100 simultaneons players).

if you want this feature really bad, you will have to drop raknet and simply use http rest instead. your number will go up to close to a thousand though it is only based on my cheapskate estimate. real-world million dollar backed projects can deliver numbers higher than that.

i'm testing soap at the moment, looks pretty good so far.

[CuteAlien]

There have been some experiments with running Jirr from within a browser (http://irrlicht.sourceforge.net/phpBB2/ ... e4841e4f36) and I think it's a planned feature for Jirr, but for now Irrlicht is probably the wrong tool for running games from within a webbrowser. I suppose I would try to do that with Java, but I never did webgames, so better don't take my word for it.

[rogerborg]

-Must handle no more than 100 simultaneons players).

if you want this feature really bad, you will have to drop raknet and simply use http rest instead. your number will go up to close to a thousand

I must be misunderstanding, because it looks like you're saying that "http rest" (whatever that is) scales better than Raknet-abstracted UDP. I can't think why that would be the case. Can you explain how you came to this conclusion, and based on what evidence?

i'm testing soap at the moment, looks pretty good so far.

SOAP would work for a browser based client, but I still think it's massive overkill for a game (where you control both the client and server), and I don't understand why you'd choose to use it rather than designing your own (minimal, efficient) schema and sending it via raw TCP streams rather than arsing around with XML parsing. Can you explain the pragmatic benefits of using SOAP over a custom schema?

[Dorth]

Dude! rogerborg... I've got to build you a shrine or something... well, I guess I'm left with silently approving (except this blurb) what he said

[dlangdev]

-Must handle no more than 100 simultaneons players).

if you want this feature really bad, you will have to drop raknet and simply use http rest instead. your number will go up to close to a thousand

I must be misunderstanding, because it looks like you're saying that "http rest" (whatever that is) scales better than Raknet-abstracted UDP. I can't think why that would be the case. Can you explain how you came to this conclusion, and based on what evidence?

i'm testing soap at the moment, looks pretty good so far.

SOAP would work for a browser based client, but I still think it's massive overkill for a game (where you control both the client and server), and I don't understand why you'd choose to use it rather than designing your own (minimal, efficient) schema and sending it via raw TCP streams rather than arsing around with XML parsing. Can you explain the pragmatic benefits of using SOAP over a custom schema?

technical merits between the two can be itemized, though i've already decided to take the responsibility of building and testing what i've mentioned above, so i can't argue the finer points until i have the numbers.

the interesting part is testing the threading model. i'll be able to gather data and produce a chart, it could look like a bell curve or maybe...

y = (x * N) - (x^2)