nitzel / pb_mp Goto Github PK

• Line
• Square
• Relative - that would be cool!
• Circle (every circle is directed in every direction...)

When a client sends a moving ship to a new location the client will see the ship stutter because of the network delay:

• For RTT/2 the ship continues straight on.
• The packet arrives at the server. The server changes the ships direction and broadcasts that change.
• Clients: For RTT/2 the ship travels in the old direction. Server: For RTT/2 the ship travels in the new direction.
• Packet with new location and direction arrives at the clients. Their location is now up to RTT * velocity off from where the ship should be - and the ship jumps.

Possible solutions:

• For the client issueing the command we could improve the stuttering by sending the ship locally to location + RTT/2*velocity + RTT/2*expected_veloctiy_from_server so that it'll arrive at the location that the server broadcasts when the broadcast arrives at t=RTT.
• The server could attach a timestamp of now + max(client1_RTT, client2_RTT, ...)/2 to the command and trigger the move of the ship when that time is reached. The clients do the same. That'll probably lead to lag experience by the command issueing client as it'll take at least RTT before the ship changes direction. In the current scenario the command is only issued with a delay of RTT/2.

A little menu on the clients screen to update a selected planet or build some ships there if he got enough money

Right now it works like this:

• Complete Sync when connecting
• Sending updates only (money, planets, changed ships, dead ships, new shots)

If there is any information lost then the system easily gets out of sync, so there should be a continuous synchronization of the ship-list. This would also allow a better control of the amount of data sent.
If we update 5000 ships every second (changed first, and if there are no more changed to be updated, fill the rest with ships that stayed the same) we have a constant throughput and mistakes will be corrected within seconds. The amount of ships to be updated over time can also be adjusted to the maximal possible throughput of the internet connection.

You could also consider it as a ring-buffer that is continuously transmitted.

There are a lot of parameters that should come from a configurable .ini file (and maybe even be broadcasted through the network from the server to the clients, so that everyone agrees on the games' settings). Some of them are currently #defines in inc.hpp.

Select [1,2]
Ship 1 gets killed
lots of ships spawn, of it is 1
Rightclick some where
Ship 1 and 2 are selected and moved, as opposed to just 2

vec2 needs some operator overloads make code look clearer!

• * multiply with scalar
• / divide by scalar
• + add vec2
• - subtract vec2
  scalar:= int or float
• implement overloads
• replace code with overloaded operators

When drawing a selection box on the right side of the map that goes out over the window of the game it's possible that mTree is accessed at an invalid index. Should be possible to reduce selection to less than treeW and treeH.

To scroll you have to move your mouse to the border of the window. Then the map will start scrolling.
If you are currently selecting units, there'll be a box from the start of your selection (where the mouse down occured on the map) to the current position of the mouse. If the mouse isn't moved, it's virtual position on the map isn't updated and thus the box isn't rendered correctly.

how could i miss that?

When sending a lot of ships in random-circle-formation several times to the same place, ships get ported to a place outside the map. the TREE counts them as if they were in TREE(0,0).

Maybe that's because of sin/cos combined with random and then normalization (dividing by length).

There may be some problems coming up I did not think a lot about before:

• Datatype sizes on different operating systems (eg size_t is on Mac 8, on windows 4 bytes)
• Byte-order/Endianness. htonl, ntohl, htons, ntohs. If that is necessary, I will need to restructure quite a bit.
  • maybe extend the structs by methods converting them to networkbyte order and vice versa
  • a method converting everything to network/host byte order ntoh(T & x); hton(T & y);

The client needs a way to send ships in different formations.
To fulfill this issue, the following formations shall be accessible:

• Circle, with random positions in there.
  • Size changeable
• Square, positions dependent on order in selection-array
  • Size changeable (depending and distance to next ship, minimum distance necesary!)
• Line, positions dependent on order in selection-array
  • Size changeable (depending and distance to next ship, minimum distance necesary!)
• move relative. Ships keep the distance to the other selected ships
  • first find middle of all ships (sum xy/n) and then move relative

A minimap for the client, showing its planets and ships.
If there are selected ships/planets, show them, too.