Collectible Card Game Headquarters

Previously in Forge we used to face situations when GUI was directly called from game classes. Luckily, after the game module was extracted this is no longer possible.

Now it's time to go further with that great divide and limit client's access to game classes. The actual state of game allows the client inputs (eg: pay mana ones) or code that still remains in GUI module to directly activate card's abilities, to change state of combat, potentially look into other players' decks and hands and even manipulate cards in those zones. Because all the data is stored in the same process, so any code may perform almost any change in every module.

When game state departs onto a remote server application, what data are the clients going to operate?
How will players pay mana or choose an ability to play then? Will there be the devmode and its cheats working?
Which part of game state has to be transferred to client? Which classes are going to hold that data?


I have some vision of how implement that, yet I would like to get to know your opinions to learn how much our ideas match and to have a chance to adjust my vision basing on your opinions.

In this future that you vision how are the following scenarios handled:

1) Human vs AI Play (in any form), do I have to be connected to the internet just to play Forge?

2) Human vs Human Play (2 players total), does one player host the remote server and the other player connect to it? Is 3+ players different?

I almost feel like it may make sense to allow the client to have some simple rules checking (everything up until actually putting a spell onto the stack), which would then get sent as a full batch "I'm casting this spell, and this is how I paid for all the costs" and similarly for declaring attackers/blockers (these are all the creatures I'm attacking with, this is the Propaganda costs I'm paying), which would then get approved/rejected.

I would think that the server generally runs with cheats/devmode disabled, but we should certainly have a way to enable it.

In general, we should try to limit what information is sent to a client to what a player can actually see, don't send the top card of the library until the card is actually being drawn, etc.

Answering to your questions:
1 - Local server and client. In 2 different applications (like Mage) or a single one (that connects to itself via TCP/IP). So, you don't have to be connected.
2 - Possible, but to prevent cheating it's better to use a dedicated server that no player can debug or edit its memory.

But these questions are too general, the what I've asked about in original post lays one layer below.
The main problem is: the game classes won't be available to client. The actual Game, Player, Zone, Stack, Card instances are all on a remote host. This is why the gui part cannot perform any rules checking or give away the whole mana payments

How is the client supposed to operate then? Which information sent over network is the sufficient minimum for the client to work?

Max, maybe you should post your ideas, since you are the one who keeps pushing for wanting to add network play and then the rest of us will have an idea of what you are expecting us to respond with.

I think a dedicated server, while nice, puts too much onus on whatever the server is, especially if it's going to have to hold threads open and respond to every little minor action.

Why couldn't each player have a local server attached to their client, these servers sync with the other peers they are playing with and can also respond to immediate rules enforcement to the local client for simple actions like starting to cast a spell and paying mana? Once a full action is completed, it would get sent across for verification, then both clients would sync on the confirmation.

If a server sends an action across to the other peer that's illegal, it would provide some type of "illegal action" that would be provided. In this two-server mode, both servers would need to be set to debug mode for illegal/dev mode actions to be accepted.

friarsol wrote:I think a dedicated server, while nice, puts too much onus on whatever the server is, especially if it's going to have to hold threads open and respond to every little minor action.

Why do you think of this as a problem?

friarsol wrote:Why couldn't each player have a local server attached to their client, these servers sync with the other peers they are playing with and can also respond to immediate rules enforcement to the local client for simple actions like starting to cast a spell and paying mana? Once a full action is completed, it would get sent across for verification, then both clients would sync on the confirmation.

If a server sends an action across to the other peer that's illegal, it would provide some type of "illegal action" that would be provided. In this two-server mode, both servers would need to be set to debug mode for illegal/dev mode actions to be accepted.

Before my arguing against this idea, would you please point at a few games that play over network this way?

friarsol wrote:Max, maybe you should post your ideas, since you are the one who keeps pushing for wanting to add network play and then the rest of us will have an idea of what you are expecting us to respond with.

The main idea is that game classes won't be accessible any more. There'll be their counterparts filled with data received over network.

It's a problem because it's a central server that can be shut down, and tracked back to a single entity, isn't that just the same as why BitTorrent better than Napster?

Am I supposed to know the history of all networking now? If the Client isn't to have any rules checking, then I'd imagine a local rules checking off on a different thread would be advantageous. I know Action RPGs often have some type of local checking on which actions are legal that way the player can get immediate responses, and when those actions return from the server they are verified whether it worked or not. Path of Exile is a game out right now that I know for sure does this.

You're the one who brought this topic up, but I see very little information of how you were thinking of doing this, which is pretty frustrating. Instead it's just me throwing out random ideas and you saying they don't work because that's not what you were thinking. That's not a brainstorming session. That's wasting my time.

