findenet.cmake, move gui stuff into client/ and make server/
create the clients and the server
add release and release/linux dir, make startup.sh script for loading

the libraries that we will place here, on startup
now using google protobuf for story binary data.

we absolutely need this to serialize the binary data for packet transfer
and also for binary (world data and other data) data storage.

basically, it means the binary data scales to any platform, and it even
has versioning..which seems like it'd be super helpful for world saves.

it's actually a very well done lib, and just involves using protoc to
compile your .pb definition files into a C++ class and header, which
then yields getter setters and even a debug string (for seeing if the data
you stored is actually good, as opposed to the fact that it's just binary
making things difficult).
managed to pack and int and a protobuf message in our packet and extract

now lets try packing 2 protobuf messages in a packet
serialization of multiple bufs nearly in place
aaand de/serial working, next commits will be making it generic
argh, small snapshot for when it works partially

I *think* it's just a matter of resetting the stream feed ptr..assuming
the data itself doesn't get hosed.

i'm having issues with the streams, since i pass them in without copying
(which is what i'd want, obviously).

but deserializePacketType will then
eat everything and deserialize will have nothing left to read.
fixed, apparently you need to call clear() (confusingly), and then

call seekp to see the pointer. the first part i didn't have ;)
use the enum identifiers to identify packet contents
lot of refactoring taking place, splitting stuff into server or client

(aka moving a lot out of World and Game, making them more generic)
propagate game-> client refactorings, now compiles again
world no longer a singleton, we only used it for one thing anyways
make the client not attempt a connection on ctor, that'll have to be

when a user hits the client's gui

the game now runs (only technically a client right now), and shows
the gui and renders that and some debug text. world is not created, nor
is a server
for now, we will ignore the dedicated server scenario

(it's pretty trivial to add, simply make Game only create the server
based on arguments to binary), and so the Client technically creates
the server if he chooses to host and play (SP or host MP), but of course
only when the user chooses to either play SP or host and play an MP
server will it do so. So we won't make assumptions based on that (validity
of m_server indicates this).

In the event that the client and the server will exist, the client will
handle the event loop of the server too.

athe tricky part is going to be handling collision and stuff through
the World...and also splitting out the rendering, so the spritesheetmanager
is not called if in server-only mode. luckily that was already modularized
so that part shouldn't be too bad. mostly the collision i need to think
about, and corresponding update code
disallow ESC hiding/showing main menu when we have no peer
on singleplayer click, immediately create the world, a server and connect

to it. presently everything is still done client side, think right now
i'm going to get initial client->server handshaking done (which, of course
is pointless for clientside but it doesn't matter since they're just local
sockets), then work on network chat
attempt to send initial client data

turns out i just exposed a nasty failure in my packet serialization.
if i send a 0 as an integer anywhere in my packet, it craps out entirely.

betting it's because i call google::protobuf::Message::SerializeToString
and the ParseFromString..the examples i saw used that though to do just
this..weird.
excellent, packet deserialization works

what i had to do was construct a stringstream and string from the raw data,
not a .c_str() representation which of course fails when there's a null byte
in there..
server deserializes properly, remove a lot of testing code