Author Topic: 2D MORPG design  (Read 2665 times)

Kalagaraz

  • Guest
2D MORPG design
« on: July 19, 2013, 09:46:28 PM »
So I've been working out how to use TNET to design a 2D morpg. The idea is that a single headless unity instance will be the Authoritative server.

Tilemaps will probably be either 128x128, or 256x256 in size (32x32 tiles). Each tilemap will be in a seperate "scene".

When clients enter an area, they will load the scene (unloading any old scene). Without changing channels

Headless Server will load the scene additively, as it has to manage areas with other players as well. Area of interest will be managed by adding a simple area check on non-unity server before routing messages (since we are no longer really using "channels"). When all players leave an area, the area state will be saved and the scene object destroyed.


Does anyone else have anything thoughts or better suggestions on how to do a similar design? The main thing is I want a headless unity instance managing the entire game world. I don't want to have 30 servers running for 30 different maps.

Thanks,
Kalagaraz


ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: 2D MORPG design
« Reply #1 on: July 20, 2013, 03:52:57 AM »
Why have a headless instance of Unity? You will save an incredible amount of resources by writing your server-centric code right inside TNServer. Better yet, you can rethink your design in such a way that even putting additional code into TNServer is not necessary -- just do everything via RFCs. I always say, before you worry about hacking, make a game worth hacking first.

Kalagaraz

  • Guest
Re: 2D MORPG design
« Reply #2 on: July 20, 2013, 07:13:14 AM »
Why have a headless instance of Unity? You will save an incredible amount of resources by writing your server-centric code right inside TNServer. Better yet, you can rethink your design in such a way that even putting additional code into TNServer is not necessary -- just do everything via RFCs. I always say, before you worry about hacking, make a game worth hacking first.

Because I was thinking that handling things like collision etc... would be more complicated without unity. If I handle collision just on the TNServer instance, i don't have any knowledge of the tilemaps etc... so I would have to program all that in? . Just seemed simpler to do it all with a unity client acting as server, if I add maps, it already has knowledge of them, + I can just use unity physics for collision etc...

Would be some major code changes to go back and rewrite everything from being on the client to being on the server. Take collision for instance, can be handled on client extremely easy, unity does it all. But now a hacker is going through walls and stuff. Now I have to program in client side interpolation and extrapolation from server updates and latency compensation on the server. Depending on how I handled other things, it might not be a simple task rewriting large chunks of code to move things from client to server without breaking other things.

Like for instance since I have real-time combat in my game, now I just moved movement to server so now combat is going to be boinked. Due to latency when a character shoots an arrow at an enemy, by the that packet reaches server, enemy has moved. So even though client registered a hit, server did not. So then I'd have to go back in and program position tracking and latency compensation to smooth that out (i.e client latency is on average 80ms, so before I register a hit, I rewind object position 80ms and then do hit check).

Just seems a lot easier to program all that to begin with, then to go back and rewrite everything for something that will eventually happen.
« Last Edit: July 20, 2013, 07:20:33 AM by Kalagaraz »

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: 2D MORPG design
« Reply #3 on: July 20, 2013, 03:00:56 PM »
Like I said, make a game worth hacking first, then worry about hackers.

Worrying about hacking before making your game is like premature optimizations in your code. Both only cause frustrations, delays, and quite frequently -- major bugs.