Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Dec 2004
Offline Last Active Jul 16 2016 06:16 PM

Posts I've Made

In Topic: Following the Train Tracks or Plumbing the Depths

16 July 2016 - 06:16 PM

For at least a potential solution to the shallowness and shooting gallery paradigm most/all MMORPGs have degenerated to, you might want to read what I wrote in the bottom half of this posting :





Ive talked about this years ago (probably in the Game Design forum) but I cant seem to find those postings.





In Topic: How do you deal with shared data and work load balancing?

09 July 2016 - 08:47 PM

See if you can handle some of the operations as seperate staged/phased  data waves(?) within the server with seperate core-threads working each 'phase' in a pipeline fashion. 


Thats to allow use of coarse locks on large chunks of data, which get handed off to the next phase en masse (With minimal lock manipulations)


That is independant groupings of processings like network processing(client sessions)  and decoding inbound commands, actioning and arbitrating game mechanics events, outbound data to clients, etc...   With the 'turns' pipelining (internet delays mean the game probably can be processed in steps without affecting perceived timing).   When each thread finishes wuth its turn data (and is waiting for its next turn to start)  it might do some secondary less time dependant tasks as filler...


Note that this frequently does require some data replication and buffering between the pipelined phases to keep them independant (the data that phases processing is taken in,  integrated, and then what its producing marshalled to be passed on to the next phase).   Some heavy phase processing might be run on more than one core  with the inbound data read-locked and outbound data designed to be inedpendant (just gets queued up for the next step down the pipeline. 




This kind of thing is more used in Clients which may be doing prep work 2/3 rendering frames ahead (with seperate core-threads working in parallel) and the handoffs of phase completion and with tasks broken up to try to keep all the cores as busy doing useful work as much as possible.

In Topic: Optimize field of vision algorithm in a grid tiled map

08 July 2016 - 07:58 PM

Hmm Amit has a page on this:  http://www.redblobgames.com/articles/visibility/



Though, also, you probably don't need to do an actual raycast for the initial check, which I think is what wodinoneeye is saying, you could do a bresenham/wu line walk to check if a tile is empty or not.



Actually its not a 'ray trace' but a precanned set of stepped vectors for a fixed radius grid test (the whole surrounding grid from the centerpoint or limited to only some of the 8 half quadrants if a limited  boresite is used.   That for fast culling of whats NOT within view and then more precise methods can be done on the identified grid edges/boxes  (or the now identified sets of objects within those grid boxes).   Because of the stepping order, you also get a sequence that might be useful for calculating a progressive  partial visibility through intervening obstacles.    I used to make the diagonal cases inclusive of assuming visibility (leaving questionable cases to culling later with more accurate methods).


I also used this quick cull method while doing rough influence maps.

In Topic: WW2 Pirates - world scaling and settlements?

07 July 2016 - 03:08 AM

You might want to make it well AWAY from the front lines where both sides have major assets ready to blast anything that remotely looks wonky.   You have to remember that even merchant ships in WW2 were much more armed than in peacetime (when such things ate into the profits, which might not be as much a consideration during war).


Privateering might at least NOT have everyone after you (and a source of supplies/equipment/intelligence)



In Topic: Optimize field of vision algorithm in a grid tiled map

07 July 2016 - 03:00 AM

I used to do this with a canned array of vectors which went thru every point within a fixed max distance. Really it neead be no more than  +/- 0/1 data for X and Y  progression along an angle,  a growing offset for eact vector   (I even reused the same  +/- 0/1 array flopping over its use on each half quandrant   8 similar pattern upon a 45 degree wedge).


You grow vector til you hit then the rest is LOS blocked yeyond.


Its a low cost processing (simplified math and tight loops).