Online-Features like Newsletter, Archievements, Leaderboards, Mod-DB

[MKelm]

The playtomic api allows to use different online features via html5: http://playtomic.org/api/html5.html from https://github.com/playtomic/gameapi-html5

The API offers functions like:

• newsletter subscriptions
• archievements (save/load/list and activity stream)
• leaderboards (different types of scores for players)
• mod-db for simple mods (by using the player levels feature)

Additionally: The API allows to set the game language by geoIP/country code.

[MKelm]

Or, maybe the levels feature can be used to share save games, if the save games are not too complex, I have asked Ben Lowry about that. More about save games here https://github.com/MKelm/mct/issues/24

[MKelm]

Good news from Ben:

The MongoDB stuff the playerlevels is built on can store up to 16 megabytes per entry so the size isn't really a huge consideration, you can also compress it and store it that way to streamline the volume of data although if you're using Heroku + MongoHQ they are both on the same physical private network (Amazon Web Services) which isn't a huge consideration.

And I found a javascript compression tool for strings/JSON and JS objects: http://floydpink.github.io/lzwCompress.js

[MKelm]

I have some concerns if an open solution is good for such a feature, because I do not know any solution yet, how to validate generated content against manipulation.

Maybe we can allow some special types of user generated content only which does not have direct connections to in game mechanics, or we have to develop a sever middle ware, e.g. in php which validates some ingame data, but that is not secure at all, because as long as we have a layer with JavaScript logic which handles the data transfer, the data can easily be manipulated.

Maybe we need something like punkbuster for node.js by developing an own module if it is possible to access values in the memory directly to validate memory snapshots to combine a validation meta data result with a secret key of the user to revalidate the meta data with the key located to the user on the server.

[MKelm]

Or we can write our own client / server application by using the net module from node-webkit, that makes something like a p2p concept to (re-)distributing contents and real multiplayer features possible ...

[jackery4444]

Honestly, I think your second suggestion is making it more difficult that it needs to be. For multiplayer I think the simplest and, in my opinion best, solution is to use a webserver and communicate with it via Ajax. Data could be continuously sent from both players to the webserver to be stored in an SQL database and then at the end of the turn the webserver compares and syncs the data to be sent back to the two players.

[MKelm]

Ajax and a Webserver (HTTP) have a high overload, compared to a protocol like TCP it is very slow ... I researched for a chat solution some time ago, and some sources advised from ajax and recommended the sockets of node.js, because they do not have the overload, it depends on the amount of data, if we get a small footprint of communication data the ajax option might be playable, ...

[MKelm]

If the game keeps it's time concept, the heavy calculations and data amounts occur while turn / quarter transition, that might be ok, if the players want to wait longer ... but the data handling looks complex for me currently ...

--- it is not enough to send the data to a server and load it from there after a turn, the data (market) has to be calculated for the next quarter, so the data need something like a dependencies check and logic to split data regions, so that both clients get packages to calculate, and if they have broken dependencies, they have to contact the other client, a server is more a bottleneck for such an approach ... but the amount of cross-connections might be higher, because a large set of calculations depend on random / probability values and they can not be the same on both clients, that needs more commication ...

The implementation of a TCP communication looks not more complicated than an ajax implementation, in fact the TCP implementation is much easier, because you do not need any middleware, and the client/server events for sockets are quite the same: http://www.hacksparrow.com/tcp-socket-programming-in-node-js.html << looks very easy!

But the direct connect features are an early approach only, and it might be a to big effort to concentrate on an additional gameplay concept, we have sandbox and scenarios already ....

First I want to concentrate on light features for alpha 5 next year, like a leaderboard and some features to trade user generated content, that can be done with playtomic or a simple db connector on a webserver.

[MKelm]

I have developed a solution to validate the game version correctly, I use the solution for the surveys, to detect which version the participant refers to -> https://github.com/mctteam/mct/issues/20#issuecomment-21988866

That makes it possible to enable the light online features for official versions only. But with tricks every player can manipulate the client server communication, so it is not 100% save, and the database is editable with the node-webkit tools easily ...

But more validation checks are too much effort for such sub-features ... in my opinion.

[MKelm]

I made a speed comparison for fun between HTTP and TCP in node-webkit.

The result/example has been published in the node-webkit news channel on IndieDB.

In short: TCP might be (28,535+ 0,465 * n) faster than HTTP, "n" is the amount of parallel PVP connections. E.g. with 1000 parallel PVP connections the HTTP delay might be ~494x higher.

More realistic example: The HTTP transfer needs a timer delay e.g. of 10 ms to check for new server data, then TCP might be (49,534 + 0,466 * n) faster. E.g. with 1000 parallel PVP connections the HTTP delay might be ~516x higher.