I use this work for my game icons: GitHub - MWDelaney/Netrunner-Icon-Font: Icon font that replicates the symbols used in Android Netrunner by Fantasy Flight Games. . I recommend it for your need.
3 Likes
Cool to see progress. What are your plans for back-end/logic? I’m thinking of switching to that direction next time I have a chance, because I’ve spent far too long on toying with the UI also. I would be developing a multi-service server written for node.js. It would accept websocket connections. The services would include:
- Lobbies
- Chat (rooms)
- Games (rooms)
Obviously the most complicated is the game rooms. The hardest thing for me to wrap my head around is the ‘secrecy’ of cards. Each player’s browser can only know about the cards they should know about. Face-down cards, cards in decks, and hands. Those need to be known, as far as locations and counts, but the card ids/text cant be sent to the client until the card is installed/played/rezzed.
P.S. I’ve use those icon fonts also… they work pretty well.
1 Like
Damn, this looks so sleek and nice
Hope you guys make a minimal web-engine like in these mock-ups!
Definitely.
That’s not that hard. If you consider the cards as entities. An entity has an id and everything else (name, types, locations, rezzed, counters…) is metadata attached to that entity. Then you can send the list of all the entities to both players so they can have the counts and you only have to filter (using a whitelist for example) the metadata you send for each players (for locations, status, …).
I think the “Server Circles” should probably be rounded corner rectangles, roughly the same width as the circles but with much less height.
Agreed that its not rocket science or anything 
Just tricky to get right. You’ll need two ids for the cards, the actual id of the card (the netrunner db id) will be known on the server only, whereas the game-id (temporarily assigned) can be known on client and server.
2 Likes
An important question is: will you trust the client? If the client sends a request to expose a card, will you verify the validity of the request? It can be very hard to implement. Exposing could be the result of an Event or an ability. How do you know it’s legit?
1 Like
Well, the server obviously has to keep track of all that’s going on anyway, so unless there’s an option I’m neglecting, as long as each request to expose comes bundled with a reason why (i.e. the source of the expose), you can always verify that source against the current game state… and then do adjustments as needed (Infiltration no longer in hand and -1 click, Raymond trashed, Silhouette actually ran HQ and didn’t expose a card earlier that same turn, etc).
Thus, even if you were to convince the client to send a request it shouldn’t, it would either get discarded as illegal because it didn’t make sense in the current game state (“But, dear client, you don’t have an Infiltration to play in your hand!”), or it would actually become a legitimate play server-side (“Sure you can expose that, let me just subtract 1 click and the card you just played from your hand!”)… at the worst leading to a desync between the client and the server, which would get rectified momentarily at the next sync opportunity.
Or am I missing something?
Never! That’s rule #1 of building a multiplayer/networked game 
Here’s how I’m planning it will work. Despite being a turn-by-turn game, the online experience will be real-time. That is, the game will require two players to be connected to the server via websocket (full duplex connection) and will only communicate via this channel. First security level is that no other client can connect to that game.
Then, there is the issue of one player trying to cheat by sending an invalid action (remember that the server sends the players their currently available actions). That issue is solved by validating the action on the server and making sure it’s a valid one.
Ok, so whenever you compute the game state, you also compute all possible actions, according to the game state. Then any action taken by a player must meet the list of possible actions. You then compute the new game state after the action resolves, and the new list of possible actions.
2 Likes
there is no need to do security checks if both players are informed about each others actions. each api call can mimic real game like action. i can see when my opponents peeks at a card in real life game. same here. and yea, filtering out hidden info is easy for game server.
Though it would be nice to stop the possibility of cheating (for peace-of-mind), the main reason that everything needs to be run through the server (and verified) is to keep sane game state. Since this is a browser we’re talking about, it can crash, accidentally get closed, refresh, socket connection drops etc. You have to assume everything is terrible 
So, when someone reloads the game you need to restore a legal game state so play can continue.
In addition, as @prozz points out, we need to inform each gamer of every action the server has processed, most importantly to facilitate bug reports
2 Likes
Well, a game can only support one runner and one corp, and the user ids for those can’t change mid-game. Ideally the game supports ‘observers’.
spectators can spoil game and allow cheating if they will be allowed to look at hands, browse hidden card in archives etc. so spectators is good idea, but there have to be limit of information they are getting. again: easy enough to do
full spectating mode is doable too, but in world of vm’s and all possibilties around - it wont happen due to cheating being way too easy.
post game replay can replace spectating mode for those who need badly to review how game was played etc.
All of that is true, but only if you don’t trust the spectator(s). Usually, spectator mode is used in competition where a judge launches a game an invite both players in the game.
1 Like
for me spectator was an observer, like in online go you can watch games by grandmasters in real time. idea with judges being spectators is good one.
You gentlemen are confusing two things:
- spectator mode, where the client is only allowed access to information available to BOTH players (i.e. that which is publicly visible)
- overseer mode, where the client is allowed access to any information available to EITHER player (i.e. he sees all except stuff hidden from both players)
Both of them should be in, ideally (and one really can’t replace the other).
1 Like
Just being curious: how is the overseer mode useful when you have a spectator mode?
I’d say spectator mode should always be allowed since no harm can come from it, whereas both participants should have to agree for overseer mode to be enabled, to help mitigate asshattery.
good points @PeekaySK. confusion came from a fact, that most of the games i played online doesn’t contain hidden information, be it quake, chess or go