[Home]ChrisHowlett/DominionServer

ec2-3-93-59-171.compute-1.amazonaws.com | ToothyWiki | ChrisHowlett | RecentChanges | Login | Webcomic

A server, written by ChrisHowlett, for playing Dominion.
Located [here].

Anyone want a go? :)

The current version is V1.0.0


New Features:

Bug Fixes


Previous versions


Beta 0.2.0


New Features:

Beta 0.1.0


New Features:



Next Release



The next release will be a targeted release to migrate to Heroku.

A minimal set of changes, limited to bug-fixes and enhancements required for effective hosting elsewhere, will be made.
Ratings history will be lost.


A second tier of WIBNI enhancements plausible in this update is:
If I do this for the stated purpose, it'll need to tie chat lines to game events. I can think of two ways. The simpler would be to have chat lines become history lines with a CSS style that calls them out (perhaps shifting them leftward to protrude from the flow?). The alternative would be put turn counts into the history and associate chat comments (separate from histories) with turn numbers, displaying them somewhere else in a more conventional style. Preferences?



Bugs
Works WikiNow on my localhost dev server on Chrome. Would be interested in a report on whether it's playable on ToothyCat on the latest Chrome.
Confirmed not to. --CH
Bug reports


Leave yours here!


Planned Features
The following are intended to go into a future release. Please help me prioritise by voting! I'll leave an empty Priority: bullet with each - add + or - if you want to indicate a desire for a feature to be done soon, or relative apathy regarding a feature. Please don't cancel + with -; ++--+ is much more interesting that just +.

You can also leave English comments below.

Expansions
Engine
Interface - Notification
Interface - Other

Comments / Feature Requests
Can we get a plain old cardlist page?  Not particularly for the game itself, but for the inevitable dominion discussions.  --Vitenka
Seems like the Wiki would be a good place for that. How about Dominion/CardList? --AC
Actually, there's a pretty good one already at http://dominion.diehrstraits.com/?set=Prosperity&f=list . --AC

I think queueing of user inputs/choices might be one of the biggest usability enhancements possible, and it occurs that it might actually be quite doable. E.g. I play Bureaucrat, and know what I'm going to want to buy; the Alex:buy is in the tree already, so I'd like to be able to say "I'll buy a Silver" and have the rest of my turn take care of itself once the other players do their Crat actions. Thing is, the engine and UI already have a reasonable guess what the inputs for each element in the tree will be. I propose that you could let me select any action in the tree that's waiting on me, and specify what I hope to do when that option resolves. It will obviously only show me options that it currently knows about, and those options will need checking when the engine comes to actually process that element, but it could save a *lot* of time. --AC
It would probably be sufficient to be allowed to just move the "Wait for everybody else" task to the end, for those tasks which can't change your hand.  --Vitenka
Will require thought, but is probably doable. Don't expect it in the next release.

An undo button.  Please?  --Vitenka  (Both in general, and specifically, right now)
That could be really difficult, but I'll have a think.

I may at some point (requiring me to get Git working on one of my machines) move my hosting to [Heroku], in order to both a) get an up-to-date Rails, and b) ease MoonShadow's load.
...although the 5Mb database limit on the free version is a bit stingy. The one completed game hits that already, so perhaps not.
''On third thought, I suspect that much of that was Postgres's framework bloating. Might be worth a go.

Using secret chamber against a spy is WAY too technical.  Playing with physical cards I can play around with the order until I can get it right, being forced to do it step by step makes me make stupid mistakes.
What would you prefer? "Place a card on top of your deck" followed by "Place a card on top of your deck" is pretty clear. Do you want a subtitle "(This will end up second from top)" on the first one? --AC
That might be enough, actually.  It was that ordering, plus the spy then letting me discard the top one once I'd finished arranging them confused the heck out of me.  --Vitenka

