ORK + Makinom + UNET = MMORPG

@Zhenit Its probably possible. But i would not recommend doing 3 huge frameworks at the same time for a multiplayer game not with unity. the overhead would be to much. Now lets say you where to take just ork and unet or just makinom and unet then the over head wouldnt be so much. But as some one who is a game developer for a living and knows both unet, old unity networking and photon. i would not mix ork, makinom and unet together. if u go with just ork you will need to write work around scripts in order to do quite a few things with out needing to touch ork code. other wise u will have to adjust orks code. if u go with makinom u dont need to adjust any code and can do it all from with in makinom. Things u need to know about networking.

1: careful with how many things you have animating at the same time. if not using a dedicated server.
2: make your own culling system. the built in one for unity sucks.
3: use lod's
4: use bytes for every thing that u can. (including bools, vectors and so on) this is crucial to so that you dont over load the network while sending information.
5: keep as much as you can off update.Use delegate's when ever u can. this will help keep things off update an only do things on change.
6: always test on different systems builds. run the game on the lowest preforming computer u can get ur hands on . (suggest laptops for this. due to the mobile cards running lower end gpu's or lowend phones based on what platform you are shooting for )

all in all just remember unity is not very well optimized. which means u have to do alot of leg work to get things running smoothly. use the built in profiler while debugging sometimes lag is caused by graphics more then code. try to keep tris counts on models as low as possible with out losing to much quality. suggest around 20k to 30k for npcs 10 to 20k for buildings and such and up to 50k for the main characters for unity.. this is due to unity not being optimized at all. the graphics engine needs alot more work...

thats all i can think of atm so for now good luck online games are a pain in the ass but if u work at it u can make some thing good. also remember with networking u will always need to know a bit of c# in order to do certain things.

Thanks for the friendly comments, my idea is an MMO mobile, low poly. I would use Makinom only in the UNET part to facilitate the code, but I can leave out.
In the Store has the uMMO system, promises UNET integration only by plugins and a dedicated server.
Somebody knows? Would the use of this system be as problematic as Makinom?

@gamingislove
No need to apologize, I think it is very busy, so I decided to post the question here. I just have to thank for this fantastic system. ORK is wonderful!

I have some more doubts:
Would using Photon be better than UNET?
How would you do to save the information of clients in a database? (I do not refer here to the use of the database, this I know)

@Zhenit photon is no good its mainly for co-op play or single instance areas's unless you good at loading and unloading levels. but the work arounds with photon are rough some times. and the support sucks. Unet can handle a mmo. but like @dlevel said ue4 is better for a mmo environment. since the networking part is done very well. issue you will have with this is that you will need to know c++ to do some things(also learning unity c# will help you big time in learning blueprint ). But that goes for all engines u will need to know their base language in order to do much of anything. cryengine is also good for mmo's and used quite often for it. but u need to know either c# or c++ to do anything good with it. they have a node type system as well but its not really optimized well.

ORK's save game is just an XML formatted string saved into a file - so it's pretty easy to change the code and save it into a database instead. The class responsible for this is the SaveGameHandler.

Well, I finished a good part of the tutorial game, ORK's ability impressed me a lot, but I realized how much work I have to make the modifications I want.
So I started Makinom tutorials and I need your opinion:

- Is it possible to create a MMORPG with Makinom and its UNET functionality?
- Can I use third-party assets such as Inventory Pro, NGUI, Dialogue System, ..., along with Makinom?
- How to use databases with Makinom?

@gamingislove
Could you create a multiplayer game tutorial that has good complexity?

Thank you friends.

I'd say that Inventory Pro is fundamentally incompatible with ORK, unless you want to ignore ORK's inventory system entirely.

The only way that I can see the two working together is if you maintain two separate item databases and add a custom script to each Inv Pro item that associates it with an Item in the ORK database.

Keeping the parallel databases in sync would be a nightmare.

The time and effort it would take to build such an integration would be better spent creating a custom UI on top of ORK's inventory system. That's the primary advantage Inv Pro has over ORK's item system anyway.

@dlevel
@Keldryn

Thanks for the explanations, but about getting a whole MMORPG using Makinom and its UNET capability?
Does this same Inventary PRO issue also apply to Makinom?
How to use database with Makinom?

Dialogue System does include a Makinom integration, I believe.

I don't believe that Makinom has any sort of inventory system built-in, so you'd have to roll your own or integrate with a third party system like Inv Pro. It probably wouldn't be too difficult to build some custom schematic nodes for Inv Pro by looking at its included Playmaker actions for guidance.

I can't really speak much regarding using any of these assets for an MMORPG. I don't enjoy playing them, so I haven't spent much time seeing how one might build one. However, it is still my opinion that an MMORPG is simply out of reach for the vast majority of indie developers. The scope is just too large for a small team to handle.

Zerano's RPG Kit (on the Asset Store) might be a better fit for doing an MMORPG; it's set up for co-op multiplayer so you'd still need to do a lot of work, but it's a starting point that is likely closer to what you want to achieve. It doesn't get updated anywhere near as often as does ORK, nor does the author appear to provide anywhere near the same level of support as GiL.

I would be very hesitant to take on a major dependency on an asset that has such an inconsistent level of support, but the option is out there.