Where Should The Logic Go? (client/server)

Where should the logic for the game go? Client or server? What logic should go where?

In my view of the game, I would put all of the game logic in the server, and simply have the client as a "dumb" gui. This helps keep the client from getting overly bloated, and gives you a fairly clear separation of logic. C++ is great at drawing things, not so much (in my experience) as drawing things and keeping track of state/logic. In single-player mode, the client could simply start up a server on localhost, and the player wouldn't know the difference. In addition to simplifying things, it also has the advantage of making adding multiplayer easier, which is nice :).

Also, the title is not a pun on the go language that would be lovely to write the server in :). Provided, of course, that the dev team is willing to give up (do we have support?) for single-player or server hosting on windows in the interim while the windows port of go matures.

I actually like this Quake-ish approach. It's Model-View-Coding at its best ^^.

The biggest drawback to the whole thing is that we have to rewrite great portions of the game. I have to admit that the separation of logic and representation is quite bad in some places of my code, to say the least. Now that I think of it, rewriting certain portions would be a pretty good idea, actually.

For the languages I would suggest that we use a combination of C++ and Lua scripts (and go if it provides sound Lua bindings). Lua is an extremely well-known scripting language with many non-programmer users (game modders, etc.). If we kept things like AI code for the inhabitants and drawing & logic of items away from C++ and in Lua, the game would be easily extendible by literally anyone. And it would speed up development since you don't have to recompile things. This leaves the core game engine and systems to C++, and the gameplay logic stuff to scripting.

I think the best time to do something like this is sooner rather than later, as long as there is not too much game logic written and we're only working on the classic version. But if we're actually going to do this, we need some serious concept work on what the engine does, how it is organized, what the AI/item scripts do and how they are organized, and how everything fits into the client for drawing.

What if we keep client/server together in one program, with something like a --server switch to start without SDL and GUI in server mode? This would simplify local gaming, since one could connect to the server using some virtual connection inside the application.

What do you guys think?

Well, my motivation in choosing go for the server is simple:

Super fast compile times (compared to, say, C++).
Reasonably fast at runtime (slower than C++ right now, but performance-critical components could be written in C/C++).
Awesome multithreading (if we write the server in C++, it'll likely end up single-threaded because of the difficulties otherwise).
Builtin support (from the standard library) for tcp, udp, and http connections.
Cool type system that seems to work better for most things (in my experience). Basically like C, but with syntactic sugar to call methods for types.
No header files (this is awesome)
Better package dependency management system (import "github.com/someuser/somepackage" is awesome!)

Of course, there's some drawbacks as well:

Another thing to install in order to compile the source.
Doesn't work properly on windows yet, although that will likely be fixed by the time we actually get this working.
Relatively immature, there might be bugs in the runtime (although i've yet to encounter one in my year of go coding), or, more likely, features or libraries that are incomplete or missing altogether.
Route finding and simulation code currently written in C++ would have to be rewritten in go (or bridged using cgo, but rewriting would probably be easier and more maintainable long-run).

I would be weary of trying to do all of the "game logic" in LUA. OpenTower ultimately failed because putting all of the game logic in python and maintaining the bridge was quite difficult. By all means, we should design it in such a way that adding these things in later in one form or another of scripting language would be possible, but write all the game logic in the same language as the server itself- go or c++- for now. Another thing to move to the list of features for the deluxe version if we ever want to finish the classic version.

Keeping the client and server together might increase the tendency to "cheat", and would make actual multiplayer harder to test (since actually testing the client in single-player wouldn't guarantee that it was working properly). Furthermore, it would make it so that compiling the server requires all of the 3D and GUI dependencies that the client does, which is just ugly. Getting around this with a compile-time flag to disable the 3D/GUI functionality would be possible, but at that point you basically have two different programs anyway. The only advantage I can see to this is that it would make single-player ever-so-slightly easier to implement, since you would just have to call startServer() rather than SomeLib::RunProgram("C:/Program Files/OpenSkyScraper/bin/server --localonly --max-players=1"). Using a virtual connection is probably a bad idea, since it's unlikely to be any lower-latency (or not significantly lower-latency) than dialing localhost. In any case, if the latency on localhost is an issue, multiplayer gaming is going to be a serious issue, so we'll be having to do some serious optimizations at that point anyway.

I don't think that the «another thing to install» is going to be an issue, since at least on Mac OS X and Windows users are used to downloading precompiled binaries which already have this stuff statically linked, and Linux users tend to be used to installing stuff :)
I'm absolutely not familiar with go, so I'd actually be glad to get to know it through this project. Rewriting the existing game logic (which essentially isn't too much) sounds like a sound idea, just for the sake of saving any bridging acrobatics.
I see your point on writing to separate programs, which actually seems to be the better way of doing things.

One thing I'm not sure about how to do is the UI interaction which requires heavy interaction with the game state, especially constructing things. To get the most crisp UI experience one would have to implement all the construction validation twice, in go and in C++. I'm not sure how much the responsiveness suffers if you send construction requests from the client to the server and check whether a construction is possible on the server.

I think the overall question here is: How dumb do you want the client to be? From my perspective, we have to find some balance point between moving all logic to the server and having all implemented twice. Any thoughs?

go is a cool language, although it has a bit of a learning curve (much smaller than the learning curve for C++, mind you). See http://golang.org/doc/go_for_cpp_programmers.html for a quick intro into the differences. If you're on linux or mac, installing it is fairly easy, although the updates can be a bit of a pain (immature language and all).

For things which the user would require immediate feedback, I would implement the validation twice. For placing rooms, floors, elevators, and the like, it's fairly trivial to implement twice. If the server rejects the room placement, remove the room, possibly somehow indicating to the user that it has been removed. Generally the latency here should be under a couple seconds at absolute top, which would be unacceptable and frustrating if the user was trying to place a room (WHY ISN'T IT PLACING???), but small enough that they are likely still looking at the same area of the map when the potential rejection would occur. However, the only time this would occur is when lag was large and two people were placing rooms in the same area, or if the player is strapped for cash in cooperative mode, with two players trying to make use of very limited funds.

The client should be "smart" in that it should contain internal representations (classes, structs, or whathaveyou) of all of the same objects that the server has (at least in the area currently being observed). However, it should be "dumb" in that none of these objects change in any way without user or server interaction.

I don't see a lot of potential issue with duplication, although perhaps i'm just not fully considering the different possibilities. I suppose most of the validation routines would have to be implemented twice, but as far as I can think right now, that only comprises two or so routines (room validation and elevator validation). What other duplication were you seeing as becoming an issue?

Thanks for the link, I'll look into it so I can be of some insignificant help at the beginning of the server development.

So eventually we have to implement the entire game properly in the server in go, and implement certain functionality again in the client in a recessive manner, which tries to predict the servers response based on its own knowledge of the game state, but eventually takes the server's decision as the relevant result of an action.

What you are suggesting sounds like the classic model-view coding paradigm to me. Having a fully fledged model of the data in the server, and a copy containing only animation-specific stuff in the client (animation and the like). Sounds pretty good to me. Only updating items that are currently visible on the client machine is actually a pretty good idea, this would even allow for some server-initiated animations (hotel and office people moving around).

If you have any thoughts on how to represent the items and stuff in the server (the model) in go, make a new wiki page for it. I'm quite familiar with MVC, but I don't know to which extent it applies to go.

fabianschuiki / OpenSkyscraper

Where Should The Logic Go? (client/server) #18