more readme updates

Author: zigster64

README.md

@@ -55,6 +55,16 @@ Once logged in, you will see (in real time) who we are waiting on, and watch as
 
 Once everyone has logged in, the board is presented, and the game begins !
 
+## The Clock / Timer
+
+Each phase has a clock timer - usually 30 seconds, which counts down to 0.
+
+Each time a player completes their turn, the clock is reset.
+
+If the clock ever gets down to 0, the game is terminated, and everyone loses.
+
+The reason for this is to allow the game to run on a public server, and not get stuck in some mode where its waiting for a player to do something, and everyone runs, freezing the game forever in that waiting state.
+
 ## Winning the Game
 
 Each player takes a turn, selecting an empty square to place their piece in. 
@@ -87,3 +97,25 @@ after someone set us up the bomb.
 This code is interesting for the following reasons :
 
 - Its all written in Zig
+- It uses the excellent http.zig library https://github.com/karlseguin/http.zig
+- Note that the router is decorated inside the Game object ... the implications of this are that it is possible to create 'web components' using this
+zig/htmx approach that are all self contained, and can be imported into other projects, without having to know about connecting up routes. Interesting.
+- Uses SSE / Event Streams to keep it all realtime updates with pub/sub from multiple players
+- No websockets needed
+- There is pretty much NO JAVASCRIPT on the frontend. It uses HTMX https://htmx.org ... which is an alternative approach to web clients, where the frontend is pure hypertext, and everything is done on the backend
+- There is a tiny bit of JS, to update the session ID, but im still thinking up a way of getting rid of that as well.
+- Uses std.fmt.print() as the templating engine.  I didnt know before, but you can used named tags inside the comptime format string, and use those to reference fields in the args param. 
+Actually makes for a half decent templating tool.
+
+
+## HTMX thoughts
+
+Yeah, its pretty cool, worth adding to your toolbelt. Not sure its really a 'replacement' for SPA type apps - I think it might be painful for larger apps. Not sure, havnt tried yet.
+
+What it is 100% excellent for though is for doing apps where there is a lot of shared state between users. (Like a turn based game !) In that case, doing everything on the server, and not having any state
+at all on the frontend to sync, is really ideal.  Its a good fit to this sort of problem.
+
+There are some very complex things you could do with a turn-based-multiplayer-game type of model though (doesnt have to be a game even) And being able to do that without touching JS, or
+writing a tonne of code to synch state on the frontends is really nice.
+
+Its also a reasonable model for doing shared state between GUI frontends, just using the HTTP/SSE protocol too.