Archived

This topic is now archived and is closed to further replies.

New Level Of Online Gaming (C# Idea)

This topic is 5381 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I haven''t experimented with C# all that much yet but from what I''ve heard/read, you can run a have clients run programs FROM a server, have the server perform calculations, and have the clients SEE the results. Correct me if I''m wrong, but does this mean that game companies could have clients simply connect to the server without downloading all game content? It would be just like playing a normal game, but the player''s wouldn''t have to download the whole game. This would also greatly cut down on development time. Only server code would have to be created as opposed to server and client code. Distribution would also be easy. Oh my gosh, and you could have TOP graphics no matter how slow the computer is that your on, because all calculations are done on the server. Just as long as you had a fast connection to the server! Ok, I''m getting way too excited now.......... Tell me gaming companies are cluing into this. _____________________________ - Rob Loach Current Project(s): Upgrade to .NET and learn DX 9

Share this post


Link to post
Share on other sites
this is what online games do now... but the graphics, sounds, etc still need to be on the client end, because it would take FAR too much bandwidth and time to upload each frame to each client.

Share this post


Link to post
Share on other sites
Rob Loach to give you an idea of how much bandwidth krez is talking about, suppose a game is running at 16-bit colour, 800x600 resolution, 30 frames per second. That's 2*800*600 = 960 kilobytes per frame, multiplied by 30 frames/sec = ~28.8 megabytes/sec. Most internet connections support only a few hundred kilobytes/second, even a typical lan is 100 mb/sec under ideal conditions (in reality you're not going to get close to that on average). And that's just graphics, you also need to transmit the sound data alongside it.

Oh, and there's nothing special about C# that allows you to do that. Any language can support client/server architectures.

Edit: Just so there's no confusion, a typical lan is 100 megaBITS/sec not bytes, which is 12.5 megatbytes/sec.

[edited by - Dobbs on March 24, 2003 4:50:58 PM]

Share this post


Link to post
Share on other sites
"I haven''t experimented with C# all that much yet but from what I''ve heard/read, you can run a have clients run programs FROM a server, have the server perform calculations, and have the clients SEE the results."

C# is a standart language much like C++.
I guess you´re talking about .Net?

Hmm, that is distributed computing. Try to search google for web services, COM/COM+, Corba.

Distributed computing in .Net is accomplished with XML.

Share this post


Link to post
Share on other sites
quote:
Original post by nectarine
Distributed computing in .Net is accomplished with XML.

Not necessarily. If you want performance, you use a binary formatter and TcpChannel.



"If there is a God, he is a malign thug."
-- Mark Twain

Share this post


Link to post
Share on other sites
Even before RPC techniques, this was always the basic idea when you are implementing a protocol for a client/server system; RPC just adds another layer of abstraction.

However letting the server do everything is not that sensible, like it was mentioned above, the bandwidth would be too high.

A bigger issue, is that it is not too efficient. If the server had to do everything like rendering, they would have to be super computers, while the clients are sitting at home with 2ghz pc''s and not even using their potential. It would be completly un-sensible to implement a system like this, at this point in time.

Imagine if the server supported like 200 clients, that means the server computer would have to have the power of 200 client pc''s with 200 graphics cards etc: not possible.

Share this post


Link to post
Share on other sites
quote:
Original post by Dobbs
Rob Loach to give you an idea of how much bandwidth krez is talking about, suppose a game is running at 16-bit colour, 800x600 resolution, 30 frames per second. That''s 2*800*600 = 960 kilobytes per frame, multiplied by 30 frames/sec = ~28.8 megabytes/sec. Most internet connections support only a few hundred kilobytes/second, even a typical lan is 100 mb/sec under ideal conditions (in reality you''re not going to get close to that on average). And that''s just graphics, you also need to transmit the sound data alongside it.

Oh, and there''s nothing special about C# that allows you to do that. Any language can support client/server architectures.

Edit: Just so there''s no confusion, a typical lan is 100 megaBITS/sec not bytes, which is 12.5 megatbytes/sec.

[edited by - Dobbs on March 24, 2003 4:50:58 PM]




There is of course compression... But even still that wouldn''t do much.

It was just an idea.

_____________________________

- Rob Loach
Current Project(s): Upgrade to .NET and learn DX 9

Share this post


Link to post
Share on other sites
Back to your original post - you said C# can have clients run programs from a server and the client just displays the results. That''s not entirely accurate, and it''s nothing new, programs/languages have been using client/server architectures for years. If you care, here''s a brief explanation of what it really is you''re talking about:

Companies wanted to be able to create servers that provide a service that programs on other computers can request remotely - for instance wouldn''t it be nice if you could write a program that runs on your computer and searches Google? Google provides the service on the server-side, you make the client and provide a nice interface/client program. It then made sense to come up with standard protocols and formats for transmitting requests like "Give me the first 5 search results for ''independent game development.''" The industry settled on using XML as the format and HTTP as the protocol, and dubbed the whole system ''Web Services.'' Microsoft is making a platform for providing Web Services called .NET, and is providing languages that support that platform - C# is one of them, others are VB.NET, ASP.NET, C++.NET, and possibly some I''m forgetting.

So really what you mean is "C# provides an easy way to create a client that requests and displays the results of a Web Service provided by some server."

Share this post


Link to post
Share on other sites