Before you go "OMFG IDIOT LOCK LOCK LOCK", I am a coder and have experience with C++, Lua (in a different game), various internal scripting languages, BASIC, and Java.

I first had this idea when I saw "Cortex Command chatroom" created by (Griff?). That has convinced me it is possible to hack in MP.

I say "hack" in because true multiplayer would require re-writing the source. However, hacking in multiplayer is possible with Lua (or really any decent language). It's been done in other games where "multiplayer" is impossible. All you need is one thing:

The ability to control NPC's via whatever language you are using, and an external server (to compensate for the fact that it is impossible to code in a CC server). The main issues are definitely server joining\hosting, but those could probably be solved by joining servers using IPs and hosting servers by setting a variable in the console.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So, conceptual idea of how to hack in multiplayer:

1. Get an external server, this will be used for transferring data between both players.
2. Create an NPC actor in each player's game.
3. When player 1 moves in his game, move the NPC actor in player 2's game. When player 2 moves in his game, move the NPC actor in player 1 games.
4. This "moving" is handled by uploading the information to the external server, and then receiving it on the other end. It is then used to tell the NPC what he should do.

Now, this entire idea hinges on two basic premises:

1. That it is possible to transfer data to and from an external server. I would suggest starting with something simple, like transferring health back and forth to the NPC actor. So if you take a bullet in your game, the NPC actor in the other game has his health go down.
2. That it is possible to control NPC's via Lua, with unerring accuracy. Let's say Player 1 fires a bullet at the NPC actor in his game. What needs to happen in Player 2's game is that the NPC actor must fire the exact weapon, as soon as possible, at the exact trajectory. If this does not occur then serious problems will happen, that may make people think "WTF? LAG".

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The best way to implement multiplayer, if both of the above are possible, would be to do it in milestones.

First Milestone:
Create a simple "join" and "host" command. Host will upload your IP to the external server, and join (IP) will search the external server for that IP and if it is there create an NPC actor in your game and there game.

Second Milestone:
Allow chat between games (technically already done). Synchronize NPC actor and player health across games.

Third Milestone:
Synchronize movement. (This one is likely to be the hardest)

Fourth Milestone:
Synchronize actions. Such as shooting, buying, switching clones, ect.

Fifth Milestone:
Playable beta.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The main hurdle of this idea, outside of the basic premises it is based on, are:

1. The server. You will need an external server that can support receiving and transferring data on both sides, as fast aas possible, for as long as the game lasts.

Now technically all you will need to send regarding data is what the actors do, their movements\locations, and their health.

From there, hopefully the gameplay will be the same in both player's games (of course, there is always Chaos Theory, and it's likely to apply to those calculations as well...).

Due to this, I would suggest starting with just two people, testing, using a Linux comp as the server. That way the strain will not be too great to handle, and right off the bat it will be possible to do this. The other hurdle also deals with the server, but not about hardware:

1. The actual software.

This requires software, language doesn't matter, coded so it can support receiving data on both ends, and then sending the data to the other end. It must also support queries ("Is (IP) hosting?"), and a "server list" that is updated whenever someone uses the host command in their console. That will add an IP to the list, and upon being queried by another players "join (IP)" command it will search the list for the IP, and if it is available, will connect both players.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All in all, what this idea requires is this:

1. A server.
-A linux comp with Apache should do fine.
2. Software coded specifically for this.
-Must be able to send\receive data, keep an up to date server list, support queries, and handle other problems.
-At first this should be made specifically for just two people using it at a time. Later versions may support multiple people using the server.
3. A competent Lua coder
-To handle the CC scripting
4. A competent coder
-To handle the software coding

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As I said before, this entire design hinges on the idea that you can control actors completely with Lua, and that you can use Lua to send and receive data from an external server (which I am assuming is possible due to the chatroom I saw).

