General tutorial on programming a CCG?

[Formedras]

I've got a question that leads to more questions: is there anyone willing and able to design a tutorial or other guide on how to program a CCG? I'm thinking in a very general sense, where the people using the guide would be able to replicate any CCG/TCG they want or even make their own.
I've looked through the Forge source code once and it just read as Greek to me, same with Incantus and Wagic. (Of course, it doesn't help that Wagic is designed for the PSP.)
The Forge blog talks (or talked, I'm not sure if it still does) about some technical aspects, but it doesn't really explain any of it.

If someone actually does this, I'm not sure what language it should be in. (Probably best to use at least one real programming language.) Perhaps an easier language such as C#? Or should it be in a more widely-used language, like C++ or Java?
Should programming the complete interface be part of it, or just rendering the cards?
Should it be for people with understanding of programming concepts, or for total beginners? I'd think advanced programmers already know how to get it done, and therefore don't need to be catered to.
Also, should the guide be in website, wiki, or blog format?

This is, of course, a completely greedy request, since if it's done, I plan on taking full advantage of it to make my own CCG. But why would I even ask if I already knew how, or otherwise had no interest in making use of it?

Thanks for reading this post, and extra thanks if you start considering the request.

[Hellfish]

In my casual-developer, only-partially-informed opinion, CCG's/TCG's are too varied for a blanket tutorial. At best,maybe you could go through the merits/drawbacks of various design patterns that could be used, but then that's already some ways above the heads of most beginners.

[Formedras]

Actually... it's not the variance that worries me. I'm not looking for anyone to tell me what my game's rules should be, since I'm not making a clone of a CCG, but rather a fully-original one. Anyway, that's still easy: tell the game server to wait for events (commands from the clients) and react to them. (Yes, the server. I don't think a P2P model is a good idea; just try to allow both sides to hold and change the game state and keep them in sync. Not gonna happen.) Any programmer should be able to figure that out once they figure out the other parts and events. If not, they probably shouldn't be programming.
Plus... a guy's got to learn somehow. Better a guide that goes a bit over the user's head than pure source without a guide that goes orbital in relation to the user's head.

Anyway, here's what I think should and shouldn't go into a guide like this.
What I'm looking for in a guide:
1. How to set up cards, decks, and players.
2. How to set up turn steps and turn order for a given category of objects, not necessarily players. Players would obviously be the default for most games, but allowing it to be different objects may make things better in the long run, both for the guide and the programmers using the guide.
3. How to create a server to handle the game state and how to connect the clients to it. Obviously, this would involve networking.
4. An Object-Oriented language, using events as the driving force for progressing the game forward.
5. A way to use text and/or markup language (XML, perhaps?) files to provide cards instead of hard-coding them.
6. How to let cards, server-side of course, perform actions.
7. How to set up a basic client, using whatever GUI the language and programming library/framework prefers or otherwise uses.
8. The KISS principle. Some of the other things look like they'd violate this (Client-Server model, anyone?), but I think I've got the requests as simple as they can be while still being usable.

What I'm NOT looking for:
1. A specific programming language. By this, I don't mean "don't use any language", and I also don't mean "don't stick to this language that you know." Probably best to stick to a single programming language (maybe plus a markup and/or scripting language), but whatever the guide designer is using is probably best for now.
2. A specific CCG as a guideline. See point NOT-1. Magic would be the obvious starting point for a guide, but I personally think it's too limited; however, if it works it works.

All considered, I think a wiki/guide format would be best for this. A non-wiki guide would either look bad or mostly like a wiki anyway, and a straight-up tutorial would give every user the same result, which is the exact opposite of what I wanted.

I honestly think this could work. Hellfish is probably right about this being too much for a truly fresh programmer, but ones that have the basics down and need to learn about intermediate concepts like custom Events, Interfaces, Components, etc. could use this.

My experience in useful programming, by the way, is limited to creating basic life counters for Android (thus using Java/Dalvik), and a twin-stick PvP shooter using C#/XNA. (Like Net Rumble, but I had no clue about that source example until yesterday, while I had made my shooter back in December.) In other programming, I've tried to learn C, C++, Python, VB6, and Java, and I'm taking a class in VB 2010, but for one reason or another I've ditched every language I've tried. (Yes, I will go back to C++ when it's time. And I get the feeling that the time will be somewhat soon.)

If you're still here, thanks for reading. Please, reply about what you think of the possibility of making a guide.

