Grains: Vegetarian Zombie Rising - Possible example MMO

General Discussion
1

A few years ago, my brother and I came up with an idea for a joke project: Grains: Vegetarian Zombie Rising

The idea is simple, you are a farmer, you have one of many square farms in an endless world. Your farm (like all others) shares an edge with a graveyard, and every night your farm is invaded by vegetarian zombies moaning “Grains… Grains…”. As a farmer, having your crops eaten is clearly a bad economic choice, so you must protect your crops (probably just corn, its nice for obstructing view).

Basically its an MMO farming FPS. No PVP (if you shoot a player, you get arrested), just PVE.

Why: Panda needs a serious MMO sample, and a nice multiplayer shooter sample, and some graphics samples. I say cram them in one game in ridiculous fashion. Horribly mismatched graphics can be part of the gag, which means we can use in fancy overkill gfx demo assets, and placeholders alike. Cube zombie eating your normal mapped, instanced animated corn, what ever.

Design:
Server:
Out of principal, I’d go for a scalable load balancing, distributed server design, written in Go and optimized for multi core operation. I’d do this because I don’t think its very hard to do for a trivial grid based game if you start the server design from that perspective, and it would be a nice example server to have around. I’d use Go because its fast, and makes concurrent designs easy. Its also really nice for servers in my opinion for some other reasons too. The server would not be panda specific in any way, and would be as generalized as practical. I’d like to make it incrementally updatable so most updates could be done without server wide downtime. Thats not work much extra effort as far as I’m concerned (I think it can be done to some extent without much work as long as the client is rather good at reconnecting seamlessly). Making the server hardware failure resistant (realtime duplication of data, combined with load-balancing to deal with a server failure) would be interesting, but defiantly not a priority.

Client:
A panda 3D application in python, with some shaders. As high end graphics will be used, but not needed, I’d like to have a good fall back system for running on really low spec (This would make a good iphone game for example). As much as I like cramming Cython into things, I think sticking to pure python would be the best choice in this case. I don’t see anything in particular that would need significant processing time which would be an issue for python. It could also run in the web player.

Process and Implementation:
I’d do this as a slow paced hobby project, hosted on GitHub and BSD licensed. I don’t have much free time, so it would be a rather long term thing unless other people wanted to do major portions of it (I’m mostly interested in the server design).

Here is an older server/client with a temp top down 2D view of the world showing the farms and graveyard layout.

