Widgets dont get destroyed until the network says so. Network gives edit and placement commands to the ships. Key events followed by the exact position of the ships at the time determine where the bullets are. In this mode, bullets dont do anything. A retro key hit function will be needed. All dohickeys will need to have a life limit in order for new players to join. Dohickeys created before a player spawned deal no damage?
We need to define all the events that could happen in the game. Multiplayer will be lacking features until those features have events.


PlayerA->ControlPacketA->MasterServer
PlayerB->ControlPacketB->MasterServer

MasterServer->ControlPacketA+ControlPacketB+MasterServerPacket->PlayerA
MasterServer->ControlPacketA+ControlPacketB+MasterServerPacket->PlayerB

Player Packets

Events

N KeyPresses 

MasterServer Packets

• DestroyWidget(Ship,X,Y)

Loose, undoable design of the session

Define an object
Define an object interface: An object can have multiple interfaces. For example During gameplay a ship will have a script interface which can Activate. During edit it will have an edit ship interface.

Players Cause events in 
CEditShipMode->CEditShip->CShip
CPlayGameMode->CSync->CScript(owned by player)->CPlayingShip(This part was skipped)->CShip
CRespawnMode->CRespawnControlSet->Session.Player.LoadCachedShip
CRespawnMode->CRespawnControlSet->Session.Respawn

Define objects and operations that can be performed on the objects.
A special undo class could hold Operations/Counter Operations
Examples of Objects that Operations can be performed on.
CSceneGraph{
	Add(GraphNode)
	Delete(GraphNode)
}

Players can only retroactivly move their char if they didnt affect any physical positions in the move. They must be able to snap to their new position without causing a collision. If they did, the server will make them snap to new position.  The client will physicly keep track of both models.
From the servers perspective:Server finds a retro request, server checks if object moved anything since then. If no, Server snaps object to new position, if this does not cause a collision, The change is made official.

Physics

Cundoable{
	AddEvent(Event,EventUndo)
}

CRespawnControlSet: public CEventGraph{
	Action LoadCachedShip();
	Action Respawn(Cached Ship);
};

potential physics implementation{
	Add(Body);
	Delete(Body);
	Step(); //Non undoable.
	
	if add(Body) was called before a step and it is found later that it needs to be undone. The object is deleted and any objects that collided with it request an update position.
	//The only way to undo a step is to have the master server reposition the objects that were affected by the object in previous steps
}

I need to come up with a way to create unique ID numbers based on the ID of the parent. Suedorandom?

Dohickies on the client computer are just for show.
When a dohickey destroyes a ship part. The server sends the signal that it will be destroyed in this amount of time.
Dohickies can pass though semidestroyed shipsquares but ships cant.

//Events involving physical changes in the physics engine are delayed to help prevent bulk simulation disasters. Your player's shipthrust is the only thing that happens instantly.
Players cant manipulate any physical objects, they can only make requests

//It appears that a branch occures(Dependancy) when an action in the main game happens 
Shipgame Event Graph{
	//Player has the ability to ExitGame() and thats all
	Load Level{
		Bind CRespawnControlSet to player{
			*LoadCachedShip(){//Player action
			  *Respawn(){
				Bind ControlSet to Player();//Runs a script binding players keys to actions
				Create Player Ship1{//This event has a #, it also Creates an object ID
				
					*KeyPressed('Up'){
						Activate Player Ship 1{(Widget #2)
						  Gun #1 TurnedOn(){
							Create Bullet{While bullets can cause drastic changes in gameplay, they have no dependancies}//Bullets can retroactivly fix their physical position
						  }
						  Gun #2 TurnedOn(){
							Create Bullet //It is important that bullet creation does not affect the physics
						  }
						  Gun #3 TurnedOn(){
							Create Bullet
						  }
						}
						Activate Player Ship 1{ (Widget #1){
							CocoLauncher TurnedOn(){						
							}
						}
					}
					*SessionManager->AddSHip(COconut){//Delayed Event to Create physical Object(Coconut) // The delay is to ensure that other players on the network receive the event
		
					}
					*SessionManager->DestroyWidget();
					*SessionManager->DestroyPlayersControlSet();*Not undoable(Nothing the session manager says is)
				}
			  }
			 
			}
		}
				
			}
		}
		Create Player Ship2
	}
}

Widgets and Dohickies now perform different actions based on if its used  in the real MasterSession or
the client sessions. All master session actions are delayed. (and not undoable?)
CocoanutLauncher{
	TurnedOnMaster{
		CocoLaunchSound();
		CreateACocoIn(X amount of time)
	}
	TurnedOnClient{
		Nothing!!!
	}
}



CMessageStream
CEventManager
CShipgameSessionManager is the interface that THE GAME uses.
CShipgameSessionManager: public Cundoable{
	An action 

	virtual MessageMap(MessageID, *DataSize, *Data)
	
	Activate(TriggerEvent, WidgitID): Creates a branch to hold all the add(Ships) that are 
dependant on this
	Deactivate(TriggerEvent, WigitID)

	Add(TriggerEvent, CachedShipID)
	Delete(ShipID)

	Add(Dohickey) <- This should not be here? Only widgets can add dohickies?
	Delete(Dohickey)

	LoadCachedShip();

	CData CachedShips;
	Serialize(CStream *Stream)
	
}

Client Master Session will receive "what really happened" events. It will go back though the undo 
list and Add/Delete undoable items. In the shipgame 
Even the master session might undo changes to allow a player to retroactivly perform an action



CShipgameMasterSession{
	Move(Ship)
}
CEditShip