[Arch]

I think that the individuals that would be willing to do this already are. The blogs might not be exactly what you're looking for but I belive there's quite a bit of information already out there.

Here are some counter-proposals;

Ask for different content.
Most people I know have no problem talking about their designs, ideas and implementations of their favorite projects. Check with the bloggers. If you ask more pointed questions than "CCG implementation tutorial" I pretty sure they'd be happy to answer.

Do it yourself.
You've already broken down your request into parts. You could solicit opinions and ideas about each from this board and compile them yourself.

Be an amateur.
It seems like your actual goal is to create a CCG-game. Do that instead, even if you don't know how. Amateurs have one important quality that more seasoned practitioners lack; they have no idea how difficult something might be or how much work it might take. They have nothing holding them back. Start somewhere and see where it goes.

[Formedras]

Thanks for your comments, Arch. I'd like to reply about all your points.

About there being information out there: If you're talking about around the web, rather than in the heads of the bloggers, I've made multiple searches through Google; that's how I came up across Forge, Wagic, and the like. Other than the source code for those (and maybe other Magic-clones), and finding the no-rules-enforcement programs, I got nothin'. Maybe I'm not looking in the right places, but I can't find anything useful to inexperienced programmers.

Ask for different content: I'll probably do that, and I've got an informal mentor IRL for general programming guidance. (As soon as I said "digital card game," he started picturing the structure in his head, so I think he'll be a good source.) The reason I wanted "general information" was pretty much that I didn't know where to start asking. I mean, for example, do I ask about the card format, or the rules engine? Start with the client, or the server? How am I supposed to do the networking?
The answers to the first two, by the way, are "card format" and "server," respectively.
The rules engine on a CCG can't go anywhere without the card format unless you build the interpreter's end-result, and that's probably pretty hard without the card format.
And the server is far more important than the client: The client is merely an interface for the server, with holds the actual game. You can't make the client unless you have the server. You can only make what the client looks like, not how it acts.

Do it myself (the guide): After I posted the original post and got the first reply, I started considering that. Not through asking others, but through my own experience. (I've gone so far in considering it that I downloaded a personal localhost server to run a WordPress blog and MediaWiki wiki. With that stuff, I just need to know where to get started at.) Oh, and the asking for different stuff relates directly to having me make the guide myself through vicarious experience. It's still not a bad idea, but I don't think it's my style.

Be an amateur (do it myself: the game): As implied above, that is exactly what I am doing. I'm in the middle of working on an XNA client and server (because that framework is what I know most); once I'm done with that, I'll probably work on removing the XNA from the server and building a standalone client. Oh, and it's an original game, not a digital clone of some other card game. (I started thinking about it as a digital card game once I tried it as a physical game and found that the large numbers and mathematical complexity made it clunky and slow.)

[juzamjedi]

The best way to learn is to read the source code for one of the existing apps here. Ask the developers specific questions and they will surely help you understand where to look in the code and understand what is happening.

I doubt anyone is going to create a document like what you are suggesting - coders don't even like to leave good documentation in their code I kid, I kid.

This would be a really cool blog idea though. Documenting all the things you are suggesting would be a lot of work, I think. Maybe even an idea for a senior seminar / project.

[Formedras]

Ok, I decided to do make a blog about my experience making my own CCG. I hope I succeed on both the CCG and blog fronts, but I'll be happy with just the CCG.

http://cardgrid.wordpress.com

If I picked a bad host, please tell me before I get too deep into this.

Oh, and juzamjedi, I would love to be able to ask specific questions. But I don't even know where to start looking for a question to ask. Probably in Forge's CardFactory, but it's all gibberish to me, so I don't know where in the CardFactory series of classes to begin.

[MageKing17]

I would love to be able to ask specific questions. But I don't even know where to start looking for a question to ask. Probably in Forge's CardFactory, but it's all gibberish to me, so I don't know where in the CardFactory series of classes to begin.

A little advice before you go source-code diving; keep in mind each program has its own strengths, weaknesses, quirks, and inaccuracies. For instance, I haven't looked at the source code for Forge, but I know that they hardcoded a number of cards (they're now moving to a newer, more flexible system called... Ability Factories, I think). Hardcoding anything related to a single card is generally a Bad Idea(tm), and you should avoid it if possible in a new project. On the other hand, in Incantus, we avoid hardcoding entirely; as a result, the program generally runs slower, and adding an AI would be virtually impossible. Just a couple of examples to try to reinforce that everything has tradeoffs, and, as Juzamjedi said, you should talk to the developers about their programs; not just to help understand the code and what's happening in it, but why it was written, and what the tradeoffs are.

(Speaking of, if you want to speak with me or Incantus (the person) about Incantus (the program), we can most easily be contacted on IRC, channel #incantus on EFNet.)

[ivycool]

my casual-developer, only-partially-informed opinion, CCG's/TCG's are too varied for a blanket tutorial. At best,maybe you could go through the merits/drawbacks of various design patterns that could be used, but then that's already some ways above the heads of most beginners.

[magicgrove]

My suggestion is to start with a couple of easy cards. Try to implement the whole game, just with those cards. Do not add any rules which are not needed by those cards. For example I started magicgrove with this deck:

4 Llanowar Elves
4 Grizzly Bears
4 Elvish Warrior
4 Trained Armodon
3 Order of the Sacred Bell
2 Llanowar Behemoth
2 Shivan Dragon
1 Verdant Force
4 Blanchwood Armor
4 Shock
4 Volcanic Hammer

I implemented the graphics, card rules, turn rules and the AI. When I was done I started to add some more cards , which lead to adding, rewriting some code. Doing it this way you have a constant feedback which is good, since you will have better chance to actualy finish what you started.

[Huggybaby]

My suggestion is to start with a couple of easy cards. Try to implement the whole game, just with those cards. Do not add any rules which are not needed by those cards.

I think that's the way most people start. But aren't you sure to get stuck in a corner, where your only choice is to start over from scratch, or face massive rewriting?

[magicgrove]

I think that rewriting is part of learning how to do it, not sure that can be avoided. If you start small you have to rewrite less

[MageKing17]

Maybe rewriting is unavoidable, but if you want your engine done right from the start, I'd recommend a set of cards that includes as many of the following as possible:

Elspeth, Knight-Errant
Exotic Orchard
Chainer, Dementia Master (Okay, honestly, I only put him in this list because I love this card, but really, it covers a wide range of important features... for instance, were you aware that creatures brought back by Chainer trigger Dire Undercurrents? They do! They also trigger Agyrem, but nobody cares about Planar Magic )
Puncture Blast (If you have to do anything special for this card, you implemented Wither wrong)
Animate Artifact (Dependency is fun!)
Magical Hack
Sleight of Mind (With these two, keep in mind that continuous effects applying to a spell that becomes a permanent also apply to that permanent.)
Gather Specimens
Tamiyo, the Moon Sage
Worms of the Earth (There's a few tricky interactions here you may want to look up, to make sure you get them right; for instance, a Clone copying an animated man-land resolves by going to the graveyard. And speaking of Clone...)
Sakashima the Impostor
Dimir Doppelganger
Vesuvan Doppelganger
Mizzium Transreliquat
Quenchable Fire
Tempting Licid
Grab the Reins
Radiate
Eye of the Storm (If you can handle these two, I think you've got spell copies down.)

...And I'm out of ideas, but I should point out that Incantus can't handle about half of these cards, and I'm starting to doubt it will ever handle all of them without severe rewriting.

[silly freak]

Please, don't forget Mindslaver and Karn Liberated

although I don't think that you should be able to do these in the same way that magicgrove said "implement these". I would think of it as a set of cards to keep in mind, so that, although you leave out the functionality, you thing about whether it would be possible to add support for them with your current code. That's a great bunch of abstract thought, and it probably won't work perfectly, but it might save you one or two rewrites just by keeping things in mind while you gather experience.

[MageKing17]

I should have also mentioned an affinity card and a conspire card, as well as phyrexian mana, because those are all things Incantus can't do. In fact, while we're on the subject of mana...

Ancient Ziggurat
Cavern of Souls
Edgewalker
Drain Life (Yes, this is a worse card than Consume Spirit in most situations, but Consume Spirit is less complicated.)
Heartstone
Worldheart Phoenix
Fist of Suns
Celestial Dawn
Rage Extractor
Dawn's Reflection (The auto-card thing doesn't seem to like this one, so think Fertile Ground but also forcing you to let the player pick color combinations. The tricky thing here is that triggered abilities that trigger off of mana being generated and add mana themselves are actually mana abilities (yes, triggered mana abilities) and therefore don't use the stack.)

...And that's all the bizarre mana interactions I can think of off the top of my head.