next »

[motorsep]

The game engine I am using has basic networking capacity, but it has no server browser. Instead of implementing one embedded into the game, I figured it would be easier (or not) to make a standalone server browser app using Qt5 / C++ and connect to the servers running process with cmd line arguments. League of Legends uses that kind of approach (and may other games do too), so I figured it's not all that bad (although I suppose built-in server browser would be a better choice from end-user point of view).

I wonder if it's a massive project or something achievable in a relatively short time frame (and thus relatively inexpensive).

There is a source code available for built-in server browser (ranging from Quake 1 to Doom 3). There is also a protocol description available, and source code for a master server app. None of those matches the target game engine specs exactly, but I have a feeling since all of those are derivative engines/apps, it shouldn't be that hard to utilize all those resources.

Thanks.

[InfiniteStateMachine]

It's a fairly complex project. You might be able to get something up quick but ultimately it will take a fair amount of time to mature.

You're essentially talking about both a ui and a networking project.

You might consider some of the higher level networking libraries like raknet/enet. I can't recommend any as I haven't gone higher level than ASIO in the past.

[motorsep]

Well, it's not a networking per se. You'd just receive list of servers from master server app, and display it. When user picks one up, and presses Connect button, simply extract IP:port and use it in the cmd arg line to run the game (game.exe +connect IP:port). That's all.

As I mentioned, master server app is available, just need to add protocol support for the game.

Of course there is a chance I am oversimplifying it

[InfiniteStateMachine]

ohhh, do you mean all the game networking stuff is already done or handled by an engine? That does significantly reduce the amount of work.

That's not too bad at all in that case.

[motorsep]

ohhh, do you mean all the game networking stuff is already done or handled by an engine? That does significantly reduce the amount of work.

That's not too bad at all in that case.

Yeah, right now I can just run server using one instance of the game, and connect to it via console cmd from another instance, and play (or do all that remotely, if someone runs it on the other end of the world).

I just need to make it more user friendly

[dancing_dead]

if you're interfacing via console commands, is it not possible to use something other than qt/c++ here as well?

that's in case you're familiar with other languages and UI construction. I know I would try C# or Java for simple UI stuff way before C++.

[motorsep]

It needs to be crossplatform, thus C++ / Qt5 seems to be a good choice. Plus I poked around C++ and Qt5 a bit, so it would be a good project for me to learn more from. Also all the exiting infrastructure is in C / C++, so it would be easier to use/tie-in when using C++, vs anything else.

As far as UI, can't really beat Qt5 - it comes with sweet WYSIWYG UI designer, which allows designing complex UI quickly.

[dancing_dead]

sounds like you're set then

[motorsep]

sounds like you're set then

I might be capable of making a layout of UI in Qt5, but I definitely can't complete the whole project

[InfiniteStateMachine]

Yeah if you need multiplatform Qt is freaking awesome. Qt and WPF are probably my 2 favorite user-facing frameworks. Admittedly WPF has an insane learning curve though.

[surt]

If you've already got all the network code sorted then it should be quite straightforward.

Wrap a QAbstractTableModel around your server list. This would be the guts of it.
Wrap a QSortFilterProxyModel around your QAbstractTableModel to allow filtering and sorting by column.
Set a QTableView to display server list from your QSortFilterProxyModel.
QLineEdit to enter server list filter.
QPushButton to launch game with selected server.

Basic Sort/Filter Model Example covers basically all of this other than the custom QAbstractTableModel.

[kirennian]

I've messed about with WinSock2 for a master server -> client server -> client architecture before using basic Winforms, as well Qt5 integrated with DirectX (yeah I know...).  I'm also currently a commercial WPF developer soon to be doing my own thing back in indie dev and am looking to do server architecture so I have some thoughts!

UI:
Qt is fantastic for cross platform applications.  I once built a cross platform with it, developed on Windows and it just worked straight out of the box on Ubuntu a few years back; I'm assuming even greater strides have since been made to make that even easier.  My main issue was with the IDE which now trying to go back to from Visual Studio is just silly.  I hear there is an integration with VS for it though so that'd be worth looking into (I certainly will be purely so I can use WinSock2 again).  The very fact that it has its own OpenGL integrator yet it still really quite easily just opened the doors when I wanted to add DirectX instead speaks volumes for its versatility.  It's not a patch on C# for how quickly you can knock things out but I have no doubt you could do something simple in a very short period of time.  That said...

