Carl Worth [Thu, 18 Jun 2020 16:04:29 +0000 (09:04 -0700)]
Set judging_start_time_ms before anyone actually does any judging
The judging phase is different than answering in that judging is
optional. So we can't rely on clients actually sending a "judging"
notification, (since they might just submit without having clicked on
any of the words). So instead, we set the start time for the judging
phase as soon as we enter that phase.
Carl Worth [Thu, 18 Jun 2020 15:11:00 +0000 (08:11 -0700)]
Fix bug attempting to set "answering_idle" state
So annoying to have no static compiler checks for assigning to a
mistyped property like this.
Anyway, the impact of the bug here would have been fairly minimal: If
a user reloaded during idle, they would not have gotten the "Move On"
button like expected.
Carl Worth [Thu, 18 Jun 2020 14:59:17 +0000 (07:59 -0700)]
Extend PHASE_IDLE_TIMEOUT from 10 seconds to 30 seconds
The 10 second value was always known to be aggressively short. I had
this in there with such a short value because we didn't have the
feature to auto-advance a phase after every single player was in, nor
to auto-idle the phase after the players-waiting list is emptied. So
without those features implemented, players were forced to wait for
the idle timeout in situations where there was nothing to wait for. So
to keep that from being too annoying, I had this parameter dialed
down.
But now that those two missing features were implemented in recent
commits, we take this timeout up to a higher value. With this,
hopefully the Move On button won't appear too soon so that people
inadvertently skip an active player, but instead only appears once
people really are stuck waiting.
Carl Worth [Thu, 18 Jun 2020 14:57:27 +0000 (07:57 -0700)]
Add named parameters for the two idle timer controls
These controls may need some tweaking, so it's better to have some
defined names for them along with some carefully specified semantics.
Also, we plan to extend the current idle detection from the answering
phased to the judging phase as well, so it will be nice to be able to
reuse these parameters there too.
Carl Worth [Thu, 18 Jun 2020 14:49:16 +0000 (07:49 -0700)]
Broadcast "answering-idle" as soon as the waiting list becomes empty
That is, as long as the answering phase has been going on for a "while".
This avoids an awkward pause when all active players are done
answering, everybody wants to move on, but the "Move On" button hasn't
appeared yet, (because clients haven't been told yet that the
answering phase is idle).
Carl Worth [Fri, 26 Jun 2020 14:33:04 +0000 (07:33 -0700)]
Include still-answering players when ruling on end-asnwering majority
The test suite exposed a logical bug here. Imagine a 10-player game
where two players have submitted and 8 are still answering. Those two
players should not have the ability to move on without the answers
from the larger set of players still waiting. But that's what the old
logic would have allowed here.
In this commit we count up all players who have already submitted
answers as well as all players who have at least indicated that they
are answering in order to decide how many we need for a majority.
Note: This does mean that if something happens, (like a major network
outage), that prevents a majority of the players from being able to
submit their answers, the game cannot proceed with the minority who
succesfully submitted. I think I'm OK with that. (If the minority
really wants to proceed in a case as dramatic as that then it would be
reasonable for them to start a new game.)
With this commit the test suite is now fully passing again, (for the
first time since the recent addition of new tests).
Carl Worth [Fri, 26 Jun 2020 14:31:43 +0000 (07:31 -0700)]
Consistently use null value to reset the ambiguities list
The constructor has always been setting ambiguities to null, but on
game reset it was getting set to 0 instead. The test suite noticed
this inconsistency, which we fix here to make a recently-added test
start passing.
Carl Worth [Fri, 26 Jun 2020 14:26:05 +0000 (07:26 -0700)]
Expand test suite to include testing of auto-phase advancement
The previous commit makes it so that when all involved players are
ready to move on, (such as, everyone has submitted their answers), the
game automatically advances to the next phase.
This breaks some existing tests, which had been expecting the game to
wait for everyone to vote to advance (the old, clunky behavior).
In this commit, we fix the test suite to expect the auto advancing in
the first ame (while also adding a check to ensure it doesn't
auto-advance until the last player is ready).
We also add a second game where auto advancing doesn't happen, (one
player is never ready) but a majority of the remaining players vote to
advance without them.
These tests do exhibit a couple of bugs in the current implementation,
(so some failures are expected here). These failures will be fixed in
the immediately following commits.
Carl Worth [Sun, 14 Jun 2020 23:42:33 +0000 (16:42 -0700)]
Implement an idle event for when nobody has been typing for a while
During the answering phase, if no player has been active, (that is, by
submitting an "answering" event), for 30 seconds, then submit an
"answering-idle" event to all players.
Carl Worth [Sun, 14 Jun 2020 21:57:10 +0000 (14:57 -0700)]
Remove player names from answering and judging when they submit
Without this fix, reloading the "still waiting" view would make player
names that had previously submitted erroneously appear in the "still
waiting" list once again.
Carl Worth [Sun, 14 Jun 2020 21:55:12 +0000 (14:55 -0700)]
Fix game-state object to include players judging and answering
Previously, these were always appearing as empty objects in the JSON
results that we streamed from the server in the game-state object
because JSON.stringify doesn't natively know how to serialize a Set
object.
Here, we provide a replacer function that serializes a Set object as
an array.
Carl Worth [Sun, 14 Jun 2020 18:18:18 +0000 (11:18 -0700)]
Add "/answering" and "/judging" endpoints
These are set up so that clients can report when they are doing any
answering or judging. The server then passes this along so that other
clients can be aware of what's going on.
Carl Worth [Sun, 14 Jun 2020 17:18:12 +0000 (10:18 -0700)]
Rename "/judging" endpoint to "/judged"
This is to make room for a new "/judging" endpoint to capture the
notification that a player is in the process of performing judging,
(that they've started clicking on some of the words in the list).
This commit also fixes the test suite to track this change.
Note: "judged" isn't really a perfect name here. By analogy with
"answer" what we want here is a noun, which would imply "judgment" but
that suggests an entirely different meaning to my ears. So, for now,
we're going with the slightly inconsistent "judged".
Carl Worth [Sun, 14 Jun 2020 16:37:27 +0000 (09:37 -0700)]
Tweak game-ID generation toward more frequently used letters
I'd noticed recently that game IDs seemed to have more Qs, Zs, and Js
than it felt like they should. In fact, all letters were being given
an equal probability of appearing, but that doesn't match our
expectation that some letters should be "rare".
In this commit we tweak the selection of letters toward more "common"
letters. This should hopefully give game ID strings that are slightly
more "friendly" looking in general.
The set of available game ID values isn't reduced here (at least
because of the above, but it is reduced because of part of what is
described below), but when many game IDs are allocated it can now take
longer for the random-selection algorithm to find an available one.
We also switch from using 'B' and 'F'/'X' to instead using 'P' and
'S', again favoring letters that English speakers expect to be
"common".
This actually fixes a bug which I hadn't noticed before, in that the
code has always been replacing a '5' in the input with 'S' but doing
that after 'S' was replaced with 'F', so any input with '5' would not
be mapped as intended. Now an input of '5' will work in the place of
'S'.
Carl Worth [Thu, 25 Jun 2020 16:08:53 +0000 (09:08 -0700)]
Adapt test suite to add explicit voting to advance phases
As of the previous commit, it's now required for players to explicit
vote to advance from one phase to the next. That commit broke the test
suite which didn't have this voting added.
In this commit, we fix the test suite by adding that voting (and
ensuring the state game state transitions from before to after the
vote).
Carl Worth [Sat, 13 Jun 2020 21:38:28 +0000 (14:38 -0700)]
Accept votes to advance game at /end-answers and /end-judging endpoints
The previous logic was far too strict, where the game would advance
only after every registered player had submitted. That made it
possible for the game to become totally stuck with just a single
player that left the game, (or even that accidentally reloaded the
game in a way that lost their previous session).
Now there are endpoints for players to vote that they would like to
advance past either the "answers" or "judging" phases of the game, and
the game will advance as soon as a majority of the registered players
have voted.
This does still make it possible for the game to get stuck if a
sufficient number of players stop playing, but it's at least less
likely to happen. And we've got plans to improve this situation
further soon as well.
Carl Worth [Fri, 12 Jun 2020 17:24:41 +0000 (10:24 -0700)]
Force all submitted judging words to lowercase before mapping
This fixes the bug revealed in the previous commit so that the test
suite now passes once again.
The server now doesn't apy attention to the capitalization that a
client happens to use when providing a judging submission, but will
treat things as equivalent regardless of case differences.
Carl Worth [Fri, 12 Jun 2020 17:18:00 +0000 (10:18 -0700)]
test: Stress the implementation a bit with a mixed-case judging report
With this change to the test, we now have a user submitting a judging
report with "grains of sand" in a list after having received "Grains
of Sand" from the server.
The server currently misscores in this case, so this test case now
fails, (revealing a bug in the server).
Carl Worth [Fri, 12 Jun 2020 17:10:06 +0000 (10:10 -0700)]
Fix bug with incorrect scoring based on capitalization
As exposed in the previous commit which extended testing.
After we construct what we call "word maps", (where a group of words
are hased to by each word in the group individually), we collapse them
down to just the array of word groups themselves. This step was being
carried out by looking for the mapping to the word group where the
mapped word matched the first word in the list.
However, if that first word happened to differ in case from the
mapping word (which was already made canonically lowercase) then the
word group wouldn't be included in the final array and all submissions
of words from that group would incorrectly be scored as singletons.
The fix for this is to simply force the word being compared to as in
this commit.
Carl Worth [Fri, 12 Jun 2020 16:56:35 +0000 (09:56 -0700)]
test: Empathy: Extend test to submit judging results with proper capitalization
In commit abea9915939bd7f5b6e70f12d724f19dc6694ec9 we extended the
test suite to cover the case of players submitting words with mixed
capitalization and we ensured that the server didn't send out any
duplicate words for judging, (that it ignored case when determining
which words were unique).
However, in that commit we still had the players returning the results
of their judging in all lowercase. This is not a good test since
actual clients will return words exactly as they received them.
Here we improve the test by submitting judging results with the same
capitalization that the server used when sending out the
ambiguities. And we also expect that same capitalization to appear in
the final word list.
However, this test currently fails in the final word list _and_ also
fails in the scoring. So this test is exposing a bug that currently
exists in the server.
Carl Worth [Fri, 12 Jun 2020 02:49:12 +0000 (19:49 -0700)]
test: Expand empathy test case to include mixed capitalization
When actually playing a live game recently, we noticed it normalized
different capitalization when sending words out to be judged, but
didn't normalize it when scoring. So we add a test case for this.
It currently fails here, (showing the bug). When the bug is fixed this
test should start passing without needing any change to the test
itself.
Carl Worth [Thu, 11 Jun 2020 23:41:31 +0000 (16:41 -0700)]
test: Exercise the situation coded for in the previous commit
Specifically, by changing bob's answer of "surfers" to "sand" he
should now receive one less point than before. That's because
"surfers" was worth one point (since only bob submitted it), but now
"sand" is worth 0. And _that's_ because bob is already getting full
credit of 3 points from "sands" for matching everybody, so he doesn't
deserve any additional credit for putting down an additional answer
that the group decided is equivalent to one he already has.
Carl Worth [Thu, 11 Jun 2020 23:37:43 +0000 (16:37 -0700)]
Empathy: Use word groups to assign scores to players, not their lists
Previously, we were marching through each players list of words and
looking each word up in the word groups to find a score for that
word. This worked in general, but failed in a specific case:
If a player had two different words that were considered by the group
to be equivalent, that player received the score for that word
twice. To avoid giving a palyer in this situation points that the
group clearly didn't consider they deserved, we instead iterative over
the worud groups themselves to assign points out to players.
This means that when a player ends up having two (or more) words that
end up being equivalent, (based on the team consensus when judging),
all but one of those words will be worth nothing.
Carl Worth [Thu, 11 Jun 2020 22:57:24 +0000 (15:57 -0700)]
Empathy: Change /judging endpoint to expect a top-level word_groups property
It's probably wise, (for future-proofing our APIs), if the server
looks for an explicitly-named property rather than just slurping up
the whole request body.
This also keeps the code more consistent with other endpoints, (which
is going to be particularly important as I start refactoring things to
remove some duplicated code).
Carl Worth [Thu, 11 Jun 2020 22:52:28 +0000 (15:52 -0700)]
Empathy: test: Including final score in testing
And expand the answers a bit to eliminate duplicate scores between
alice and bob. This test verifies that the game is properly scored
according to the word groups that the players submitted.
Carl Worth [Thu, 11 Jun 2020 22:26:17 +0000 (15:26 -0700)]
Empathy: Initial implementation of scoring that considers players' judging
I'm slowly learning more about JavaScript, (such as using
Objects.entries instead of open-coding it, using Set(), etc.), which
is helping as I write progressively more complex code.
But I don't feel _really_ confident that I've written this code in the
best form possible.
Carl Worth [Thu, 11 Jun 2020 22:23:32 +0000 (15:23 -0700)]
Don't throw out punctuation when "canonizing" words
This caused a pretty disastrous failure of the game when the team
chose "Programming languages"; people submitted C, C++, and C#; and
the word list they were presented for voting had only C# in it.
Carl Worth [Thu, 11 Jun 2020 19:11:45 +0000 (12:11 -0700)]
test: Add initial testing for the Empathy game
Two general techniques that are introduced here that will be useful
for testing of other games:
* Registration of multiple user and events sent from each (see
multiple cookies and a player-cookie parameter for many empathy_*
functions)
* Fishing events out of the event stream in response to client
requests (see curl_get_event)
This testing gets as far as is currently implemented in the server:
Multiple player join, a category is submitted and voted one, the game
starts, all players submit answers, players receive words to judge,
and players submit word groups to capture the results of their
judging.
What's not yet tested is the next phase that's also not implemented
yet: The server using the submitted word groups to affect the scoring.
Carl Worth [Thu, 11 Jun 2020 14:52:26 +0000 (07:52 -0700)]
empathy: Fix /prompts endpoint to return the ID of the new prompt
It never ceases to amaze me the bugs that can only be found when
writing tests. (My manual client testing missed this bug because they
never looked for this ID, but instead picked up the ID from the
broadcast to all clients when a new prompt is added.)
Carl Worth [Wed, 10 Jun 2020 14:55:16 +0000 (07:55 -0700)]
Empathy: Prune the list of proposed categories on game reset
Obviously, we drop the prompt that we just played. We also drop any
prompts that got no votes at all, (giving players a way to prune
prompts from the list from one round to the next).
Carl Worth [Wed, 10 Jun 2020 14:25:13 +0000 (07:25 -0700)]
Fix the /reset endpoint
The fix here was pretty simple. I'd only missed this because I had
forgotten to add an explicit setting of state.scores to null in the
constructor, (so then forgot to also do the same in reset()).
Carl Worth [Wed, 10 Jun 2020 04:28:23 +0000 (21:28 -0700)]
Add scoring once all players have submitted
And a not-quite-yet-fully-functional /reset, (or maybe it works but
the client is broken). This was a 90-minute flurry of coding, so I
haven't looked closely yet at where the bugs are.
Carl Worth [Wed, 10 Jun 2020 03:01:56 +0000 (20:01 -0700)]
empathy: Tell clients how many players have responded
That's probably not quite the information the client _really_ wants,
(since it probably wants to at least show the names of those who
haven't submitted yet), but it at least gives the client _some_
information that's not static.
Carl Worth [Wed, 10 Jun 2020 02:41:23 +0000 (19:41 -0700)]
Empathy: Add a new /answer route to accept answers from a user
This is the bare minimum, simply storing the answers. Going forward
we'll want to expand this to inform players when another player has
submitted, etc.
Carl Worth [Wed, 10 Jun 2020 02:38:08 +0000 (19:38 -0700)]
Fix buggy regular expression
I mean, it's unlikely that anyone would ever submit a URL with a
square bracket just before the prompt number, so this probably never
would have mattered all that much.
Carl Worth [Wed, 10 Jun 2020 01:14:29 +0000 (18:14 -0700)]
Use spread syntax rather than fill(nill) in generate_id
We don't actually need the array filled with null values specifically,
we just need something that map() will act on (since it doesn't act on
the empty entries we get from Array(4)). Using [...Array(4)] gives us
an array of undefined values which does the trick, and is a bit more
compact than .fill(null).
Of course, I blow away any savings in compactness with the giant
comment I've added here!
Carl Worth [Tue, 9 Jun 2020 15:10:11 +0000 (08:10 -0700)]
Don't let a new prompt get started when another is active
This avoids any negative side effect from a race condition where two
clients request a game to start within a short time window of each
other. When one prompt is active, the server will ignore any further
incoming requests to start a new prompt, (until the active one is
completed).
Carl Worth [Tue, 9 Jun 2020 15:06:37 +0000 (08:06 -0700)]
Empathy: Add support for starting the actual game
When a request is received at "/start" to start a particular prompt,
the server responds by broadcasting a "start" event to all clients
telling them to start the game.
The prompt is also set as the active prompt in the game state so that
if any new client joins while a prompt is active they will become
aware of that.
Carl Worth [Tue, 9 Jun 2020 15:03:58 +0000 (08:03 -0700)]
empathy: Better separation of concerns between routes and game class
In this commit we make the route handlers much simpler: Their job is
to parse data from the received request and provide a response to the
client, (such as an appropriate status code), but otherwise, the meat
of the functionality is provided by methods on the Empathy class).
This separation should lead to more maintainable code as the
implementations on both sides are smaller and more focused on a single
job.
Carl Worth [Mon, 8 Jun 2020 13:59:43 +0000 (06:59 -0700)]
Empathy: Add routes to receive prompts and votes on prompts
The received votes are added to the prompt objects themselves, so we
don't need to send anything beyond the prompts, and the votes will
just ride along "for free". Also, because prompts are a part of the
Empathy game's "state" property, they will always be sent as part of
the "game-state" event sent when a new client joins, so we don't need
any explicit code in the Empathy class to take care of that either.
Carl Worth [Mon, 8 Jun 2020 13:57:22 +0000 (06:57 -0700)]
Add a new "broadcast_event_object" method to accept an obejct not a string
I probably want this to be the default, (replacing broadcast_event
entirely, or perhaps renaming it to broadcast_event_string if there
are any users that do need to stick around).
With cases like this, I do wish I was using a type safe language to
avoid the confusion that comes with "Does this function want an object
or a string representation of that object?".
Carl Worth [Sat, 6 Jun 2020 16:34:29 +0000 (09:34 -0700)]
Add 'trust proxy' option since we trust our proxy
This fixes the URL that the server gives to clients in the game-info
event so that it will be a working URL (https://lmno.games/WXYZ)
instead of a URL from the node point of view (http://localhost/WXYZ)
which won't do any good for users to share.
Carl Worth [Sat, 6 Jun 2020 15:51:59 +0000 (08:51 -0700)]
Initial implementation of Scribe
This is not at all sophisticated yet. The biggest shortcoming is that
it doesn't yet reject moves that don't follow the movement
restrictions (where a player must play in the super-grid corresponding
to their last moves mini-grid).
Carl Worth [Sat, 6 Jun 2020 15:47:27 +0000 (08:47 -0700)]
Properly JSON-stingify move before broadcasting it
With the Tic Tac Toe game, this bug was hidden, (since the move data
is just an integer and there's no difference in strignifying that or
not). But an upcoming game (Scribe) uses a pair of integers, and
there's a lot of difference between "1,2" and "[1,2]" since only the
latter is proper JSON.
Carl Worth [Sat, 6 Jun 2020 12:58:53 +0000 (05:58 -0700)]
Allow for games to opt in to allow "Guest" users
Here we allow a new object to the game metadata called "options" and a
new optional property in that called "allow_guest".
If this option is present and true, then the choose-nickname form does
not require the user to enter a name, but will use "Guest" by default.
This is convenient in a 2-player game, for example, where the two
players are the only ones present so there's no ambiguity over who is
who.
But this could be very confusing for a party game like Empires.
That is why, in this commit, tictactoe.js sets allow_guest to true
while empires.js does not.
Also, now that it's even more likely for there to be name collisions,
(such as multiple people entering the game as "Guest"), when adding a
player we not automatically append a numeric suffix to their name to
make it unique within the game. (Note: The name in the session is left
untouched so if a user with the same session joins a different game
and the session name is unique there, it won't get any suffix.)
Carl Worth [Sat, 6 Jun 2020 12:54:35 +0000 (05:54 -0700)]
empires: Rename add_player to register_player
We still haven't yet ported the Empires implementation to play nicely
with all of the new functionality in the base Game class. In
particular, Game now has a base "add_player" method with different
semantics than the older "add_player" method in Empires.
To avoid Empires.add_player from being inadvertently called, we rename
it here to register_player.
This fixes, for the moment, a failure when trying to create a new
Empires game of:
TypeError: player.remove_connection is not a function
Carl Worth [Sat, 6 Jun 2020 00:07:10 +0000 (17:07 -0700)]
Assign new players to the first team with no players
But only if the game has already started, (since with an unstarted
game, all players are intentionally unassigned so that any player can
go first).
If there is no team that has no players, the new player will be
unassigned, (and will instead be a spectator until they join a team).
This logic is designed so that a game in which the precise number of
people were invited to play, (most notabl, a two-player game), these
players will be automatically assigned to teams as soon as one player
makes a move, (regardless of whether the players joined the game
before or after that move).
Carl Worth [Fri, 5 Jun 2020 23:55:55 +0000 (16:55 -0700)]
Switch team property from being a string to being an object
This should be cleaner as it avoids a bunch of bare string literals
all around the place that happen to match. Now, the player's team
property is a pointer into the game's array of teams. And for the case
when a player is not on a team, the game file maintains a "no_game"
sentinel object (with an empty-string name).
Carl Worth [Fri, 5 Jun 2020 23:18:57 +0000 (16:18 -0700)]
game: Allow either player to play the first move
When players originally join the game they do not belong on any
team. And while we could require the players to divide themselves up
and join separate teams, it's much easier for them if they aren't
required to coordinate on that.
So, with this commit we allow any player, (not yet in a team), to make
the first move. At that point, we assign that player the appropriate
team for playing first, and assign at least one player (if there are
others in the game) to each successive team value in the order they
originally joined the game.
This means that in the common case of a 2-player game, if both players
are in the game, and one player makes a move, then the two players
will be assigned to separate teams.
Carl Worth [Fri, 5 Jun 2020 23:15:47 +0000 (16:15 -0700)]
game: Store players in both an array _and_ a session-indexed object
We originally wrote the code storing palyers in an array, and then we
changed to using an object (indexed by session ID) for convenience in
looking up players by the session ID value.
Here, we add the array back so that we can access players either way:
1. Indexing into players_by_session to lookup a player by session ID
2. Iterating over players when we want to access players in order
The second usage, (in order), will be convenient for a subsequent
commit where we assign teams out to players in the order that they
joined the game.
Carl Worth [Fri, 5 Jun 2020 20:56:45 +0000 (13:56 -0700)]
Move some checks from TicTacToe.add_move to Game.add_move
Specifically, the checks for whether the player who submitted a move
belongs on a team and belongs to the team that has the next move.
These checks belong in the generic Game class so that future games
won't have to maintain their own copies of these implementations.
Previously, we were using the presence of the "add_move" property on a
game class to determine whether to add the "/move" route. Now that we
are adding add_move to the base class, we have to check specifically
whether the child class has its own add_move (with
hasOwnProperty('add_move')) to know whether the "/move" route should
be added.
Carl Worth [Fri, 5 Jun 2020 20:54:28 +0000 (13:54 -0700)]
Rename "next_player" property to "team_to_play"
The game object already has two distinct notions of players and
teams. And this property will only be compared to team values, not
player values, so this name is more accurate and less confusing.
Carl Worth [Fri, 5 Jun 2020 13:57:04 +0000 (06:57 -0700)]
game: Index players directly by session ID
Previously we were just storing the players in an unordered array, and
doing an O(n) walk through the array to find a player with a session
ID that matched the ID of interest.
Instead, we now index directly with the session ID which is already
guaranteed yo be unique and is convenient in JavaScript where we can
use the session ID as a property name, and even use a convenient
subscript syntax for that.
With this change we don't even need to store the session_id property
on the player since it is now not used at all.
Carl Worth [Fri, 5 Jun 2020 13:36:41 +0000 (06:36 -0700)]
game/tictactoe: Expand player to include a team property
The existing /player endpoint is expanded to allow a player to choose
which team to join. The team must be either an empty string, (to leave
all teams and be just a spectator), or must be one of the defined
teams of the current game. As expected, TicTacToe defines its teams as
"X" and "O".
Carl Worth [Fri, 5 Jun 2020 12:41:40 +0000 (05:41 -0700)]
Add a new player-info event to the stream
This event informs the player what their ID and their name is. It's
significant to tell them their own name because it may be provided
from the server session (obtained by a cookie from the client).
This commit includes a test case which uses the existing /profile
endpoint to set a name, and then verifies that that name is returned
in the player-info event.
Carl Worth [Fri, 5 Jun 2020 12:31:15 +0000 (05:31 -0700)]
game: Rename Game.clients to Game.players, combining multiple connections
Previously we were simply storing an array of "clients", one for every
request to the /events endpoint.
Now, the array of "players" is similar, but there is only one item in
the array for each unique session ID, but where each one may have
multiple "connections", (for a case where a player connects multiple
times with the same session ID).
In this commit we're not making large changes to the Empires class to
take advantage of this new functionality, (for example, it already has
unique session identification as part of its "spectators"
notion). Instead, we make a minimal change Empires so that it doesn't
step on the base "players" property.
In the future, we'll be able to port Empires forward to use this
base-class functionality and in the process delete some code from the
Empires class.
Carl Worth [Fri, 5 Jun 2020 01:17:48 +0000 (18:17 -0700)]
game: Send a game-info event when a client connects
This is in the generic Game class so all games will get this
functionality. This will allow clients to be able to display the
game's ID and URL so players can invite friends.
Carl Worth [Wed, 3 Jun 2020 22:20:12 +0000 (15:20 -0700)]
Add message string to the return value of add_move
Now, instead of just returning a Boolean indicating whether the move
was legal, add_move returns an object with both the Boolean "legal"
property as well as a string "message" indicating what made the move
illegal.
Carl Worth [Mon, 1 Jun 2020 21:32:50 +0000 (14:32 -0700)]
tictactoe: Reword the comment describing the add_move method
The former wording was just a little vague and potentially
ambiguous. It's now more clear about when a true value is returned,
and when false is returned.
Carl Worth [Mon, 1 Jun 2020 21:29:53 +0000 (14:29 -0700)]
Store only the the .Game property when importing a game engine
Previously, we were referencing engine.Game separately from
engine.router, etc. But now that engine.Game is the only property
that's part of the interface, let's dereference that immediately at
the time of require() so that later on we can just use "engine" in
place of "engine.Game".
Carl Worth [Mon, 1 Jun 2020 21:24:29 +0000 (14:24 -0700)]
Add some documentation about the Game import interface
Having some notes here will simplify the task of making a new Game by
copying an existing game, (since the game logic itself may obscure
some of the details of this interface).
Carl Worth [Mon, 1 Jun 2020 21:16:04 +0000 (14:16 -0700)]
Generalize the handling of the /move request
Implementing it at the "lmno" level instead of in "tictactoe".
This means that future game implementations that involve clients
sending moves to the server (which, is obviously a common thing), can
simply implement an "add_move" method in the Game class at not need to
implement the route handler piece of things.
Carl Worth [Mon, 1 Jun 2020 18:35:43 +0000 (11:35 -0700)]
Rename identifiers from square to move
There is no functional change here, but the code makes more sense this
way given the code change of the previous commit. The body property is
now named .move not .square so use identifiers that match.
Carl Worth [Mon, 1 Jun 2020 14:51:59 +0000 (07:51 -0700)]
Give the "/events" route a common implementation
At this point, both the empires and the tictactoe implementation have
an identical implementation of the "/events" route so we push this up
to the lmno.js file.
Carl Worth [Mon, 1 Jun 2020 14:44:37 +0000 (07:44 -0700)]
Standardize transmission of game "state" when a client joins
With this addition to the Game class, the TicTacToe class drops its
custom implementation of the handle_events method.
Similarly, future game implementations can simply have a "state"
property and not need to do anything further for new clients to be
provided with the current state when they join.
Carl Worth [Mon, 1 Jun 2020 14:34:33 +0000 (07:34 -0700)]
tictactoe: Move all state-related properties into a new "state" property
Consolidating this into a single property is a step toward
standardizing game classes to treat state consistently, (which should
let us reduce some code duplication).
Carl Worth [Mon, 1 Jun 2020 14:30:06 +0000 (07:30 -0700)]
tictactoe: Actually toggle between X and O as the current player
It is kind of hilarious that I hadn't even noticed that up to now
every move committed to the board was an "X". I hadn't noticed this
because the server state is currently only used to determine if a new
move is legal, (in that the board is unoccupied). The code currently
doesn't test for a win, for example.
And meanwhile, the client has been tracking toggling X and O on its
own just fine.
But this will certainly be cleaner going forward, and is strictly
necessary before we serve an event that exposes the entire board
state.
Carl Worth [Mon, 1 Jun 2020 01:04:38 +0000 (18:04 -0700)]
Drop the meta property from the game exports object.
The game's Game class is already a property on the exports object, and
that Game class already has this meta data. So there's no need to copy
it to the exports object as well.
Not to mention, no code is actually referencing it from here.