Forums Thread

@Anthony

I think we should have the server and all supported code in C#.NET or Mono as possible.  This will allow us to have one code base that is easy for all programmers to modify in the future and we don't have to have any special ability from anyone to make changes.

In TFS you will now see a Server.Game, Server.Chat, and Server.Interface I split these up to run as separate service so that we can run them from different server if need be in the future for scaling.

The server will run from our main server so I'm not sure what functionality we will have by using a command line on the application.  Can you explain that a bit more please.

Thanks,
James Fleming

I agree that everything should also be in C#. This saves us from having divided developers. We can have C# devs that work on all code related to the game, client, and server. To explain the command line interface a little more... we are just going to run the game itself like we are trying to run it from a command line, from the client. So say after matchmaking, the client program will save the players, what teams they are on, and their preferences in the sql database along with a unique game is. Then, we start the game, The program will call to open game.exe --args-game 12345 where 12345 is the unique game id the players just created in the matchmaking lobby. Then the game will load up as normal reading the game id we passed it and it will immediately grab all essential data from the sql database that's needed to start the game. So overall no one will notice any command line interface because that will all be in the background. A good example of this set up is league of legends.


  - Anthony Michelizzi

Here is the initial unity code I had worked out to get the game id passed via command line in unity.

https://github.com/cynical89/unity-client/blob/master/Assets/scripts/startArgs.cs

Here is how I started the game from inside the JavaScript application.

https://github.com/cynical89/game-lobby-client/blob/master/javascript/startGame.js


  - Anthony Michelizzi

I understand what your saying the next question would be would this be simpler then having it as one application that just loads its in the same client?  Technically speak what reason would we have to split them "Pre Game" vs "Game"?  To me we would have to manage two code base and make sure they talk to each other.  Which granted after its set up wont be hard but is their a logical reason to do it like League of Legend?  To my understanding they do this because of some coding issue in language is what I heard but I'm not sure.

Thanks,
James Fleming

Thinking about this a bit more the only time I can really see this as a reason would be for an update client so we can update the game when need be because the client can not override its own files.  We do this with the Member Collaboration Utility right now.

Thanks,
James Fleming

I looked into this for a couple reasons.

1. Cost. If I wanted to make a multiplayer game myself, due to cost restraints I would start out using something like unitys networking. These solutions limit you to a specific number of concurrent users. So keeping them in a client instead of in game is cost effective.

2. Updating the game. I couldn't find a good solution to upgrading the game to a newer version if it was patched as of this point. So having a client that can modify the games files and download updates made that easier, it also kept someone from running the whole game AND trying to update their game which I felt would allow a few more lower resource systems in the loop.

3. Server communication. The servers can still be split up no matter what. That's not an issue. But making the login server talk to this server and that server and all of them link together and every step keep passing information back and forth seemed a little inefficient. My setup allowed a simple solution to this since the servers also don't have to maintain a connection to each other or communicate in anyway. The client saves all information in the database and the game server loads from the database. So I felt for my personal use this was an easier way to do things. This may not be the case for us.


  - Anthony Michelizzi

Thanks,
James Fleming

I can make up whatever we need. I get off at midnight tonight which is in about 2 hours. And I have the next 9 days off. Also one more notable point is that should the game be a console game and not just PC/Linux/Mac we will still need some sort of ingame gui for the console stuff. So depending on the entire scope and whether or not the console will have limited up anyways since they handle their own chat this may not be relevant


  - Anthony Michelizzi

@Anthony ok sounds like a loan for now I would like to focus on the PC we will port it right after we get a working prototype for the PC working. For now I'm going to add you to the agenda for the next sprint since this iwos in relation to that task.

Thanks,
James Fleming