An unchanging encryption key is not going to be of much help. One of the main things you are trying to prevent with packet encryption is hackers gaining private information and prevent them from spoofing messages. With a single encryption system all a hacker would need to do is sample the packet sent when he did a particular action (without needing to know what the contents actually meant), and then have a program spoof that packet on command (this is how Soldat was hacked, someone wrote a program that detected shoot messages and duplicated them, making all weapons rapid fire).

The better approach, even if your encryption is trivial (such as a basic XOR) is to have a constantly changing key. In the best situation you would determine an initial key (hopefully without having to ask for it, which could be done by generating the key from the servers name or other unique value known to both parties) and then change it each time a message is sent (using predicatable random numbers for instance). Of course you are likely using UPD, and so you can't be guaranteed that all packets will reach their destination or in what order.

To work around UPD you could use this system:

Each message contains all the information needed to decrypt it. While this may seem bad at first, it can actually be very good at preventing a hacker from poisioning or reading packets without understanding exactly how your whole system works (most hackers are trying to understand a very small part of your system and exploit it).

One example would be to have a packet structure like so:
  • Random key needed to decrypt message. The key itself is encrypted using the length of the message.
    Message
    Random amount of padding, designed to make all packets fall within the same size range (so that you can't tell what the packet is for based on size)

In this manner no two packets are alike, requiring the hacker to understand your whole program rather than just the part he is after. To increase security each packet should contain within the message section (which is encrypted) a packet number. This packet number is unique to each packet sent, so if the server recieves more than one packet with the same number it will be rejected (this prevents packet sampling and spoofing)

I've got to go now, but I'll come back later and post some more ideas. If you read this in the mean time give me some feedback and maybe some details of what kind of game it is (or more accuately what information the client has and what information the server has, and what needs to be passed back and forth)