Multiplayer, Multithreading, and Game Loops Thread

[WALL OF TEXT INCOMING]

I'm in the process of designing an engine for a game I've been conceptualizing for a while, and would appreciate any thoughts people might have on things before I implement them, particularly as they relate to the "while (game should not close) { //do stuff }" loop.

Ultimately, my goal is to have a dedicated server handling multiplayer. Having done some research, it appears that there are three ways of implementing this. First, I could have the server take in input from all of the clients and handle all of the game logic there, then send output back to the clients to draw on the users' screens. Or, I could have the clients handle some of the game logic, and have the server handle the rest. Third, I could have the server only transfer object position and state data, with the clients handling all of the game logic.

The second and third options seem dodgy to me, and particularly easy to manipulate, if not cheat outright with hacked clients. While that might not be a large issue, it is still a concern of mine, because I don't want to put out bad code. With that in mind, I'm almost entirely certain that the first is the best choice for my project.

That leaves me with the question of how to design the event system... and is compounded by the other question of "How do I implement multi-threading in my engine."

- - - o - - -

I'd like to have a dynamically generated world, where as players move through the map, it is procedurally created around them and offloads regions as soon as the player(s) leave the area. I'd like to shove all of those calculations, from taking object position data to building the vertex buffers, into a separate thread or threads to keep the FPS at a reasonable number.

I found an article published in 2006, when multi-core processors were still relatively new, that explores some of the possible ways of implementing multi-threading in a game loop. Two options I'm partial to are the second and third methods, data parallel (top) and asynchronous function (bottom).

From those, I've worked out a possible concept, and would appreciate any feedback anyone can give me before I commit to it.

My idea is to have, on the client-side, an asynchronous thread exclusively dedicated to generating vertex buffer data for the environment, with a stripped-down game logic loop to send user input to the server, then process data sent back from the server and combine it with messages from the vertex buffer thread to draw everything to the screen. The server would have nothing to do with rendering, but would handle all actual logic.

Is this a reasonably effective/efficient way to do this?

Edited by: Prometheus1998_