Thinking about rolling my own MMO server and want to know if it's feasible

I asked a similar question before but didn't get many answers, so I'd like to repeat my question as now I have a bit more detailed plan after an initial research.

What I want to do is a roll my own MMO server for a Second Life like game and I like to write the server part in Scala / Akka.

I know it might not be a popular choice of a framework, but it's a hobby project and that's something I'd like to try so let's assume it's part of the requirement. And I cannot use any proprietary product, since the project I'm working on is an open source wok.

Anyway, I did some initial research about the plan today and found the following. I'd like to know if I'm on the right track or if the plan is feasible at all :

• Using LLAPI is not an option, as it doesn't have any published documentation about the protocol and it'd be time consuming if I have to reverse engineer it.
• Using HTTP/TCP based RPC seem to be a unsuitable for a game where a lot of people move and interact with each other in real time.
  
• Building custom UDP stack would require quite a work, especially when I'm not familiar with such a low level programming.
• Not using Unity on server means I need to handle the physics somehow, for which only limited Java based options exist.

Considering these factors, I came with the following plan:

• Create a custom protocol based on Hazel Networking, as it seems to be pretty much the only open source game networking library that is being actively developed and lightweight enough to be easily studied and replicated in a different language.
• Use a native wrapper of Bullet physics engine for Java to calculate collisions on the server side. It looks to be the only Java based project that is still being maintained.
• Extract information of rigid bodies, colliders and terrain height map from a scene using Unity and store them on the server to create a server side view of the world inside the Bullet engine.
• Use Akka Streams/Persistence to build a server to synchronize the client side and server side states.

I'm thinking about writing a simple chatting system then building a proof of concept project where characters can move around in an empty terrain. But I'm especially concerned about the physics part since I have only a vague idea as to how much work would it require to build such a prototype.

So, here's a list of questions that I'd like to ask about the plan:

• Is it (the prototype) something a single hobbyist can achieve in 6 months or so if he's working on weekends?
  
• Is there any option I can use to extract rigid body/collider/terrain information from Unity assets outside the platform?
• Is it a good idea to use a native wrapper of Bullet to handle physics? Should I worry about the performance or stability?
• Is there any other libraries or framework that might help me building such a game?

Any kinds of feedback will be appreciated. Thanks!

 

Sorry, nevermind my question. I think I was too hasty in asking this before putting more thoughts on the subject.

After some more research, I realized it'd be prohibitively time consuming to go for that route, so I'll just use HLAPI or LLAPI instead for now.

Maybe I'll need to rewrite major portion of my game later if I ever decide to try that approach (possibly with libGdx) again. But I guess it'll become easier once I've finished working prototype using what Unity provides with its networking API.

I tried to delete the post after I reached the conclusion but couldn't find how to do that.