Collectible Card Game Headquarters

If you've noticed the few posts I've made so far, you may have noticed that I have been making my own TCG program. Before now, I wasn't ready to officially announce it to the world, mostly because my first post, less than one week ago, was asking about how to get it done in the first place. I've made considerable progress, considering I have had no real help from anyone. And now I'm ready to make the official announcement.

I am making a completely new TCG. That game is called CardGrid. I have been working on the rules on and off for about three years, all on my own.

What makes CardGrid different?
Unlike virtually any other TCG/CCG thus far, turn-taking will not be just one player acts then the other. Instead, Characters will be the ones to take turns, with the player deciding what to do.
You will not draw cards just because it's your Character's turn. Instead, you will have to decide when to use your turn up to draw cards.
There are no minions. Your Characters are who you start with, and that's it.

CardGrid as a commercial venture (albeit indie):
CardGrid will be a free-to-play title, but intended to draw a profit through advertisements and/or a Cash Shop. If it is decided both are to be implemented, advertisements can be turned off temporarily for a small fee. I'm sorry if this irritates some of you, but this is the way it's going to be.

CardGrid's current state:
The initial test version of the CardGrid client and server are not yet functional. I'd say (as usual) assume Valve Time, but that needs a set date to fail to meet.

Projected platform of release:
The test versions will be built in C# 2010, and will therefore be available to any user of a Windows version that has .NET 4.0, as well as OS X and Linux users with Mono 2.8 installed.
The release version is still in the basic planning stages. That is, although it will be a web app, the programming and scripting languages involved are still not confirmed. The current plan, albeit likely to change at a pin drop, is to use ASP.NET with C# 2010 and IronPython.
Since it will be a web app, all modern graphical, AJAX-friendly web browsers should work, from iPod Touch Safari to Internet Explorer. Opera Mini, Opera Mobile, and similar apps will never be able to work, though the full-size version of Opera will be the initial development target. (Look. I like Opera. It has more built-in features than Firefox in about half the download size.)

Will CardGrid be open-source?
No. CardGrid is a completely closed-source project, and there are no plans to ever change that. If you want legal access to the source code, you will need to become a member of the CardGrid team.
However, certain elements may be used as code examples for people looking to create their own games. These examples will be released under either an OSI-approved license or as public domain.

What does CardGrid need from the community to see release?
Support. Mostly encouragement, but possibly some direct assistance.

Ok, so what specifically does the CardGrid "team" need?
The old version of this was way too large, so I'm just shrinking this down to saying "everything," from encouragement to programming to card rule and card image design.


Please take a look at the development blog and the rules linked there. Please provide input about what the game needs. If you are interested in becoming a CardGrid team member and you have skills that have been requested above, please apply via PM. Do not ask to be part of the team in this thread, but do express interest in playing the game.

This post will be maintained to provide the status of both the game and the team developing it.

--CardGrid Team--
Members: 1
Formedras: Pretty much everything, except art assets.

--CardGrid Release--
Nowhere near it. Don't ask for a date - even my previous prospect of "2011" is unlikely. Just assume that the game is being developed.

--CardGrid Test 1--
Who really knows? I'm sorry, but doing this myself with just a minimal amount of programming experience, a release in the near future isn't looking good.

This is pretty much a bump to tell people that I'm still working on this, rather than letting them think that I gave up.

I've given up on codebases, but not the game. I've written a few posts in my devblog, although most of the recent ones aren't directly related to CardGrid. I've put more into the rulebook pages.
I've made an interface (1024 pixels wide), then shrunk it (900 pixels wide).

And it all seems a weak argument as compared to actual progress, of which I have little, and none of it presentable. All I can really say is that I haven't given up.

Here's my current prototype interface. It's not exactly stylish, but I think it'll work for now.

Progress, no matter how small, is still progress. Thanks Formedras!

I've completed enough of my Card Editor program to use it for the Test program. Pretty much started working on it I think less than 24 hours ago and it's already done. (If not 24, then definitely less than 48.)

It's one hell of a lot prettier than the v1 Card Editor was. But the v1 codebase (Yeah, let's call the last time I got this far v1, while the current codebase is v2 - everything else is just scrap) encoded the Action rules, not just the descriptions, in XML. Then again, that may not have been the best idea. I had to insert every single Command in each Action, each Command had multiple Sources that I also had to punch in... using Python does it a lot more gracefully than XML rules did.
(XML: Card 1 | Action 1-1 | Command 1-1-1 | Source 1-1-1-1 | Source 1-1-1-2 | Command 1-1-2, etc.)
(Python: Card 1 | Action 1-1 | Command 1-1-1, Sources built into the Commands)
I could, of course, have just parsed a command, but I don't actually know how to do that.



One step closer.

We've had discussions regarding the merits and drawbacks of XML before...IIRC most people don't like XML that much, it's too hard to use for the benefits it provides.

Huggybaby wrote:We've had discussions regarding the merits and drawbacks of XML before...IIRC most people don't like XML that much, it's too hard to use for the benefits it provides.

I've had great luck with it so far, using it for piece definitions. But like anything else, it's not a "one fits all" type of tool. I've seen XML abused big time.

~telengard