40. ◯☓ゲーム – 今のままだとチートが可能
Bob (1)
Amazon
DynamoDB
Bob (2)
Bob (3)
Update:
Turn : Alice
Top-Left : X
Update:
Turn : Alice
Mid : X
State : STARTED,
Turn : Bob,
Top-Right : O
Update:
Turn : Alice
Low-Right : X
41. ◯☓ゲーム – 今のままだとチートが可能
Bob (1)
Amazon
DynamoDB
Bob (2)
Bob (3)
Update:
Turn : Alice
Top-Left : X
Update:
Turn : Alice
Mid : X
State : STARTED,
Turn : Alice,
Top-Right : O,
Top-Left : X,
Mid: X,
Low-Right: X
Update:
Turn : Alice
Low-Right : X
43. 修正版◯☓ゲーム
Bob (1)
Amazon
DynamoDB
Bob (2)
Bob (3)
Update:
Turn : Alice
Top-Left : X
Expect:
Turn : Bob
Top-Left : null
State : STARTED,
Turn : Bob,
Top-Right : O
Update:
Turn : Alice
Mid : X
Expect:
Turn : Bob
Mid : null
Update:
Turn : Alice
Low-Right : X
Expect:
Turn : Bob
Low-Right : null
44. 修正版◯☓ゲーム
Bob (1)
Amazon
DynamoDB
Bob (2)
Bob (3)
State : STARTED,
Turn : Bob,
Top-Right : O
Update:
Turn : Alice
Top-Left : X
Expect:
Turn : Bob
Top-Left : null
Update:
Turn : Alice
Low-Right : X
Expect:
Turn : Bob
Low-Right : null
Update:
Turn : Alice
Mid : X
Expect:
Turn : Bob
Mid : null
45. 修正版◯☓ゲーム
Bob (1)
Amazon
DynamoDB
Bob (2)
Bob (3)
State : STARTED,
Turn : Alice,
Top-Right : O,
Top-Left : X
Update:
Turn : Alice
Top-Left : X
Expect:
Turn : Bob
Top-Left : null
Update:
Turn : Alice
Mid : X
Expect:
Turn : Bob
Mid : null
Update:
Turn : Alice
Low-Right : X
Expect:
Turn : Bob
Low-Right : null
58. FPSのリアルタイム分析
PUT "kills" {"game_id":"e4b5","map":"Boston","killer":38,"victim":39,"coord":"274,591,48"}
PUT "kills" {"game_id":"e4b5","map":"Boston","killer":13,"victim":27,"coord":"101,206,35"}
PUT "kills" {"game_id":"e4b5","map":"Boston","killer":38,"victim":39,"coord":"165,609,17"}
PUT "kills" {"game_id":"e4b5","map":"Boston","killer":6,"victim":29,"coord":"120,422,26"}
PUT "kills" {"game_id":"30a4","map":"Los Angeles","killer":34,"victim":18,"coord":"163,677,18"}
PUT "kills" {"game_id":"30a4","map":"Los Angeles","killer":20,"victim":37,"coord":"71,473,20"}
PUT "kills" {"game_id":"30a4","map":"Los Angeles","killer":21,"victim":19,"coord":"332,381,17"}
PUT "kills" {"game_id":"30a4","map":"Los Angeles","killer":0,"victim":10,"coord":"14,108,25"}
PUT "kills" {"game_id":"6ebd","map":"Seattle","killer":32,"victim":18,"coord":"13,685,32"}
PUT "kills" {"game_id":"6ebd","map":"Seattle","killer":7,"victim":14,"coord":"16,233,16"}
PUT "kills" {"game_id":"6ebd","map":"Seattle","killer":27,"victim":19,"coord":"16,498,29"}
PUT "kills" {"game_id":"6ebd","map":"Seattle","killer":1,"victim":38,"coord":"138,732,21"}
We have two players in a round of tic-tac toe. The item storing the data for this particular game of tic tac toe is here stored in DynamoDB.
This is a match between Alice and Bob, and we’re going to have Alice go first.
We can see with this move that Bob is not very good at this game. By playing that, Alice can guarantee a win by playing in the lower-left.
Let’s say Bob realizes that he not good at this game, and wants to come up with some other way to win.
Based on the API calls we’ve sketched out, this would work and Bob would win, or crash the game.
Here all of those will be merged together. UpdateItem lets you pick specific attributes in an item to update, leaving all the rest of the attributes alone.
PutItem on the other hand replaces the whole item, so then it would have been last write wins. That opens another can of worms around being able to “undo” moves, but that’s a different issue that we’ll fix in the same way.
Apply the write only if the values in the item are still what the request expected them to be.
9-10 min
But, only one of those writes will arrive first. Writes to each item are serialized by DynamoDB.
Introduce Redshift Product
Typical data we see developers gathering about the player includes session length, telemetry data, in game data like how long to the first purchase etc, basically any information that will tell you where the game is doing well versus where it is not.
This data tends to be unstructured and so developers often deploy a NoSQL solution to store that data. They will later use a batch based sort job to cleanse the data and move it into a relational database of some sort, likely a DataWareHouse, for analysis.
Many Game Developers use AWS’s NoSQL offering DynamoDB which can handle very high volumes of read and writes and is highly durable. And as always you can install and manage your own NoSQL offering like MongoDB, Cassandra, Couchbase, etc too.
Typical data we see developers gathering about the player includes session length, telemetry data, in game data like how long to the first purchase etc, basically any information that will tell you where the game is doing well versus where it is not.
This data tends to be unstructured and so developers often deploy a NoSQL solution to store that data. They will later use a batch based sort job to cleanse the data and move it into a relational database of some sort, likely a DataWareHouse, for analysis.
Many Game Developers use AWS’s NoSQL offering DynamoDB which can handle very high volumes of read and writes and is highly durable. And as always you can install and manage your own NoSQL offering like MongoDB, Cassandra, Couchbase, etc too.
Typical data we see developers gathering about the player includes session length, telemetry data, in game data like how long to the first purchase etc, basically any information that will tell you where the game is doing well versus where it is not.
This data tends to be unstructured and so developers often deploy a NoSQL solution to store that data. They will later use a batch based sort job to cleanse the data and move it into a relational database of some sort, likely a DataWareHouse, for analysis.
Many Game Developers use AWS’s NoSQL offering DynamoDB which can handle very high volumes of read and writes and is highly durable. And as always you can install and manage your own NoSQL offering like MongoDB, Cassandra, Couchbase, etc too.
Alternative to Kinesis: Kafka
Still good solution – managing is non-trivial
