Yes. But then Java may not be the obvious choice.
Yes.
Java is probably almost non-existing on the graphical side.
I believe some multi-player games use Java server side.
Minecraft has both the client and server end written in Java.
don't know much about others games.
most of the other game engines I am aware of are typically written in C
or C++, usually with either a common scripting language (such as Python
or Lua), or a specialized scripting language (such as UnrealScript,
descendants of QuakeC, ...).
in most I am familiar with, servers are typically run by individuals,
usually either a "listen server", where the player runs the server and
also plays the game at the same time, and other players may join their
world, or a "dedicated server", typically where the server runs in its
own process, which may or may not be on the same computer the player is
using to play the game.
I am less familiar with MMOs though, but from what I can gather it is
more often that they will do something like the dedicated server case,
just typically run each area on its own server (often each on a
different physical computer as well). when a player hits an area between
server-managed regions, they will typically just jump from one server to
another.
my project more fits into the category of a game-engine mostly in C with
a scripting language, and is mostly aiming for the listen-server and
player-run dedicated-server use case (which may be coupled with the use
of an HTTP server for pulling other game contents).
I ended up trying to use Java for scripting at one point (since
Minecraft made it look like maybe this made sense), and ended up using
my own custom mini-JVM (using a JavaME like subset, mostly due to JNI
frustration), but soon enough realized that it didn't really make a
particularly great scripting language (didn't really fit in well with
the use case, and I couldn't readily "eval()" it).
(I also evaluated using .NET and/or Mono and C# for scripting, but this
also looked like a big mess).
so, effort mostly shifted back to my custom script language, which is
more closely derived from JavaScript and ActionScript (with a lot more
elements from C, Java, C#, ... glued on). (like, hell, I will glue on
what parts I care about).
it seems to work moderately well for game-scripting tasks, without the
same level of funkiness as Lua or Python (I more prefer an at least
vaguely C/Java/C# style syntax, even if the language still has its share
of funkiness, and the controversy over whether to the use JS/AS or
Java/C# style declaration syntax, ...).
theoretically, I guess it would be a more direct competitor with Lua or
similar though.
security is a potential worry case (yet to be adequately addressed IMO),
mostly to hopefully be able to prevent malicious content to be spread
to/from servers and/or exploit client computers.
these would be sort of like macro-viruses in MS Word or similar...
WinForms was supplemented with a slight taste of replaced with
WPF 7 years ago.
well, yes, but a person can choose whether they want to use WinForms or
WPF (at least in my version of Visual Studio, it gives both options in
the "New Project" box, along with "Console Application", ...).
No - Java EE does not necessarily cost money. JBoss, Tomcat etc. can be
used for free.
Java EE is server side. Client side will typical be browser, but can in
theory also be a Java SE desktop app or a .NET/native desktop app.
ok.
I had thought Java EE had been like some sort of bigger money-costing
version of Java SE (with more libraries and stuff).
granted, I had never really looked much into it.
In the EE space you would need to look at CORBA or DCOM.
You would prefer Java EE believe me.
errm, so you can't just copy all the files over to ones' servers? and/or
recompile the code for ones' servers?...
granted, dunno much about business systems, but I was under the
understanding that most were some combination of:
rack mounts running Linux, typically with x86 CPUs, and with Gigabit
Ethernet or 10GbE or similar linking them all together.
one or more server computers in a desktop-like form factor, sometimes
with multi-CPU boards, Xeon or Opteron chips, and craploads of RAM
installed, and sometimes also in a LAN. AFAIK, Linux is also popular
here. (though I guess Windows XP, Windows Vista, and Windows Server,
also make an appearance).
something more strange, like IBM mainframes or similar, where everyone
uses them via funky multi colored textual interfaces inside of a
terminal emulator, ... pretty much everything I have read about them
sounds strange.
as for data sharing (between lots of networked servers), I am less sure,
I would think maybe something like NFS or SAMBA, but then thinking of
it, NFS or Samba might not scale well if the number of servers becomes
sufficiently large (like, people would probably want to locally cache
files, rather than always doing IO over the network, ...).
I guess alternatively, an option could be a sort of centralized
batch-push or batch-pull, where a daemon or similar is used to update
all the servers, or something... (say, on a schedule, they pull from a
Git or Hg repository or something...).
but, in any case, people have probably figured out all this stuff already.
otherwise, not entirely sure why developing for these would be all that
much different than dealing with a normal PC or Linux box.