I was considering designing a trading card game, as I thought it might be pretty fun, however I don't know the first thing about designing these types of games. I don't even know where to start. What I need most is some assistance on actual game mechanic design, like designing the rules of the game, win/lose conditions, and balancing the cards. The second thing I'm interested in knowing from more experienced people, is the actual programming design of the game. What would be the best method of programming the game with the intent of adding more cards later? Should I program a basic card game framework in like C#, then do actual card mechanics in Lua or Python or something? If anyone has any personal knowledge or knows of any online resources, I would love to hear it. Thanks in advanced for any help.

Quote:

Original post by Kalagaraz ...like designing the rules of the game, win/lose conditions, and balancing the cards.

Well, it'll be hard to give you too much help in these areas, as your TCG will in essence be defined by these elements. However, if you look to the popular or successful games out there (Magic, Eve, Battletech, the list goes on) you'll see a couple key points that make for balanced gameplay with room for tactics.

1) Usually there's an element of resource management/economy. This prevents the player who would build a deck out of 5 thousand cards, as they wouldn't have the ability to deploy/play all of them in any reasonable timeframe.

2) Your "combat" units should fall between two major endpoints: "paper tiger" and "rock". Think of it like a bell curve, where the majority of your combatants (if there is combat in the game, which I assume is a yes) fall in the middle of these two points, and at either end are a handful of incredibly powerful attackers and incredibly stalwart defenders.

Playtesting will tell you how to balance as you go. I'd suggest making the first ideas that come to you, play with them, and then tweak and redesign from there. Someone else in the forum said something about "design by iteration," which is incredibly sound advice.

If you want general framework for balance design though, come up with your base attributes for cards (let's say "attack, defense, and cost") and make a baseline across the board for all cards, then for each direction you push attributes for one card, push in the opposite direction for another. Let's say your baseline is a value of 2 for all three attributes: give the card pool a couple 4/4/4 cards and some 0/0/0 (like an event that modifies the game board or your hand, etc). These are arbitrary numbers for the sake of discussion however, yours will be specific to the game you end up with.

As for event cards and other "gameplay affectors", I'm sure a lot of these will come to you in the playtesting process, like "wouldn't it be fun to have a card that made us trade hands? Or that prevented all biological units from attacking, but not the mechanical ones?"

Above all, take notes as you go. The best thing about the design phase is that everything's fluid, but ideas can come at any time. I'm running around my job with an extra notebook that's half full of ideas for my project. Some are crossed out, others are expounded upon for pages and pages.

And good luck :)

Quote:

Original post by Kalagaraz I was considering designing a trading card game, as I thought it might be pretty fun, however I don't know the first thing about designing these types of games. I don't even know where to start. What I need most is some assistance on actual game mechanic design, like designing the rules of the game, win/lose conditions, and balancing the cards.

As was said before, this is the part of the game only you can design. Besides, that's the most fun! BCullis already mentioned a few good tips, but I'll try to add a few of my own.

1) As to the resources part, you could have a game with absolutely no resources. 1a) I read about the Yu-Gi-Oh card game on wikipedia, and apparently the only prerequisite for playing (normal) cards is that you can only play one per turn. 1b) I was very fond of the original Star Wars: CCG, especially because you could save up "force resource" over several turns and spend it on something big. Every turn generates force depending on the battlefields in play, so it accumulates quickly and you'll want a "sink" so that one player can't just endlessly accumulate it and win the game in one big strike. 1c) Magic: the Gathering has what I call "refreshing" resources. Each turn, you can play one land card, and each turn you have mana equal to the number of land you control. If you spend the mana, the land is "tapped" until the next turn when it is "refreshed" back to its original capacity. In this way, you can control the pace of the game more closely.

Quote:

The second thing I'm interested in knowing from more experienced people, is the actual programming design of the game. What would be the best method of programming the game with the intent of adding more cards later? Should I program a basic card game framework in like C#, then do actual card mechanics in Lua or Python or something?

Since the most interesting cards are the ones that break the rules, it might be difficult to code in special cases for everything. This is doubly true if you want to add something later that wasn't in your original design (Magic says "olol expansion packs!")

My design has primarily everything in Lua (even the main loop), and the Lua scripts only call C++ components (like the renderer or the timer) when necessary. Lua is a bit easy to hang yourself with, considering variables, types and object members can change wildly at runtime, but that flexibility is well-suited to a game of this nature.

Another good avenue to pursue is IrrLua. I haven't tried it yet, but it provides a Lua interface to the Irrlicht engine, so you'll have even less dependancy on C++. Python also has PyGame, but I <3 Lua.