Now. Since you have been kind enough to read this far, you may tear apart my idea however you wish. I only even bothered saying it (after all the people I've seen get flamed) because I thought that perhaps someone might consider it.

*shrug*

Chatroom scene was made by Lord Tim

Wouldn't work, too many of CCs actions are randomized. Most obvious example I can think of is bullet arcs.

Another possibility mentioned in the IRCene topic, without all the nice features of direct control, is to use the AI commands as orders. While not quite as fast or intelligent, the AI can do pretty well for itself in terms of pathfinding, and against another AI, aiming. I'm not sure but I think Lua can set AI commands and coordinates, yes? If so, then you can forget about the movement commands and instead focus on restricting users to AI commands only. Desyncs will still happen, but it would work without being able to control the entire game via Lua.

Ah damn, that's what I meant when I said "Chaos theory". So even if two actors, using the same gun, in different games however, but the same area, firing at the same trajectory... The bullet will still arc differently?

I assumed that the cause\effect of CC's physics would allow for the precise replication of any effect, as long as you got the cause correct. Then again, wasn't that the basic idea of... ♥♥♥♥, forgot the name of it, but it was a physics belief that got owned when Quantum physics came around.

EDIT: Duh's idea is good. It would not be an "FPS" Cortex Command, but more of a "RTS" Cortex Command, and I'm sure players would be happy with even that. They could build their bases, then use commands from then on to wage war with each other.


Ooops. I wasn't sure, hence why I said (Griff?).

Would making CC turn based make any of this easier?

Yeah, if you could each build bases and then have your units set to carry out tasks for you... I could see it happening, But I owuldn't expect everyone to be satisfied when the match ended.

My name isn't even spelled Griff.

If you're going to improperly refer to someone you might as well spell the WRONG person's name right.

Also this is entirely impossible. Lua in its current form cannot be used to send the kind of data about the game you want it to. Physics would handle differently on the two computers, there's random numbers involved on both ends that would mess up games unless the entire engine was specifically designed around online multiplayer.

Well, as long as you can force one client to yeild its physics sim, and use the data from another client...you probably wouldn't have to work to hard re-writing the engine.

Yeah but the whole "one client sending its physics sim data" is you know the ENTIRE PROBLEM.

Yea, thats alot of physics info being sent over the net.

I was thinking about a way to use the area editor to split the map up into "update chunks" and watch anything that changes inside those chunks. if something changes, it sends that update to any connected clients, but only the areas where something changed. That way, you aren't sending sim data for the entire scene each update.

Guys, why the heck would it need to send the physics data? Just send and recieve the input from both players and this "NPC" guy will do what the player does on each computer.

Although one thing bothers me though. The shaking of the weapons and spreading of the bullets like on AKs for example. but then again, this can be overriden by just sending the HP and wound data of the actors and try to limit it to that. This thing might cause some "WTF HIT" or "OMFG THAT MISSED A MILE, HOWD I DIE!?" but even so, since every unit in CC is expendable I dont see much problems in this anyways.

Also one more thing: How would we handle lag?
If one player has a better rig than the other and he... lets say fires an ypsilon for kicks. And the one with the crappier computer will have trouble on catching up and the one with the better machine will be ahead of his time... so how can we avoid this? Limit the speeds and particle counts maybe? Forcing fast forward if things get too slow?


I believe its possible to make what Dvd said, but how will it all turn out gameplay wise?

We have slow-mo, why not use it? Is it possible to dynamically change that? If the guy with the faster computer will not go into slow motion at the same time as go with the crappy computer, then we synch that as well. Force them to both use the same timescale. Problem solved. So when the explosion goes off, the crappy computer begins slow-mo time, as does the good computer.

Data said that just about everything was exposed to Lua. I need to read up on how CC uses Lua, it's fairly different from the other systems I've seen, but hopefully I'll be able to come up with something for you guys.

Although you bring up an interesting point. How to handle mods? I can see a shitload of errors if players have different or edited weapons.

Do what Garry's Mod does with Lua mods then: send them when the person is joining if they don't have the mods. Then again, all those .bmp files...

mods really arent that big. you could quite plausibly compress&archive the files before sending, and then extract them on the other end. a dialog with a progress bar and some cancel would be nice aswell.
that or just limit it to vanilla cc, or make players agree on mods. if someones cheating itll be less fun, in that case: quit. im assuming there wont be ranking or anything anyway.
also if the engine would give output on what it had "decided" for its random values, those could be sent aswell, and forced into the other games sim.
what we're talking about here is basically the same concept as a trainer, but its different in that it sends values from your game to someone elses trainer, while executing/manipulating whatever it receives from the other trainer, yes?
i think another sub-milestone of actions would be to see if its possible to force the other players engine to use your random variable instead of making its own.