You might get trouble from having asynchronous communication, possibly together with different speeds of message processing. It is known as race condition. This might happen at every point where two messages target the same entity, and the order of those messages is crucial.

Say some entity is waiting for a timer message to fire. At some moment, the timer posts a message that it has run out (ie it can fire). At almost the same time, but say a fraction later, a projectile hits the entity, killing it.

So the entity should fire and then die, but perhaps the tmeout message processing is a little slower, so the hitting message arrives first, and the entity dies without having fired.

You also get in trouble if you want to reduce redundant code and components so lets say you have an enemy and a player component, both need a transform that says where in the world they are located and hat they are facing. Instead of adding those properties to each component, you decide to have a transform component but now how do enemies and players update?

What about message concurency? Some component might need to know values of another component but in between processing the component changed for a message processed after component A has read the values of component B but before component A finished processing. This may lead to artifacts in best and crashes in worst case

SillyCow said:
Simplified example: Hero raycasts gunshot to enemy → Hero's gun calculates that shot hit → Gun calls enemy's “do 20 damage” function.

You need to consider not only write access, but also read access. What data structures is the raycast using, and what happens if they are being modified concurrently with the raycast?

A few of the points you described I actually just read about in this book, http://gameprogrammingpatterns.com/

I think in general something like that would work. If you at least synchronized frames, you could easily handle the read/write race conditions by using something like a double buffer method. I think using multiple threads though might bite you in the ass. I think the reason asynchronous programming is taking off like it is, is because its lighter weight, and when not compute limited, faster that multi-threading. (Bare in mind, I am no CS). If you exceed the number of available threads on the CPU, you're going to end up with worse performance due to the OS context-switching so often.

SillyCow said:
I don't think that I am in danger of “artifacts” and race conditions, because any entity can only update themselves

This is wrong unless you never ever take other entities into acount and this won't happen because a player and/or enemy can have moved at the time the bullet hits it. So how do you make sure that such “artifacts” like a player got hit by an enemy even if he was already out of reach won't appear?

Generally speaking, map reduce is a tool towards a reasonable parallel execution pipeline and yes, you can write an entire engine using it and succeed. I know this because I've done a variation of it, I reworked things into something a bit more generalized and targeted towards games specifically. So, why not map-reduce as the only solution? Mostly because I wanted generic reusable systems and a GUI that could be used to deal with the extreme complexities involved. They end up the same, just start from a different location for the most part.

As to the bullet/impact bit. The way I deal with this in my engine which is parallelized from ground zero, is split the check and action. You run the code that moves the bullet, checks for collision and produces impact events in one part of the code. Then the other part has exclusive write access to physics/health and applies the events. The application portion is done single threaded but because I define dependencies between the functions and also the access rights they have to data, I can schedule other non-conflicting work at the same time and still fill up all the threads.

All said and done, I would suggest thinking in terms of map reduce but considering how to move to a data driven pipeline definition. I.e. you don't want the code to define the pipeline as it is too hard to keep all the bits of a game engine in mind, you could easily be talking about a chain of 100+ parts. Rather, I use a system where I declare each piece of code to be executed, what data it accesses, the rights to the access (read/write) and what other pieces of code are dependencies. From that, I generate the pipeline and collapse it, which is automated versus the manual version of figuring out where to map things, reduce things etc.