lightvector / arimaa-server Goto Github PK

Eventually, before we actually go live, we probably want to consider adding limits on message size and rate for things like sending of chat messages, opening of new games, etc.

Add ScalaStyle target for sbt.

Scalastyle examines your Scala code and indicates potential problems with it. If you have come across Checkstyle for Java, then you’ll have a good idea what scalastyle is. Except that it’s for Scala obviously.

http://www.scalastyle.org/sbt.html

Once you add the sbt plugin you can do:

sbt scalastyleGenerateConfig
sbt scalastyle

Overview of SBT plugin: http://www.scalastyle.org/sbt.html
XML file configuration options: http://www.scalastyle.org/configuration.html
Example config file. (Used by ScalaStyle team, and Martin Odersky): http://www.scalastyle.org/scalastyle_config.xml
List of all implemented rules: http://www.scalastyle.org/rules-0.2.0.html

Scalate by default lazy compiles and caches the templates every time we access the resource.

http://scalate.github.io/scalate/documentation/user-guide.html#precompiling_templates

Currently, it's a big white rectangle popup that's much larger than its content, and that doesn't fit with the styling of the rest of the site.

A decent number of fixed-strength near-instant-move bots might go a long way to populating the site and giving people things to do.

There needs to be a page for people to change their password and email account and possibly another details of account management. Perhaps, it would be convenient as well to have a page for all the site settings in one place such as animation speed, sounds, preferences related to postal games, etc, once we have such options.

We need a page or links or something for new people to learn about what the game and its rules actually are.

There's a memory leak in when running SBT to test the webserver. Enough runs of ChatTests.scala will result in something like the following:

Exception in thread "Thread-32"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread-32"

OR

java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: PermGen space

As far as I can tell, this is because the web server infrastructure leaks in Java's permanent generation memory on multiple runs. Using "jmap" to probe the memory usage of java, it seems like every run of the tests consumes about 20-40 MB more memory in the permanent generation that is then never freed.

I also haven't find any online resources explaining how to fix it. I only find resources that explain how to increase the limit (and thereby require less frequent restarts of sbt).

Add alternate piece and board graphics to the site, such as for example the ones here: http://thenoviceoof.com/blog/projects/arimaa-icon-set/. Along with a way to switch between the graphics.

Neither mattj256 nor lightvector have strong feelings on this one.
Lightvector is going to talk to Omar and/or the community.

Need a page or a way to see a list of recent games and to search through historical games (by player, or date, or game length, or whatever).

Add a way for users to specify their own time controls in the UI, rather than hardcoding only some fixed available choices.

Add the ability to comment on games after they're played. The design of this should think carefully about how much it should share with with in-game chat. In fact, the in-game chat database and JSON API was designed to leave a bit of a foothold for this, although I don't know if that's ultimately the best way to go.

Need to add the ability to scroll backward and forward through moves in a game to view earlier turns in a game. Particularly when viewing a historical played game, but also when playing or spectating a game.

The following error occurs in sbt when trying to download a library that is depended on by the json parsing libraries we use:

[warn] problem while downloading module descriptor:
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.7/paranamer-2.7.pom:
invalid sha1: expected=deea673ac6c495cfca3c2fecce26bd9b67295e5b computed=36ef984e4403f800d8aeb5b82045ea4cec0db07b

(libraries added with this revision):
b1c87a9

For now, the following line in Build.scala disables checksum checking.
checksums in update := Nil

Once the mismatching checksum issue is fixed in the library, we should remove this line and retest.

Implement or experiment with alternate controls for moving pieces, such as edge-clicking or drag-and-drop.

Allow either player to abort the game before the first move has been played, with no ratings penalty.

(There is some potential for abuse here, so that should be either monitored automatically, or else players should have a way to report abuse to the admin staff.)

