Friday, March 15, 2013

Considerations on Terrain Maps

So I'm still working on Terrain, and have no visual updates to include this time.  I started development on one form of terrain, but my original design was going to yield 50 megs map files that would need to be reloaded, edited and resaved by the server any time a change happens.  ouch.  I needed a better way.

First, I took a look at what my current architecture requires:

  1. Players have 3D maps, that can dynamically change and often during game play
    1. In order to place buildings, sections of land would need to be leveled. 
  2. The server is primarily responsible for logic, to reduce client hacking abilities.
    1. This even includes subtle validations on the land.
  3. MVC4 Restful Services would mean the data file for the map would need to be reloaded on the server every time a change occurs, or even just to validate land structures.  
    1. For the 50 Meg file size, and potentially hundreds of simultaneous users, this would have crushed the server from Hello.
  4. The MVC servers translates everything to text for transfer to client.  That would increase the content size, processing effort, and transfer speed of the binary map data.
To try to meet all of these concerns:
  1. The tiles will be managed in smaller segments, probably 32x32 tiles at a time, or 1024 tiles. 
  2. These blocks of tile data will be saved in binary form.
  3. The block files will be stored in a location accessible through the web.
  4. The client will directly download the smaller binary files, skipping the use of MVC4.
  5. Map Processors on the server side will be designed to work directly against the binary format, instead of fully loading the tiles into objects, allowing direct read/writes to the binary files as needed.
  6. Depending on the amount of data changing from the Server Side Map Processors, 
    1. Smaller data changes will be sent to the client to apply to memory directly and leave the cached map files alone.  When the client logs out and back in, it will download any maps files that are out of date.
    2. Larger changes will just download the map change immediately, and reload it into memory, overwriting the previous knowledge.
First proof will simply be the first 32x32 grid of tiles.  creating on the server, and displaying on the client.  No caching or anything like that yet.

I'm hoping this first draft should be ready within a week.

Also, some people have commented to me that they haven't been able to connect to the game client because there routers complain about the DNS.  WarpWars.RR.NU (or anything from .RR.NU) has its DNS set dynamically, which some security systems flag as dangerous because it is less stable, and has more potential of hiding hoodlums (Not Hoodlums!) with fake sites.  As that is the case, I will see about getting a more appropriate locked DNS name.  (warpwars.com is taken)

If anyone cares to, come up with potential domain names at godaddy or somewhere else, that might suit the game, and let me know if they are available.  I may (or may not) pick the domain name you chose.  :)

1 comment:

  1. Found out WarpWarsCity.com was available, so I took it. as you can see, the blog is already moved to it, and I'll be addressing the site/services/domain issues soon.

    ReplyDelete