WPF, if you already know it, is very good for medium-large scale UI design.  For small UIs it's ridiculously overburdened and the learning curve is silly so if you don't already know it, ignore it like the plague.  I know Xamarin is pretty damn good for mobile apps and there are other ways of getting multi-platform with WPF but really, I couldn't comment as I haven't properly experimented with those yet.  For Windows UI design though and anything with more than a couple of views, it's really very good.

Java, I may well be biased but the only real benefit I can think of is that it's a happy middle ground.  C++ historically has been faster and C# has been quicker to develop for whilst Java was cross platform.  That said, C++ and C# are starting to bring in native support and both are as fast or faster than Java so I'd avoid it unless it's what you already know.

Networking:
WinSock2 is where things start to get a bit more difficult but I'd highly recommend it if you're tech savvy and like building custom libraries!  It's a relatively old set of libraries now but it's extremely quick - much quicker than anything C# related that I've tried to work with (SOAP/REST).  What I would suggest if you go down that route is to make something extremely basic in a week just to get to grips with the architecture, then step back and start designing before starting again with that design in mind (throw away your first design having learnt something).  The best way to unlock performance as far as I could tell was with a massive binary/hex definition library type thing and message types.  It's difficult to maintain which is why I'd recommend experimenting before starting a final version but once you get it, it can be very powerful.

After all that is considered though, of course things like security, databases (C# and Entity Framework would trounce Qt/C++ in both those regards), volume of potential players and your requirements.  Of course without knowing if you're aiming for single 8 player servers or 100 player ones it'd be difficult to suggest how you'd go about organizing it. 

That said, if you yourself aren't entirely sure, I'd recommend thinking of a scalable architecture; cut/drop bits of this you don't like, dependent on requirements but once you've got one of these WinSock servers working, the rest would follow suit quickly:

Overkill architecture!
Main Server:
All master client servers connect to this to relay and request information; this is not externally facing and you can only connect to it via internal servers.  This has a grandiose name but really, it just routes messages between internal servers... very little UI design required (maybe a global messaging system only?).

Accounting/Database server:
Heavily protected with no external connection, no internet, account SSMS management etc, massive amounts of logging, probably written in C# and only communicates with the Main Server.  You get the picture though, it's going to be over the top for 99% of projects; for the most part, roll this into the main server.

Master Client Server:
Useful only for systems which require a large quantity of client servers.  These sit internally but can be externally facing.  Client servers plug into these and send requests such as login and account updates (character information et al).  Individuals also send 'client server' information requests which will respond with IP addresses and server information based on those currently connected... nothing more detailed than that.  The idea is to abstract the client sensitive data away from generic more open commands such as requests for currently active servers... it's a bit of a balancing act I guess.  Can also contain blacklists; no cross Master Client Server communication.

Client Servers:
These are where game data would be routed between players.  Essentially this can keep track of player movements and all the other high volume requests required.  Players find/connect to these via Master Client Servers.  Every so often, these servers can send a refresh request to the Master server for game updates as well as to check for cheating or dodgy servers.  No cross Client Server communication.

Clients:
You login by sending a request to a Master Client Server (perhaps by region?).  Once logged in, all currently active servers can be found by sending a request to the master client server.  Once found, you click connect.  This sends your IP address from the Master, down to the client server and the client starts loading appropriate assets... No cross Client communication.


I realise I've just rambled and this is probably overkill; you can probably roll the Master/Main servers together and if you aren't storing account information together, push the Accounting server in there too so you only need one active host box.

I hope this helps.

[motorsep]

It all helps, thanks. As for master server / server / client stuff, it's all there, it exists. I believe there is absolutely no need to reinvent the wheel. Just need to adopt what's available.

Here is the master server app (Linux only I believe): https://github.com/kphillisjr/dpmaster

and here is what it does: http://dpmaster.deathmask.net/?game=warsow

I need basically the same thing (as on the webpage), but in a standalone app for Windows/Linux and OSX. Plus dpmaster needs to be expanded to "understand" new networking protocol.

[kirennian]

I think the only thing is a balance between what is already out there versus what you could do yourself, as with all things programming related.  Personally, I will be rolling my own as it has a niche set of requirements but it really does depend on what kind of thing you're trying to do. 

If you're looking at something which currently targets one system type but you need it to target all, I'd be a little wary of the time needed to do so versus doing your original suggestion of doing it in Qt/C++.  I've got no idea about dpmaster as a library but if it already does everything you need, it'd be perfect. :D

Really, I think requirements would be the first thing needed to know in order to advise anyway; it could be an 8 person server or 1000, real time or turn based.  To be honest though, I think rolling it on your own full time may take 'one unit of time' (don't know your experience) to properly get things set-up.  As for doing something pre-existing, it could take half that or it may not be possible at all, again dependent on requirements.