Networking functionalities in v19 ?

Mar 16, 2008 at 11:27 PM
Will there be any networking layer in the v19 ?
Mar 16, 2008 at 11:50 PM
We had originally planned to have a loopback network layer in 0.19, with a System.Net implementation a version or two later. I haven't heard from the developer working on that for awhile though. I'm not sure if he's still around.

We've lost about half of our already minimalistic dev team. :(
Mar 17, 2008 at 12:54 AM
I've got a friend who has worked on a client-server networking component for the game I planned to start. I'ts using low level networking classes (System.Net) and thus not the XNA ones as they restrict to 64? players...
I looks good at the moment, I sent him a text message to ask if he wanted to join the QS project , we should hear from him soon I hope.
He might then being interested in taking over this functionality.
Mar 17, 2008 at 12:56 AM
Keep confident with the team size, the project is too good to be left over.
I might postpone my game dev and focus on this framework's development instead as it would bring so much to the XNA community !!
I'll write my game later with it :p
Mar 17, 2008 at 1:26 AM
Networking is an interesting topic we need to discuss. All of our previous discussion has been pre-GDC, meaning we did not know about the Community Games platform. Live networking was all but dismissed for this project, since Xbox distribution was non-existant and Windows Live did not have any distribution potential. Now that the Xbox Community Games platform will be coming out, we need to adjust our thinking and decide if we want to pursue that route.

I've always wanted to push the Xbox development of the project, but the lack of tools and distribution made me shy away (and as LordIkon knows, frustrated me on several occasions to the point that I wanted to drop Xbox support altogether). Now we will have the distribution channel. So while the tools are still lacking, its a worthwhile market to tap into. I've love to get a QS user base among the Community Games submissions.

But at the same time, I can't help but think we're digging ourselves into a huge hole. We want to support networking, top-of-the-line graphics, 3D physics, scalable multi-core-aware internal processing, and a fully-featured world editor. This is not an easy task, and I do fear we don't have the resources. You can be the most dedicated team in the world, but if there's just not enough people to do the work, you're not going to get much done.
Mar 17, 2008 at 1:43 AM
Shaw,

I think that in this adventure, the most important is the ideas we've got, the will we've got and our motivation.

We have no time constrains, time is not an ennemy.
We have no money constraints neither.

Keep it cool, and most of all, Believe.
We'll get this done, sooner or later.
Mar 17, 2008 at 1:47 AM
Edited Mar 17, 2008 at 1:48 AM

we're digging ourselves into a huge hole
It's not a hole, it's a dream :)

This is not an easy task
It's a fact and that is what will keep our motivation up, the challenge.
If it was too easy we would get bored.

I do fear we don't have the resources
They will come, go, come go, it's part of a team life.

You can be the most dedicated team in the world, but if there's just not enough people to do the work, you're not going to get much done.
There is always people available to volunteer for good ideas when they know about it.
Lots of very skilled persons have free time that they spent sillily, and are waiting for the right project to get involved into.
They just need to hear about it. Maybe we need to advertise the project a bit more and post "Looking for volunteers" in other forums, etc...
Mar 17, 2008 at 3:22 AM
While I do agree with you, a smaller project that actually makes good progress is better than a larger project that never really gets off the ground.

I'm not saying we can't do it, but we need to consider if we can actually write an entire game middleware solution.
Mar 17, 2008 at 5:03 AM
a smaller project that actually makes good progress is better than a larger project that never really gets off the ground

I think that the size of the project does not makes the difference as soon as it is well designed, planned and organized.
The schema is always the same : we need to clearly define the list of tasks (you already did that on a per-version basis) per milestone and progress slowly but surely from one milestone to another.

As soon as the tasks have been completed for a given milestone, unit tested, system tested, we follow on, smoothly, with no stress

If it has to take five years, it will take five years :)

we need to consider if we can actually write an entire game middleware solution
I agree on that point.
Mar 17, 2008 at 5:19 PM

I think that the size of the project does not makes the difference as soon as it is well designed, planned and organized.
The schema is always the same : we need to clearly define the list of tasks (you already did that on a per-version basis) per milestone and progress slowly but surely from one milestone to another.

As soon as the tasks have been completed for a given milestone, unit tested, system tested, we follow on, smoothly, with no stress

