Supporting more than one player on the client

[Lazy]

A few days ago I got an idea to allow upto 4 players to play half-life on one machine at the same time.
The view would be split either half/half or into fours depending on how many people are active at the time.
So far I have it able to render the 4 views while putting inactive ones out of map bounds and looking down to keep up the framerate.

I realize almost all of the network messages have to be changed aswell as saving/loading, ect but I have run into an odd situation.

How can I have extra players on the client control their players on the server?
I've thought about:

- TCP/IP Sockets
- Shared memory area
- Sending commands containing information ( ugly, I know )

What would any of you do to get the angles/buttons/ect to the server?

Note: This would have no online capability but would support co-op and deathmatch locally.

Added before submit: Wrong place? It still has to do with the sdk... bah, I'm confused.

[Pierre-Marie Baty]

I would go through TCP/IP sockets. The game DLL would control 1 real client and 3 bots, the real client would use the HL network protocol, and the 3 others another protocol of yours. The advantage is that you don't need to send much to the game DLL (only position, angles, velocity and buttons). On the other hand, I wish you good luck modifying the client DLL, because I foresee quite a lot of changes of importance.

[Lazy]

Yeah, quite alot will have to be changed. Luckily somethings can be removed which should cut down the workload.

- view.cpp: ALOT has to be re-written
- HUD/sprites: Have to be drawn using TriAPI so they can be scaled down to fit the small screens
- Scoreboard: Can be replaced with scores in the upper-left
- SayText: Removed
- Spectator: Removed

Hopefully I won't have to change any movement code but I think the hardest part will be the views since I'm really bad when it comes to math.

Thanks for the advice, I'm going to start working out a protocol right away.