No central server, one player is a host, other is a client, or dedicated server. Same system as Quake 2 had, if you played it.
Path of Exile is a top-down shooter, don't compare its data exchange methods to a turn-based game.
Ok, anyway, since noone else expressed their opinion, that means we have no objections.

What I want to make now: the client will have to use proxy classes to access cards and players and all that game data. These proxies will contain as much information as the player is allowed to know. Firstly proxies will act as wrappers around real game classes, and then be filled with data that arrived over network.

Better to make it before drdev links android client to current game classes.

You seem to have a much different definition of words than I do Max. I wouldn't call one player hosting and another player connecting in a "Dedicated server" that's just a peer to peer connection like Apprentice used. Not that it matters to this discussion, but Path of Exile is an Actin RPG like I mentioned a sentence before that, not sure where you got top-down shooter from. Lastly, me asking you questions, and then you not answering them certainly doesn't count as no objections. I'm fine with peer-to-peer, that's basically what I mentioned except one peer is the host and one peer has limited rules handling so actions could be sent in bulk.

How responsive will doing basic actions going to be? Do I have to wait for the server to respond to me for each land I tap for mana?

Well, to be fair, one player hosting a server is from a technical perspective not peer to peer: both players are connecting to a server, the server just happens to be located on the same host as one of the clients. "or dedicated server" means, as I interpret it, that the server is indeed hosted somewhere else than all the clients. That's still far from a central server, which would be a bad idea as you pointed out.

having a distributed rule engine, where all players check the rules themselves, is possible but hard, especially when tweaking an existing system that's not designed with that thought in mind. It's even harder to at the same time give every player only public information (which would be roughly equivalent to what humans do with paper magic). an additional hurdle is private information: how can you prevent a player from choosing the cards they have in their hand if the other players truly have no knowledge of the cards?

the client server architecture Max proposes is much simpler to implement, and you only have to trust the server host instead of all participating players.

by the way, my thoughts to replicating turn-based games are available here, if you're interested. when I continue working on laterna magica, my multiplayer model will be replicated servers each connecting to a few clients, i.e. you could have one server hosting the game, or one server per player, which means everybody has full information, but it helps an AI for choosing good moves, or enables players to unde before syncing with the other servers, or a mix: multiple servers hosting the game, each serving a different subset of clients.

Max mtg wrote:Better to make it before drdev links android client to current game classes.

I already have started connecting to the current game classes, at least a little bit, but if you just keep me in the loop or fix the references yourself, there should be no problem.

I'm excited to see where this goes once we get all the details sorted out.

silly freak wrote:Well, to be fair, one player hosting a server is from a technical perspective not peer to peer: both players are connecting to a server, the server just happens to be located on the same host as one of the clients. "or dedicated server" means, as I interpret it, that the server is indeed hosted somewhere else than all the clients. That's still far from a central server, which would be a bad idea as you pointed out.

I guess it doesn't have to be peer to peer. It mostly depends on how it's implemented, but yes my main point was a "dedicated server" to me is the server in my office that hosts Unreal Tournament that no client plays from. This doesn't have to be a central server for all players everywhere, but it's much closer to that than a single user hosting a match. Maybe "self-hosted server" is a better terminology?

silly freak wrote:one server per player, which means everybody has full information, but it helps an AI for choosing good moves, or enables players to unde before syncing with the other servers.

This was the point I was really trying to make. If I'm attacking with 50 creatures, do I have to click each one and wait for the server (across the internet) to respond? Or could my local end handle a limited rules interactions and then only the full batch of who I'm attacking with gets sent over? The host server would still do everything else like checking state, and appointing priority. Could my local client handle dealing with all of the cost to playing a spell, and then the whole action be sent over as a single request?

silly freak pretty well expressed my idea.
It's not a peer-to-peer, it's client server architecture. Yet, everyone may run their private server, that may be launched from desktop gui app or as a console application.

> Check every mana tapped.
- Yes, that's unavoidable. Server may give you a list of abilities you could use, you reply with index of the one you're activating.

> If I'm attacking with 50 creatures
Server sends you creatures able to attack and possible defending targets. As you select attackers on client nothing is checked besides that they belong to that list. When finished, you pass a multimap to the server (defender->[attackers_list]), then it checks them alltogether.

> Could my local client handle dealing with all of the cost to playing a spell?
It can not. Some costs include zone changes, this operation may not be delegated to client. (harder to check serverside than simple actions one-by-one, the client also will have to check game rules - more coding, will have to sync game state)

> multiple servers hosting the game, each serving a different subset of clients
Too complicated for me. I'd rather implement a simplier solution with better chances for success.