Gameplay details:
You get income from your farm to buy supplies. Shotguns are fun, so you probably start with one and get unlimited free ammo for it. Later versions will allow buying upgrades. Dead zombies are good fertilizer. When offline, time on your farm begins to slow down (the slower the longer you are off line). This prevents your farm from being totally destroyed while you are gone. I think a negative interest rate would be good (your money slowly goes away if you don’t spend it, so with fixed income and no (or fixed) spending, wealth follows a logistic curve. Thus World rank can be based on either income or wealth, either of which is indicative of how much crops you get vs how much you spend. You can sell your farm and move to a new one thats uninhabited as long as its not too isolated (you have to be near, or maybe even next to someone). This lets you be with your friends while not letting people spread endlessly far apart. I’d like zombies and players alike to have lame billboarded speech bubbles over their heads. It would be fun to also have though bubbles (zombie thoughts would be a nice touch).

From a design perspective, this game is unique, can have novel stylistic charm, has action, strategy and social aspects (MMO with world ranking, ranking among friends, whatever). It can potentially run on mobil devices too. While it may be a joke design, I think it could actually be fun, and maybe even popular, while demonstrating panda’s abilities.

The game can start as trivial and be playable before purchasable items/upgrades are made available which shortens the dev time to initial launch. Even effects like weather (that would be a great gfx example), multiple crop choices, and regional crop prices based on supply could be added. Its a very expandable design.

Anyway, thats my random Panda project idea for now. I hope you enjoyed reading this. Please respond with your thoughts on the idea.

2

I had a fantastic laugh with the premise.

My commentary is on the server half. Go is a cool idea but last I heard the windows port was still incomplete.

Another option is to improve the DistributedObject server implementation. It is still missing a lot of features like persistent storage api, player authentication/authorization, distributed physics (my current bane), etc.

Or add something like Raknet or RedDwarf support.

3

Rakenet does not interest me much, but RedDwarf actually looks pretty powerful. I do know Java, but I don’t like it very much. Doing the server with RedDwarf (and thus in Java) might be a good idea. It would provide an example of using an existing and apparently scalable server. That said, most of my interest in the project is in my crazy server design, so I’m very biased when it comes to what would be good to have as far as a server goes.

Existing third party server options aside, I have a rather interesting design for for a server I would kinda like to try:
General purpose hierarchal load balancing: Use the same code to load balance multiple processes in one server application as to load balance multiple servers. This allows easy switching between single and multi server hosting. As the load balancer could balance remote load balancers, its basically a tree structure that can be of arbitrary depth (one server up to multiple clusters. Most extreme practical case is probably 3 levels, cluster chooser, machine chooser, process chooser).

For data synchronization, my idea is to have a general purpose multi protocol tree. The idea is that data is synced/served in a tree structure where each node can have its own sync/storage protocol.

Server side, different servers server up various nodes of the tree which include references to how to get the sub nodes (protocol+address usually). An example node could be a batch of all players in a zone. It could have 2 sub nodes that are moving players, about which UDP position updates are streamed, and stationary players, about which TCP events for any changes are sent. The collation process for sets of data to send to each player will vary somewhat depending on the protocols. Internally it will be done by tree walkers and/or multiplexed channels of some sort. Note that sub nodes may be stored locally, or may refer to a completely separate server (A zone tree server for example would have sub nodes that are other zone tree servers, or actual zone servers, which may or may not be in the same server, process or application)

Clients are shipped with a root node (as a static file included with the game).This root static data would contain nodes such a p3d files that would get downloaded (p3d files are a type of node in the tree). It can also contain info like server public keys and such needed for authentication, and a URL for where to find a master server file (downloaded files are another type of node) that lists all the server addresses for finding any other servers, and is signed with the private key that matches the public key shipped with the root node.

Then clients can thus traverse the tree, and based on some client side rules (some of which may be server enforced) acquire and maintain (update/sync) the parts of the tree they need.

Here is a nice picture about the tree client side. This is the client side tree that the client builds and walks to acquire all the state information it needs.

This design allows easy adding and changing of syncing protocols. If you decide you want to make infrequently updated terrain info cached gzipped on the server, and set to who ever requests it, and send out events when it changes, just add a node type/protocol for it on the client and server. P3D files and patch files are a valid protocol, and so are things like delta move compression, or even potentially something like the lockstep model. Memory based syncing is another neat trick that could be optionally used as a protocol. (Perhaps take the old/key frame state, xor with the new state, and gzip it).

It also allows things like dynamically re-batching objects into groups with different protocols. For example, you could push all of the idle characters in a zone into a node that uses TCP and sends events all listeners for changes to its contents, and all moving ones into a node that streams position updates over UDP. The same information exists (on the client and on the server) either way, but arbitrarily re-batching across different protocols and even servers just comes down to moving data between nodes.

The idea is to allow arbitrary protocols to be added in the future (and if using the tree for patches and such, perhaps even at runtime!), as well as dynamic swapping of objects between sync protocols, batches and servers seamlessly. It also means you can have high performance custom protocols for specific stuff without losing generality of the architecture.

Misc Notes:
Some of the tree’s client side implementation can use persistent data stores (such as downloaded and patched p3d files). If you cache the master server list file, then even if any of the servers go down (such as the server list server), you can still connect to and use what ever is still running.

Moving nodes between different protocols server-side can can also correspond to changing their representation, particularly as far as persistence. Idle objects (players or otherwise) could re-batched into idle groups that don’t stream updates. They could also be moved from ram to a database. Actively moving ones that stream key frames (absolute positions) and deltas could for example, update their persistent copy in the database every keyframe.

As for authentication, I’ve done that for games before (I wrote a mmo server that allowed account creation and login, though account creation was not very resistant to man in the middle attacks and should have used ssl. Login was a pretty robust challenge response system). It was particularly my experience with coding it that made me want to write a game server in Go. It would be easier to do in idiomatic Go (than any language I know), and would get benefits such as being multi core, dealing with traffic overloads nicely without extra work.

4

I like the idea, its pretty funny. I would love to help you on this project

5

I’m glad you like it. Is there any particular aspect of it you would like to work on?

I’ve put up a source repository here: https://github.com/Craig-Macomber/Grains–Vegetarian-Zombie-Rising
Currently I the server (implemented in Go) has a basic http server and TCP connection server. The client (in python) uses twisted, and can fetch the server list from the server’s http server, and use it to connect to the TCP server and receive a message.

Data streaming, updating/syncing with optional compression is mostly implemented client side, but the connection to the actual networking (the twisted protocol) and some message splitting/error checking is still needed.

The server is just a trivial cobbled together test for the client at the moment. I’ll work on making it actually reflect the proper design.

Lots to do, but I need to work on other projects for a while.

6

I think this game is also good to play but the graphics have similar on other old family computer games but different in concept.