Quote:
A neonode knows the full gamestate. The number of neonodes that persist the gamestate is equal to the number of players in a game? (each player communicates through a unique neonode)

Yes a NEO node knows the entire gamestate. No if you look at our experiementation you will see that a 1:1(player:neo) ratio is ineffecient. a 5:1 is much better. So we only need one out of 5 players as NEO node.

Quote:
The game is actually "played" (game logic wise) on the neonodes, and the communication between neonodes is similar to that of an existing RTS (neonodes send each other full gamestate updates). The neonode that a player is connected to then sends down information to the peer which he is hosting.

The Neo nodes broadcasts commands from the players connected to them to the rest of the Neo nodes (region). Yes a NEO node updates the players that is connected to him.

Quote:
This model seems to incur a moderate bandwidth overhead, as if i am playing a game i expect to send commands to my neonode, as well as recieve relevant gamestate updates from my neonode. But I can also assume that I am acting as a neonode, in which case I send and recieve a more broad set of updates to the other neonodes simulating this game.

No, because in traditional P2P a player sending updates needs to send to all his peers. Say in a 8 player game a package must be sent 7 times (within a round). In our model a player sends a package 2 times within a round. We also save bandwith by having the Neo groups (regions) as small as possible.

Quote:
I'd say it's certainly a novel idea. Understanding it a bit more, the only real place I can see abuse occuring is for a neonode to send his client an incorrect view of the world, or relaying all updates to the client, giving the client a full gamestate.

Thats true collusion in that way is hard to prevent. Just like to friends looking at each others screens. We can make it hard todo by random assignment of NEO nodes and random assignment of players to NEO nodes.

Quote:
But thats a fairly small hole in the scheme of things, because there would be no way to coordinate a cheat easily. There is definately a chance of random griefing by neonodes, and because it would be random and anonymous it would be much harder to track down griefers. But I don't think socially, it would be so much of a problem. I think grifers do things mostly for the reaction, and as a neonode, you would not really hae the opportunity to witness the reaction.

Yeah we thought of that but we did not handle it specifically. Thankfully we have a CA so we can register grief players. Perhaps a Trust model can be used here?

Quote:
You may want to readdress your realtime protocol like hplus said. Disadvantaging slower players, tends to give players a bad outlook on the reliability of the game. And by funneling traffic through the neonodes, you are adding a significant amount of latency to the system. This means if you have been so unlucky to get a neonode that has a bad connection to you, or one of the other neonodes controlling your game (regardless of your connection) you can be penalized. Personally, I feel that this is much worse than bringing everyone down to the lowest common denominator. I don't want my gameplay experience to be hampered by another peer that I have no control over.

Each player has a primary and a seconary NEo Node. if the primary does not behave the secondary can take over. The player actually ships his commands twice one to primary and one to secondary. We belive this should help against "bad NEO node"

Quote:
There are ways not to slow the game down when using a turn based method like age of empires, where you send commands to execute during a future turn. the number of turns in the future to execute a command can scale with latency, so that the game does not pause or stutter, but remains fluid. commands issuing 400ms later than they were issued is probably not a big deal in an rts, as long as the player gets immediate notification from his UI. If the little guy says "yes sir!", and proceeds to move 1 second later, it is not going to impact gameplay significantly.

Thats the reason we choose RTS games and not FPS. But much of our articles are based upon MMORGP games.

Quote:
You need to understand that you have traded cheat resistance for greater latency, and bandwidth. It's important to build a system that is tolerant of latency, and is extremely playable for those with low latency (because your model has increased the likelyhood that a player will have a bad connection (by adding 2 new, unpredicatble routes into the equation).

Not to forget more players.

Quote:
I would readdress your realtime ingame protocol, and try to find a way to scale, based on latency, a turn based method similar to AOE. (This will work to offset the extra bandwith that is added by being both a player and a neonode, as a turn based network model will send less packets, and decrease the amount of header bandwith (which is a big concern in realtime models)

Thats good advice



BTW My site is down because my ISP closed my connection with a 3 day notice (due to me swicthing phonenumber)