From my personal point of view the question should be the following:
What, if anything, is needed and fills a function? In what way would the world benefit from another local client vs. benefits from a so-called cloud based software?
If reason is to guide us to the answer I think it leans towards cloud software. My main argument would be that there is already two open source local clients in existence that do their job, and one of them is still in heavy development, albeit functional (OTCGN2 / gCCG). I can't see any point in spending plenty of work hours on creating yet another local client, if that client doesn't do something amazing or solve a huge problem which the other clients can't. And honestly, what would such a function be, that warrants the creation of a brand new client?
saturation of local clients
The existing clients prettty much have it all. Sure, they can be improved in some ways - all software can - but does those marginal improvements warrant and justify the amount of work that would be spent into creating something from scratch?
I think not. It would be like creating yet another webbrowser instead of using a plugin for FireFox or Chromium. Or, in same manner: Write a new browser instead of using the source code of either one of those two to build upon and improve from what's already around.
It goes without saying that sometimes software is so badly written and lacks so much that it's easier to trash it alltogether and start writing brand new code from scratch. However, that is not the case with the current open source clients: On the contrary, OCTGN2 is top of the line, and gCCG, while old and rusty, is a very robust system that gives us the means to let the world play WT online, using local clients.
There is but one single account where the open source clients fail: They have no implementation of AI and/or rules enforcement.
The rules enforcement part is really not necessary and usually even slows down game play, and it is also seldom needed as it brings very little benefits.
AI is...n
The AI support is the most interesting aspect that the open source clients lack. In one way, them "lacking" it is also not true - they choose to not implement it, as they have no need for it: The clients were written to enable humans to multiplay. And that's what they're all about and deliver. Not single player games vs a computer.
On that front, there is a third local client called Wagic, which does just that: It is designed to be single player only, and has an AI that plays MtG.
Currently there is no open client that is configurable in a way which allows it to work both on- and offline vs computer AI and/or human and have it's rule enforcing shut on/off etc. Such a tool has probably (my guess only) not been created because the developers of the current clients deemed it too cumbersome to develop and/or the actual worth of having all the additional functions added in relation to work and user base as too low to justify such a full featured beast.
Nevertheless, client wise, this is also the only thing that hasn't been done yet. How huge is the hole this leaves? Frankly, I'm not sure. My guess would be not that huge: Usually players tend to favor single or multiplay and keep to whatever they happen to enjoy.
What I'd suggest to anyone that's interested in developing an AI or rules enforcing for a local client is to just take the source code from whatever open client is already around and improve upon it: Much of the work has already been done. It's already there. Why not just either co-work with the dev of that project or, if such as co-work is not desired by anyone, fork it and add whatever is missing and that is deemed as a desired?
(For the record, OCTGN2 is written in C#. I'm, not sure what was used to code gCCG but it sure isn't anything Windows-specific...)
cloud solution
(For the record, in the following I use "cloud" and "web-based" as synonyms, even if I can appreciate the distinction that's made between the two. I really don't like the cloud wording and find it mostly redundant and a hype, just like talking about "web 2.0" when those technologies have been around for ages and also used in "Web 1.0")
flash
When it comes to Flash, much can be done in it and it has developed it's scripting language plenty from back in the days when it was new. However, more and more parties are taking a stance against Flash usage. Apple is one of the bigger players, and Google is tight to follow. They all wish to see Flash dead, for several good reasons (and some economical as well of course). Because of that I think the world is moving away from Flash. HTML5 is an example of that. Google open sourcing video tech they bought is another.
While I
don't want to select the language for the coder that does the actual work, I would not hesitate to
recommend that an open language is used if possible, realistic and if it that does not compromise with general quality that the user experiences in the end product. I
myself would never do anything in Flash because of the simple reason that it's extremely buggy, unreliable, resource draining and works crap on Linux platforms. In addition, there is nothing open about it, leaving the fixings and future of it at the whims of Adobe & Co, and also potentially raising legal issues.
for
- There is no such thing around that is open source.
- It's instant: You login (using OpenID or FB or internal user system), and all is always right and up to date etc. You don't have to download card images and game patches, you also don't get to see options, menus, functions and so on that are irrelevant for the game.
- Bigger user base - also makes game more known and stronger community.
- Platform independent.
- Computer independent - play it no matter on what machine you happen to have in front of you, at home, school etc. No local copy needed.
All in all, think about Travian and such games that have immense popularity. Why? It's
not because of their innovative gameplay or graphics. It's only about
availability and social context, which brings this to questions like if it should be a stand alone site or integrated into services such as Facebook etc. A huge user base and availabilyt
maintaining code & team size
I anticipate that one programmer would be enough to get the project started and provide a usable solution in short to mid term. The problem arises in the long term when we talk about the ability to maintain the existing solution.
Any and all code must be documented and clearly written, as it should in all open projects if one wants the code to prosper in the long run.
While I can't guarantee that there would be more programmers around to aid when needed, I do believe that it's higher probability to find additional coders to a
unique and pioneering project like the web based solution compared with finding them for yet another local client. I think such projects are more appealing to people because of psychological reasons. I also think it shouldn't be very hard to actually find additional team members once you'd have something functional to showcase. Hardest part is always a projects infancy. Most never make it into their childhood. They die as infants.
Are we creating an application just for us or for everyone to use?
If we're doing this and doing it open source I think it should be done in a way in which it can maximize it's benefits to the world, meaning it should be an application that is somewhat easy to use and adapt so that most CCG:s can run on it.
This is also a strategical move: By keeping it universal we will get way more support and will have easier time finding additional coders later on. We harvest the powers of the full open source community. If we'd close it down and make it WT only and hard code all WT related stuff it would be of less use for most and also something which would mainly only interest WT community (which is non-existant and will be non-existant until at least 1-2 years after the release of an actual playable game). Thus, I suggest it to be a flexible solution, focused on being easily moddable so that most normal CCG:s can run on it.
I have a hard time seeing anything that speaks against making it generic. Code wise, it isn't much more work. It could almost even make the quality of the code higher.
Connecting to the database is equally hard. Even if the application is web-based, we cannot connect directly to the Cardscape database, if we do what will happen to other users that want to install their own version of the server? Will they have to install their own version of Cardscape as well?
This is my original stance on the topic: There should be
no necessary relation between CS and SS. Whatever relations are put there should be done locally within and for the WT project only. Bridging them would be nice if easy and functional. If not, then they won't be bridged. No big deal really.
However SS is coded, it must
not rely on CS being around. CS and SS must both be kept as stand alone projects, at least they should be developed as such from the start. Later on, if we want to release some kind of bridge and code support within them so that they can communicate with each other, that could be done as well. That's in the future.
For now, let's just imagine that a user or community that is interested in using ONE of the two, should not have to use both. Or should he/she? I think the question can be asked, and honestly don't know what the best option is.
My reasoning just tells me that having two separate teams and stand alone code bases, each with it's specific function, is usually better than having one jumbo-project. I see
a lot of benefits and it would indeed be super cool if they were bridged from the start, but is it a smart move from a developers and long term perspective? I don't know any longer, and figure it would maybe be up to the coders of them to decide.