A somewhat controversial feature request: display the current contents of your entire deck. Thing is, in the current interface you can always laboriously reproduce the contents by searching the history anyway. I've found myself searching history for "How many times does it say "Alex bought Gold"? And there's one in my discards, which means there are two left in my deck. Right." Since it is possible to calculate it (or keep notes) anyway... --AC
I'm actually pondering going in the other direction, and displaying only - say - the last two complete turn rotations of history. So then you can't deduce your deck from the history. --CH

Support for bots. Possibly as defined by a script on a wiki page. --qqzm
There's always someone who wants bot support, and it's usually you ;-p. I could see this happening, but obviously we need a good API, which in turn means we need a good definition of what you'd need the API to provide in terms of enabling bot implementation. That will need discussion and heavy input from you. I'd make a subpage, but ToothyWiki doesn't allow two-level hierarchies. Perhaps I'll ask to move this to a root DominionServer? page...
How I was thinking of it working was that the bot script would define 3 methods. Each of these would take a readonly game state object parameter and return a result defining it's current decision. The engine could then call the procedure in much the same way as it displays the game state to the user, and handle the result in the same way it handles a user making decisions. The major work, of course, is in building a script interpreter - it's possible that Ruby has one built-in or available? I think you'd probably want the script language to be Ruby or Ruby-like so that you can reuse your existing code. The three methods I was thinking you'd want to have would be:
chooseAction - called whenever it is the bot's turn to take an action and it has one or more action cards in hand. The return value is either the id of the action (and the mode to use it in if applicable) or some special value indicating "play no more actions".
buyCard - called whenever the bot has a buy to use. Given that it knows the game state (including which cards it has in play) then it doesn't need to have total cash and number of buys explicitly spelled out for it, but it would make it easier for bot writers if you were to provide such information. The return value is either a card to buy or skip.
makeChoice - called whenever the bot has to make a choice for a card (not necessarily its own). This one is obviously the most complicated and I'm not sure how best to implement it. There are so many different choices that come-up on different random cards. I think the best thing to do would be to say that the bot just has to implement each individual card that causes a choice, and have some sort of metadata on the bot (probably need this for name, description etc. anyway) that defines which cards it can be used with (so you can stop people from selecting the bot in a game with a card it doesn't know about). I don't know. It might be possible to distill the choices down to a well-defined set of atomic ones but I don't think it is, unfortunately.
--qqzm
Hee. This would be lots of fun. I think I'd want to program a bot to do a particular strategy. The Goldfish-bot (which buys Prov/Gold?/Silver?/nothing, and makes random choices in all other cases) would be fairly easy to program. I however point out that Mint, or Mining Village, show that total cash can't just be deduced from what's in play. --AC

Hacking [Ascension] onto the same engine and framework. --qqzm
Looks like an interesting game, but very unlikely to happen. --CH

Don't display users who've completed zero games on the ratings page? --qqzm

On the game start screen, have options for "Random, force 3/4 split, force 2/5 split" so that the game creator can choose to give everyone an equal start - useful if picking a set that's particularly polarised one way or the other e.g. the game which was all 3s and somebody (Vitenka?) was severely hampered by starting with 5/2. --qqzm



MoonShadow - am I right in thinking that my app runs as my user account, so you're happy for it to run (within reason!) arbitrary Ruby code local to its directory? I ask because I've just realised that - by design - Rails looks for its own code, and the code for any add-ins, locally in the app directory before the system path; and it comes with little routines to freeze the current version into the app.

The upshot of all of which is that I can effectively upgrade Rails as far as it's compatible with Debian's Ruby version simply by freezing the version I have on my own computer into the app.

Yes, that is correct. --MoonShadow


Unattributed comments on this page (outside of the enhancement reqs) are probably ChrisHowlett.

ec2-3-93-59-171.compute-1.amazonaws.com | ToothyWiki | ChrisHowlett | RecentChanges | Login | Webcomic
Edit this page | View other revisions | Recently used referrers
Last edited April 8, 2011 3:22 pm (viewing revision 243, which is the newest) (diff)
Search: