Scrounge World Post #5

Alright folks, time for a foray into the server side of our app.

So Zach has been the one creating the server side framework (in Haskell for those of you just skimming) with only myself as a sounding board for rubber ducking.  And while I love game logic and am great with the overall structuring,  he has create the framework almost completely by himself.

That being said the framework is missing the game logic itself, so it really is just the empty shell.  This might sound kind of fishy but it actually aligns perfectly with our original project goal(s).   Our original idea was to create an RTS engine not dissimilar to the Spring RTS project.  Where the Spring RTS project is not a client/server model and has tons of game logic that it comes with (because you host the engine) our project is designed to be a shell that you create your own mods for and configure with your own code.

aaaaaand Zach just stole my keyboard.

Hey this is Zach. I'm working on the server portion of our client/server model RTS engine. The server handles game logic, streams graphical information to clients, and handles client commands. I've completed 90% of the networking code for receiving and transmitting data in our own binary format. I've been working heavily on pathfinding and started on a line of sight algorithm.

The plan for this engine is to be highly modifiable by anyone who wants to make an RTS game. I've designed it so "modders" can upload (nearly) arbitrary Haskell code and run it on the server. We will be implementing our own "mod" just like anybody else would to showcase the engine.

aaaaaaand I'm back.

As Zach mentioned we are going to be using our own binary format for sending game-state data.  This is because we are sending "tile/map" data to the clients in a piecemeal fashion.  I.e. the client only receives data for the tiles and units that that player has discovered.  This will make hacking the game much harder because no client has access to information they shouldn't for their given game-state.  The only information players have on the client side is graphics.  Everything the players see is just a dummy/slave to the streaming info from the server.  Additionally, because the players can only send requests to the server to change game-state, we will get to decide what a valid request looks like from the client.

When we create our "version" of our engine we will be using the "mod" interface just like anybody else.  This is partly because we think it's cool and partly because we want to make sure we have an intuitive system for modding in place.

Modders will be able to define pretty much whatever they want.  So far the only functionality a "unit" or "entity" comes with is x,y,z coordinates.  Modders will need to define from whether or not to even have resources, buildings, avatars, etc...  We do have the frame work for containing all of these ADTs but there definition and in most cases even creation is up to the Modder.

Again, thanks for reading,
-Clay Francisco (and today Zach Kamerling)