If it has to take five years, it will take five years :)


Five years for what? To finish the project? To get it in a usable state? In give years, XNA Game Studio will be a whole different beast. Technology like this changes every year, and projects must evolve to change with it. If we take five years to develop what we consider a complete project, we'll need to spend another year or two adapting it to the current state of XNA Game Studio technology.

That's my problem with our current situation. We don't have the manpower to effectively develop a complete game middleware solution. Unless we get an influx of developers, I think we need to reconsider our scope.
Mar 18, 2008 at 4:55 AM
Five years ago, we were at .net 1.1 which is not that old and still in use everywhere.
We just need to keep up to date with every new release of XNA, that is a major point.

If you aim 120% you'll get 100%.
We will have the manpower, just be patient, slowly but surely.
Mar 18, 2008 at 5:16 AM
I wish I had half of your optimism. :)
Mar 18, 2008 at 6:30 AM
Now, where are we at the networking ?
Can we get a list of current modules/tasks being held and who does it ?
Mar 18, 2008 at 4:21 PM
mikelid109 was still working on the interfaces and general design, but I haven't heard from him in over a month.

Patch 670 is the latest submissions we have from him.
Mar 18, 2008 at 11:14 PM
I'm used to VSS but not CVS, so for the patches thing , do we just get the latest version from the server or do we have to do anything else ?
I'm confused. I've got TortoiseCVS.
Mar 18, 2008 at 11:30 PM
Edited Mar 18, 2008 at 11:31 PM
Unfortunately, CodePlex uses a version of Microsoft Team Foundation Server. From the CodePlex main site, you can download the cpc (CodePlex Client) program, which is a command-line tool for interacting with the source control servers. Sturm also created a build environment for us with a lot of these things already configured. If you download the latest source tree, there should be a setup.cmd script in the root of the source tree. Execute that script, and it will create a shortcut on your desktop. Execute the shortcut on the your desktop and you'll get a command prompt within the source tree. The command "cpc update" will refresh your code with the current version online. To apply a patch, download the patch from the Source Code > Patches tab on this web site to your source tree root directory. Then, use the command "cpc applypatch <patchfile>".

If you don't use Sturm's build environment, you will need to configure a diff tool with cpc. See the cpc web site for directions. http://www.codeplex.com/CodePlexClient

Be warned, cpc is definitely the worth source control client I have ever used. There is an SvnBridge client that allows you to use SVN (including TortoiseSVN) instead of cpc, and I highly recommend it. Unfortunately, it does not recognize the cpc patch file format, and all of our patch files are in the cpc patch file format, so you need to use cpc to check out source trees for patching.

LordIkon, speaking of SVN, are we going to go through with the plans to switch to SvnBridge + Unix/Linux patch files for post 0.19?

Better yet, have you considered moving the project to Google Code or SourceForge?
Mar 18, 2008 at 11:57 PM
I have hosted a project on Google code and like it so far.
I recommend this approach , particularly when I see how CodePlex show up in Firefox !!!
There is also the Google Documents thing which is nice.
Mar 19, 2008 at 12:06 AM
Don't worry, your eyes will adjust to the lime green and stop bleeding after a few days.
Mar 19, 2008 at 12:09 AM


shawmishrak wrote:
Don't worry, your eyes will adjust to the lime green and stop bleeding after a few days.


Uh ... so we don't move ?
Mar 19, 2008 at 12:10 AM
I don't know, I'm just telling you not to worry about your eyes bleeding from the CodePlex color scheme.
Mar 19, 2008 at 12:11 AM
hehe
Coordinator
Mar 20, 2008 at 10:00 PM
I'll have to take a look at these other sites. If we did move I'd leave this one here and redirect people, so we could still get traffic from all of our original links still floating around out there (most of which is simply google though).

What are the benefits of the others, if anyone knows any stuff offhand?
Mar 24, 2008 at 4:20 PM
Any further discussion on the hosting subject should be posted to the thread
"Transition to Google Code / SourceForge?" at the following address :
http://www.codeplex.com/QuickStartEngine/Thread/View.aspx?ThreadId=24304

Any further post to the current thread should be about its original subject (Networking in v19).
Thanks