C++ Game, Java server

It's certainly possible, the data going through the socket is all the same. Although, why not write the client in Java so it's portable and the server in C++ for efficiency (If it matters, it depends on the type of game).

Hi Steve,

the client is my game & I'm gona write it C++. I've experience with Java so would like to write my server with it,

cheers

And I think what he is saying is - Java is very plausible for the client, and even better because it is very portable. C++ will probably end up requiring extra coding to port to different operating systems. Since you design the server for a specific computer (yours), then you don't have to worry about cross platform issues.

You will find out that in practice it also require a bit of work to port any
large scale java application.

C++ still takes a bit time but if you code with some consideration you will probly be fine in C++ as well.

Quote:

You will find out that in practice it also require a bit of work to port any large scale java application.

I doubt it could take significantly more time to port than a C++ project. Some of the hurdles with porting C++ is differences in the compilers on varying platforms. Add to that Java's enormous standard library means that a Java game will probably only need a handful of middleware libraries whereas C++ will typically need more.

I would prefer a C++ client and a Java server. Though, I want to try to discourage yet another language flame war, so I'm not going to list any reasons. Just wanted to tell the OP that he is not crazy.

This is something I'm looking at too, because I'm using Irrlicht on the client side (jirr is out of date) and because it's very easy to make efficient servers with Java (I use Mina for that).

In the case of using two languages, it's important to consider how much logic is common to both the client and server. If there's a lot of overlap you could be increasing your workload. Otherwise if your server is little more than a relay, then go for it.

As far as portability is concerned, don't underestimate the importance of it on the server side. You may want to run the server on your windows desktop machine in the game's early stages, then move to a paid linux dedicated server when the game becomes more popular. In fact I would suggest that server portability is more important than client portability and not to overestimate the importance of client portability.

To chime in, I am by no means an expert and an amateur developer.

I have a server coded and it runs on an old Windows box. It works fine so far. In fact, I am pretty sure the Eternal Lands postmortem talks about how he ran the server on an old (I think 700ish mHz at the time) computer. I think people tend to get ahead of themselves by worrying about transferring to a bigger and better server.

I show people my game client all the time, but I never have sent over the server for someone to run.

Quote:

I think people tend to get ahead of themselves by worrying about transferring to a bigger and better server.

True. But when people truly get ahead of themselves it's usually before they have anything resembling even the early stages of a finished game. It's safe to say that when someone makes it to the first release and is running a server at home, they'd better be prepared for the game to become popular. Sure, they can hire a windows dedicated server, but it's more expensive and their options are a bit more limited.

Anyway, I don't think we need to argue the point because the OP wants to go Java on the server side anyway. My suggestion for that would be to avoid stream-based IO like the plague if he wants the game to scale beyond 35-50 simeltaneous players. And that's from personal experience. I have used Java's non-blocking IO API (java.nio packages). It's a bit low level, but useful if you're willing to put in the effort to learn. Alternatively, use Apache MINA which is higher level, much easier to use and is built atop java.nio.

I agree: java.nio is often the most sane solution for I/O using standard Java. I/O before then was pretty lame.