So I’ve gone through the planning phases for a top down space game sort of Escape Velocity style, but multiplayer capable and I’m looking for a good engine to work with. Among other things, that would mean being able to have a standalone server app. I’m comfortable with both Java and C++, but I like the portability of Java. Is JMonkey flexible enough for that sort of thing? I intend to have the world serving code working underneath the single player game so that I’m not trying to make two different types of world handling, sort of like how Minecraft does it these days, but not necessarily ad-hoc jumping into other people’s games. Does that make sense and do you think JMonkey will do the trick? I’d like to avoid writing an engine from scratch.
Certainly possible, I see no reason why it should not work.
One old prototype of mine.
JME is definitely right for this. We have a couple of similar game projects on the forum.
I’d say JME is suitable for any kind of game as long as you can afford to put the right amount of work into it. That said, I’m probably biased, but I guess you weren’t expecting an unbiased answer since you asked your question here 
So to brush up the issues you’d have with a multiplayer space game, here are some of them on the top of my head :
- Far distances. Usually space games scenes covers thousands of kilometers which must not be considered the naive way (like 1JME unit = 1 kilometer for example) and hope for the best. You’ll have float precision issues for sure when the camera is far away from the origin of the world. A common workaround is, instead of making the camera travel through the world (space here), to make the world travel around the camera, and keep the camera at 0,0,0. Note that this is an opengl thing, not really a JME thing.
- Multiplayer game. Well…there again not a JME issue, you’ll hit all the snags of making a real time multiplayer game. We have a networking library called SpiderMonkey, but it’s just that, a networking library. You’ll have to handle the way the client and server updates their information and talk with each others. Here i guess some more experienced monkeys in multiplayer games, could give you more details about this.
- Assets. You guessed it not related to JME neither, creating assets for a games is the most time consuming part IMO, and that also true for a space game.
The rest is a walk in the park…
Sounds reasonable. On the distance issue, the plan is to have only one star and orbiting bodies loaded at a time. To maintain a sense of scale while remaining top down the star itself would be below the playing plane in the distance, other stars, nebulae, and similar decorations would probably be skyboxes or the like. Distance would be measured in some multiplier like thousands of km. The restricted zoom of the top down format eliminates the need for excessive precision. I think that internally, the coordinate scale for placing objects and rendering could theoretically be even lower, especially doing all of the rendering with camera relative coordinates like you’re suggesting. Does that sound workable?
Multiplayer wise, having a networking library is a major plus.
Assets, definitely a major time sink, but that’s the name of the game (metaphorically speaking).
On the topic of assets, is working with the integrated blender package the best option for compatibility when I get to that point?
That sounds fine.
For blender it’s preferable yes.