(I believe the Free Internet Chess Server allows either player to abort without penalty, i.e. first white moves, then black has the option of aborting with no penalty rather than continuing the game. Again, there's potential for abuse here and that has to be managed in some way.)

Selectable default time controls for postal games, email reminders for moves, perhaps the ability to start them without both being logged on at the same time.

Adding scalate-jruby to the scala classpath should allow us to use SASS css templates.

https://groups.google.com/forum/#!topic/scalate/wRG9HRtKK-M

https://github.com/scalate/scalate/tree/master/scalate-jruby
http://mvnrepository.com/artifact/org.fusesource.scalate/scalate-jruby

Implement animation for piece movements in the game client.

Errors responding to queries, times of creation of games and user accounts, etc.

Initially we're only going to support the official Arimaa notation:
2. Ee2n Ee3n Ee4n Ee5n

Some in the community (clyring, SilverMitt) want to use alternate notation(s).
(The exact format of these alternate notations hasn't been specified yet.)

Implement sounds in the game client (steps, captured pieces, low-time, setup, end-of-game win/loss), and a way to turn them on or off (and/or adjust volume?). Perhaps also sounds for chat messages, with a separate on/off control.

The current package structure (namespace) is not intended to be permanent.
We should decide whether we will be under arimaa.com or some other domain name, then change the package to match.

Options:

• arimaa.com (Requires Omar's permission and maybe permission of the community.)
• playarimaa.com / playarimaa.net / playarimaa.org (These domain names are available. Requires Omar's permission because he owns the trademark.)
• arimaa.club (This is rabbits' domain name?)
• Something without "arimaa" in it.

Implement the server queries roughly as sketched out in the draft API ( issue #30 ) for querying the gamestate and for making moves.

Note: this doesn't need to wait until the board and rules implementation is entirely done, since the interface and data structures exist for them already, but testing of course will need to wait on that.

In Chrome, at least, there are a max of 6 open connections per domain (I think shared across all tabs). Since several different things in the site use long polling, if the user has enough game client windows open, or games open in a single gameroom window, this will cause other queries to block (potentially missing heartbeats and such).

I don't know of a solution that doesn't take a lot of work. We want to switch to websockets as a replacement for possibly many long-polling connections, but this requires working around what seems to be bugginess in Scalatra, or switching our web framework entirely if indeed the bugginess is not work-around-able.

Scala has a built-in monadic class scala.util.Try.
It is a case class and the types are Success or Failure.
(I hope I'm getting the terminology right!)

This class integrates with Scala's exception handling. (If an exception is thrown it returns Failure and a message, otherwise Success.)

It looks like Checkstyle has support for this:
https://groups.google.com/forum/#!topic/checkstyle/WG6KBm9i8t4

I'm not sure if ScalaStyle does.

Should we have a standard page for registering bot accounts for developers? But the API actually doesn't distinguish between bots and non-bots almost anywhere. So maybe this isn't so important, not sure.

Start a page on the wiki and move the draft API there for more flexible community editing and discussion.

As it's good practice not to send login info, passwords, emails, in plain-text.

I just set up JUnit because that's what I'm familiar with and that's what was easiest, but ScalaTest has better features and better support for behavior-driven development.

A page for each user to display basic stats (rating, win/loss record, last login time, etc) about that player.

The server should not allow a move if it is the third time with that position with the same player to move.

Implement check: immobilization as a result of 3-move draw rule.

Is this even possible?
It came up in chat.

Set up preconfigured criteria, autodetect when a player satisfies that criteria, and display it somewhere.
For example:

• Beat bot with X handicap.
• Beat bot within X number of moves.
• Beat bot by immobilization.

http://arimaa.com/arimaa/forum/cgi/YaBB.cgi?board=talk;action=display;num=1147634070;start=180#180

The current implementation creates a ton of Java objects and will be quite inefficient.
Bitboards are more efficient and we should use them.

We might want to use sbt to build our server.
I don't see any compelling reason to set this up right now:

1. We don't have a lot of source files.
2. It's straightforward to change later on.
3. The online reviews of sbt are mixed.
4. Ant already does everything we need.

Also the learning curve is a bit too steep for me right now.

After some research, probably going with this.
http://slick.typesafe.com/

The latest version (3.0) supports asynchronous queries, an abstraction layer that lets you access database contents as if they were Scala containers, and if that becomes a problem for performance (as some have reported online with more complex joins and queries), the ability to fall back to direct SQL queries.

Add a simple display for captured pieces to the game client. Currently there is none, so it's sometimes tricky to tell the material balance at a glance.