title: Immutable game object, basic functional programming question
body: <p>I'm in the process of trying to 'learn more of' and 'learn lessons from' functional programming and the idea of immutability being good for concurrency, etc.</p>
  
  <p>As a thought exercise I imagined a simple game where Mario-esq type character can run and jump around with enemies that shoot at him... </p>
  
  <p>Then I tried to imagine this being written functionally using immutable objects.</p>
  
  <p>This raised some questions that puzzled me (being an Imperative OO programmer).</p>
  
  <p>1) If my little guy at position x10,y100 moves right 1 unit do I just re-instantiate him using his old values with a +1 to his x position (e.g x11,y100)?</p>
  
  <p>2) (If my first assumption is correct)
  If my input thread moves little guy right 1 unit and my enemy AI thread shoots little guy and enemy-ai-thread resolves before input-thread then my guy will loose health, then upon input thread resolving, gain it back and move right ... </p>
  
  <p>Does this mean I can't fire-&amp;-forget my threads even with immutability? 
  Do I need to send my threads off to do their thing then new()up little guy synchronously when I have the results of both threaded operations? or is there a simple 'functional' solution? </p>
  
  <p>This is a slightly different threading problem than I face on a day to day basis. 
  Usually I have to decide if I care about what order threads resolve in or not. Where as in the above case I technically don't care if he takes damage or moves first. But I do care if race conditions during instantiation cause one threads data to be totally lost.</p>
  
  <p>3) (Again if my first assumption is correct) Does constantly instantiating new instances of an object (e.g Mario guy) have a horrible overhead that makes it a very serious/important design decision ? </p>
  
  <p><strong>EDIT</strong>
  Sorry for this additional edit, I wasn't what good practice is on here about follow up questions...</p>
  
  <p>4) If immutability is something I should strive for and even jump though hoops of instantiating new versions of objects that have changed...And If I instantiate my guy every time he moves (only with a different position) don't I have exactly the same problems as I would if he was mutable? in as much that something that referenced him at one point in time is actually looking at old values?.. The more I dig into this the more my head's spinning as generating new versions of the same thing with differing  values just seems like mutability, via hack. :¬?</p>
  
  <p>I guess my question is: How <strong>should</strong> this work? and how is it beneficial over just mutating his position?</p>
  
  <pre><code>for(ever)//simplified game-loop update or "tick" method
  {
     if(Keyboard.IsDown(Key.Right)
        guy = new Guy(guy){location = new Point(guy.Location.x +1, guy.Location.y)};
  }
  </code></pre>
  
  <p>Also confusing is: The above code means that guy is mutable!(even if his properties are not)</p>
  
  <p>4.5) Is that at all possible with a totally immutable guy?</p>
  
  <p>Thanks,</p>
  
  <p>J.</p>