Pokémon TCG mod

[☆Rei☆]

Alright, I did understand what you said there.



I prefer a signle class (PokeBattle_Effects) with different variables that will in the outcome suit every needed situation
and to make it more flexible add a custom_code segment which allows you to evaluate a custom code just for incase there are
some un-defined methods required within the effect

OR

We can do something simmilar to Essentials where we must create a code for every move (which is time more time consuming in
my opinion)

the PokeBattle_Effects class can store any type of effect: Move/Ability/Card and can be activated at selected points:
Turn Started/Turn Ended/Coin Flipped/Coin Heads/Coin Tales/Your Turn/Enemy Turn/ect. using an array you can select multiple
points to activate this at. I also did create a sample of what I mean (I only spent about 5 minutes or so on this so it's
not perfect and may seem a little confusing) but this is what I made:

Spoiler:

=begin
  This is an example of what I would do for Effects, I can make any changes you wish
  You can add to this as you wish and or modify it. If you don't like this system,
  I can completely reconstruct this to Essential's style.
=end
class PokeBattle_Effects

  attr_accessor :type            # Integer -- 0 = card, 1 = move, 2 = ability
  attr_accessor :activation_type # Integer -- when to activate the effect (0= your turn, 1= enemy's turn, 2= coin flip, 3= before attack, 4= during attack, ect.)
  attr_accessor :hold_effect     # Integer -- how many turns to hold the effect
  attr_accessor :effect          # Integer -- 0 = damage, 1 = status, and so forth
  attr_accessor :effect_attribute# Integer -- how much damage?, which status?, ect.
  attr_accessor :chance          # Integer -- Percentage chance of the succes of the effect
  attr_accessor :custom_function # String  -- A string containing ruby code on what to execute (executes every time called)
  attr_accessor :activated       # Boolean -- Is this effect active?
  attr_accessor :turns           # Integer -- Maximum turns to hold the effect (auto selected by hold_effect)
  
  # startup of the class
  def initialize(type, activation_type, effect, hold_effect = 1, custom_function = "")
    @type = type
    @activation_type = activation_type
    @effect = effect
    @hold_effect = hold_effect
    @custom_function = custom_function
    @turns = hold_effect
  end
  
  # returns wether the ability is avaible to activate
  # if it is activatable it reset the activation turns (unless already active)
  def activatable?(a_type)
    @hold_effect = @turns if @activation_type == a_type && !@activated
    @activated = true if @activation_type == a_type && !@activated
    return @activation_type == a_type
  end
  
  # returns if the effect is currently active
  def updatable?
    return @activated
  end
  
  # updates and returns an array (the length will be 1 if it did not do anything)
  def update
    @hold_effect -= 1
    destroy = @hold_effect > 0
    ret = [destroy]
    if rand(100-@chance) == 0
      ret.push(effect)
      ret.push(effect_attributes)
      ret.push(eval(@custom_function)) if @custom_function != ""
    end
    return ret
  end
    
end

also, if you are going to read data ini-style like essentials does I made a small tool for this too:

Spoiler:

=begin
  Just a handy tool for reading ini files
  
  Reads ini files and stores them in data.
  
  You can get values like so:
  ini.read_value(section(string or int), variable(string or int), default(anything))
  returns the value of the ini you set, but returns default if it does not exist
=end


class IniReader
  attr_accessor :data
  def initialize(ini)
    array = IO.readlines(ini)
    @data = {}
    startoff_section = "["
    
    section_name = ""
    section_hash = {}
    for i in 0..array.length-1
      if array[i][0] == startoff_section[0]
        if i != 0
          @data[section_name] = section_hash
        end
        section_name = array[i].split("[")[1].split("]")[0]
      elsif array[i].count("=") != 0
        tary = array[i].split("=")
        value = ""
        for i in 0..tary.length-2
          value+=tary[i+1]
        end
        section_hash[tary[0]]=value
      end
    end
    @data[section_name] = section_hash
  end
  
  def read_value(section, variable, default=-1)
    section = "#{section}"
    variable = "#{variable}"
    if @data[section][variable] == nil
      ret = default
    else
      ret = @data[section][variable]
    end
    return ret
  end
  
end


n = IniReader.new("Game.ini")
print n.read_value("Game", "Title")

so if you have a different idea or have improvements for the PokeBattle_Effects class, let me know.

 

[Maruno]

i have to apologize!
i just realized that the features i mentioned are nice and all but they are a pain to script right?
i will remove the "seen" marks from the card dex screen...
that the new cards are marked as "new" should be enough! :)
and the sorting system is unnecessary if its possible for you to make the filters you mentioned...


should the completion value shown in percent?
it would definitely look better and save some space...

Adding filters is the thing I'm not sure I'm able to do. A "seen" counter and list sorting are doable, and probably not too difficult. As I said, it's about deciding what's needed, and what people just want for the sake of wanting things. I don't think a "seen" counter is needed; you just want it because the Pokédex has it.

Completion should be in the form 86/102 rather than a percentage.

I've attached my tweaking to your design. I'm not sure about having the card icons there (which mean the same as in the GBC game; element symbols are for energy cards only), but it's a thought. I hope there's enough space for all possible card names.

yeah i meant filters! :)
they are much better then just sorting the cards...
hope you will find a way to add this feature...

filters are often used in TCG video games like "Yu-Gi-Oh! 5D's World Championship 2011" to sort your cards in your library and find the one you want to have in your deck... ^^
here is a screen:

Spoiler:

i thought we could do the library something like this...
not as complicated but the structure should look similar...
of course we have to implement the top ds screen (where the card image is) to the bottom one...
maybe make it pop up if you click a button?

That's a huge mass of information there. I notice it just has the one pocket for cards, and displays the deck in a separate tab. That's why the filters are so important in the Yu-Gi-Oh! game: all the cards are shown at once, and only 4 are visible at a time. My game will separate owned cards into pockets (and show more cards at once), which drastically reduces the huge card lists. Large lists will still be a problem, but not as soon (for example, having all cards from Base Set, Jungle and Fossil make the biggest pocket the Grass Pokémon one, with 40-odd cards, which isn't that big considering). Basically, I'm trying to ignore the issue.

One of the things to decide upon when designing the Library is which pockets to have. I've just been assuming one per Pokémon card element plus the others (see my sketch). There may be alternatives.

Another thing to remember is that the player will be using the keyboard. This will affect the design. Remember also that, if possible, the game should fit a screen size of 256x192.

The top screen in your screenshot is simply the card summary screen, which is a separate screen to be designed.

Alright, I did understand what you said there.

I prefer a signle class (PokeBattle_Effects) with different variables that will in the outcome suit every needed situation
and to make it more flexible add a custom_code segment which allows you to evaluate a custom code just for incase there are
some un-defined methods required within the effect

OR

We can do something simmilar to Essentials where we must create a code for every move (which is time more time consuming in
my opinion)

the PokeBattle_Effects class can store any type of effect: Move/Ability/Card and can be activated at selected points:
Turn Started/Turn Ended/Coin Flipped/Coin Heads/Coin Tales/Your Turn/Enemy Turn/ect. using an array you can select multiple
points to activate this at. I also did create a sample of what I mean (I only spent about 5 minutes or so on this so it's
not perfect and may seem a little confusing) but this is what I made:

Spoiler:

=begin
  This is an example of what I would do for Effects, I can make any changes you wish
  You can add to this as you wish and or modify it. If you don't like this system,
  I can completely reconstruct this to Essential's style.
=end
class PokeBattle_Effects

  attr_accessor :type            # Integer -- 0 = card, 1 = move, 2 = ability
  attr_accessor :activation_type # Integer -- when to activate the effect (0= your turn, 1= enemy's turn, 2= coin flip, 3= before attack, 4= during attack, ect.)
  attr_accessor :hold_effect     # Integer -- how many turns to hold the effect
  attr_accessor :effect          # Integer -- 0 = damage, 1 = status, and so forth
  attr_accessor :effect_attribute# Integer -- how much damage?, which status?, ect.
  attr_accessor :chance          # Integer -- Percentage chance of the succes of the effect
  attr_accessor :custom_function # String  -- A string containing ruby code on what to execute (executes every time called)
  attr_accessor :activated       # Boolean -- Is this effect active?
  attr_accessor :turns           # Integer -- Maximum turns to hold the effect (auto selected by hold_effect)
  
  # startup of the class
  def initialize(type, activation_type, effect, hold_effect = 1, custom_function = "")
    @type = type
    @activation_type = activation_type
    @effect = effect
    @hold_effect = hold_effect
    @custom_function = custom_function
    @turns = hold_effect
  end
  
  # returns wether the ability is avaible to activate
  # if it is activatable it reset the activation turns (unless already active)
  def activatable?(a_type)
    @hold_effect = @turns if @activation_type == a_type && !@activated
    @activated = true if @activation_type == a_type && !@activated
    return @activation_type == a_type
  end
  
  # returns if the effect is currently active
  def updatable?
    return @activated
  end
  
  # updates and returns an array (the length will be 1 if it did not do anything)
  def update
    @hold_effect -= 1
    destroy = @hold_effect > 0
    ret = [destroy]
    if rand(100-@chance) == 0
      ret.push(effect)
      ret.push(effect_attributes)
      ret.push(eval(@custom_function)) if @custom_function != ""
    end
    return ret
  end
    
end

Your first suggestion is meaningless, since it isn't a solution in itself but just a restating of the problem. The only relevant part is where you imply that there's only one kind of function code, which covers any and all possible effects of anything.

Basically, how do you know which effect a particular card has? You can either code in an effect which happens only when the card is XYZ, or you can define the card to have a function code and then code in an effect which happens for any card with that function code. I'm suggesting the latter, since it allows for reusing of some common card effects (e.g. "Flip a coin and paralyse the target if Heads.").

There will be an equivalent of PokeBattle_Effects, which contains some of the more common effects that can happen (e.g. paralysing a Pokémon). However, putting every single possible effect in here is pointless, as most will only be used for one card and may as well go in PokeBattle_MoveEffects under the appropriate function code.

No, I think having a PokeBattle_MoveEffects for card effects (probably one for an attack's effect and one for any other kind of effect), plus creating a PokeBattle_Move entity for each attack and effect when the card is played (and remaining while the card is still in play) is the best option I can think of. It may use elements of your code.

I'm sure I'm not explaining this fully enough, but I have a vague picture in my head. It's a complicated picture. It'd be easier if there were no effects in the game.

also, if you are going to read data ini-style like essentials does I made a small tool for this too:

Spoiler:

=begin
  Just a handy tool for reading ini files
  
  Reads ini files and stores them in data.
  
  You can get values like so:
  ini.read_value(section(string or int), variable(string or int), default(anything))
  returns the value of the ini you set, but returns default if it does not exist
=end


class IniReader
  attr_accessor :data
  def initialize(ini)
    array = IO.readlines(ini)
    @data = {}
    startoff_section = "["
    
    section_name = ""
    section_hash = {}
    for i in 0..array.length-1
      if array[i][0] == startoff_section[0]
        if i != 0
          @data[section_name] = section_hash
        end
        section_name = array[i].split("[")[1].split("]")[0]
      elsif array[i].count("=") != 0
        tary = array[i].split("=")
        value = ""
        for i in 0..tary.length-2
          value+=tary[i+1]
        end
        section_hash[tary[0]]=value
      end
    end
    @data[section_name] = section_hash
  end
  
  def read_value(section, variable, default=-1)
    section = "#{section}"
    variable = "#{variable}"
    if @data[section][variable] == nil
      ret = default
    else
      ret = @data[section][variable]
    end
    return ret
  end
  
end


n = IniReader.new("Game.ini")
print n.read_value("Game", "Title")

so if you have a different idea or have improvements for the PokeBattle_Effects class, let me know.

I've already made scripts which compile the new PBS files and access that data, so I don't think I need to muck around with any ini files. I'm not sure why you mentioned this.

 

[the__end]

I've attached my tweaking to your design. I'm not sure about having the card icons there (which mean the same as in the GBC game; element symbols are for energy cards only), but it's a thought. I hope there's enough space for all possible card names.

hmm ok i will make it similar to this... ^^
and it will be possible to few the card summary screen from the card dex screen right?
if yes the card icons are unnecessary because you can see the card types in the card summary... ^^

That's a huge mass of information there. I notice it just has the one pocket for cards, and displays the deck in a separate tab. That's why the filters are so important in the Yu-Gi-Oh! game: all the cards are shown at once, and only 4 are visible at a time. My game will separate owned cards into pockets (and show more cards at once), which drastically reduces the huge card lists. Large lists will still be a problem, but not as soon (for example, having all cards from Base Set, Jungle and Fossil make the biggest pocket the Grass Pokémon one, with 40-odd cards, which isn't that big considering). Basically, I'm trying to ignore the issue.

actually the 1873 cards shown in the screen are the cards i own... :)
the cards i dont own arent shown there...
but i understand what you mean...
if more cards are shown at once and there are less cards there is no need for that many filters right?
you are right...
this is an issue that can be talked about after it becomes a problem because it will take some time until then... ^^

One of the things to decide upon when designing the Library is which pockets to have. I've just been assuming one per Pokémon card element plus the others (see my sketch). There may be alternatives.

i will most likely add alternatives and remove them if you dont like them... :)

Another thing to remember is that the player will be using the keyboard. This will affect the design. Remember also that, if possible, the game should fit a screen size of 256x192.

the usage of the keyboard i have always in mind...
what wonders me is the screen size...
the essentials screen is 512x384 right?
i know it uses double size graphics but i didnt thought it have to use them...
is it possible to show an image with the size of 276x380 (max. card size that would fit without changing card proportions) completely in the current essentials screen?
or does it need to be half the size so the game can double it (which includes much quality loss) to show it completely?
hope i could explain what i mean...

It'd be easier if there were no effects in the game.

i dont know much about scripting but if the effects are that annoying just make a working version without effects and add the effects one after another... ^^
changing existing effects to fit with the newly added effect is maybe easier than making many effects at the same time so that they will work together...

 

[FL]

I've attached my very poor attempt at a Library screen, just so you have an idea of what I was thinking of. If you have a better layout, go for it. You'll certainly have better graphics.

I liked your idea, having the text small provides more space! I suggest you to put the horizontal type bar as a vertical bar to a better use of this space, and, maybe, remove the pokémon level.

No, I think having a PokeBattle_MoveEffects for card effects (probably one for an attack's effect and one for any other kind of effect), plus creating a PokeBattle_Move entity for each attack and effect when the card is played (and remaining while the card is still in play) is the best option I can think of. It may use elements of your code.

I thought in something like this.

hmm ok i will make it similar to this... ^^
and it will be possible to few the card summary screen from the card dex screen right?
if yes the card icons are unnecessary because you can see the card types in the card summary... ^^

I like theses icons, but do a color revamp.

One of the things to decide upon when designing the Library is which pockets to have. I've just been assuming one per Pokémon card element plus the others (see my sketch). There may be alternatives.

Put one pocket for each subtype and one for "All". For others, use search filters.


I suggest you to take a look in the online game Dueling Network to gather ideas/concepts.

 

[Maruno]

hmm ok i will make it similar to this... ^^
and it will be possible to few the card summary screen from the card dex screen right?
if yes the card icons are unnecessary because you can see the card types in the card summary... ^^

Of course it will be possible to view the card details screen from the Card Dex. I just thought the icons might make the screen look a bit less dull. There's also the possibility of including the rarity icons somewhere, and/or colouring in card names depending on their rarity.

the usage of the keyboard i have always in mind...
what wonders me is the screen size...
the essentials screen is 512x384 right?
i know it uses double size graphics but i didnt thought it have to use them...
is it possible to show an image with the size of 276x380 (max. card size that would fit without changing card proportions) completely in the current essentials screen?
or does it need to be half the size so the game can double it (which includes much quality loss) to show it completely?
hope i could explain what i mean...

Yes, Essentials has a 512x384 screen. However, it also has the option of halving this, and playing at 256x192, which means if graphics aren't made to suit this smaller size, they'll look odd when they're shrunk. I know, only a prat would play at the smaller size, but I'd still like for the screens to suit those dimensions if possible.

You're still assuming that the card information screen will be nothing more than displaying a screen-filling image of the entire card at once. That screen's design hasn't been decided yet.

I liked your idea, having the text small provides more space! I suggest you to put the horizontal type bar as a vertical bar to a better use of this space, and, maybe, remove the pokémon level.

I like theses icons, but do a color revamp.

Put one pocket for each subtype and one for "All". For others, use search filters.

The text is only that small because I ripped it straight from a screenshot of the GBC game, just for the sake of demonstration. All text will be regular size and font unless otherwise necessary. The same goes for the icons. I'm bad at creating graphics.

The pocket icons in the Library only just fit horizontally. They probably won't fit vertically, and even if they did, they would take up valuable horizontal space which could be used for displaying long card names (I'd like to know what the longest card name is).

You don't seem to understand how pockets work. The pockets physically exist, with cards physically inside each of them; they're not a filter on one big list of cards. A particular card cannot appear in multiple pockets. I don't even think there's any need at all for an "All cards" pocket.

 

[Awkward Squirtle]

I have a couple of suggestions.

First, ditch the deck editing layout from the Game Boy game. It's a real pain to work with to make decks - you can't see your actual decklist anywhere while editing. This makes stuff like adding energy cards to the deck annoying, since you don't have a list of how many Pokémon of each type you're using.

Since this is going to only be playable on a PC, you should make use of its advantages. For example, use RMXP's full resolution instead of the DS's tiny screen size - you'll be able to fit more on the screen, and card images will be easier to read. Also, try to implement mouse controls; it's much easier just to hover your mouse over a card to see what it does, or drag it to move it between your library and your deck, than to use the keyboard for the same things.

Take a look at some PC versions of TCGs and how their interfaces work. Figure out their problems and how to fix them; use the things that work in your own game. For example, the ones I've played show both your library and your decklist at the same time on the deck editing screen, side by side. They also allow you to filter the list of visible cards in various ways, such as by card type or expansion set. Filtering in particular I don't think I could live without; I know you want to organise the cards into pockets, but what if I want to find a Stage 1 Pokémon capable of doing at least 80 damage with one attack, regardless of type? With your plan, I'd have to manually search through hundreds, possibly thousands, of cards.

I second the 'recipes' suggestion. The main thing I didn't like about the Game Boy game was that if I wanted to use my Double Colorless Energy cards in a new deck, I'd have to remove them from the deck that's using them first; a waste of time, especially since I'd have to move them back if I wanted to go back to that deck.
Discarding/trading/etc cards isn't a big problem - after each discard/trade/etc, go through each decklist, and if they contain any cards in a greater quantity than you actually have, fix it. This means you can trade cards that are currently in a deck too, which is a nice thing to be able to do.

In regards to acquiring cards, I think it would be best to let the developer decide whether to use currency or just get cards after winning. On the note of acquiring cards, please implement a switch that gives the player access to unlimited quantities of every card in the game, or at least a command that gives the player 4 of each card (and 60 of each Basic Energy/Arceus card). Some people want to earn their cards themselves, while others (like me) just want to build decks. I understand if you don't want to put this in, though!

I would try to simulate the card game as closely as possible, so things like Pokémon Powers and Abilities would stay as they are. It wouldn't be impossible for someone using the kit to change this if they wanted to.

I made a small start in implementing a Pokémon TCG system, and one of the things I found troublesome was deciding whether you have enough Energy to use an attack. With only Basic Energy cards or only single-type attack costs, this is easy. But once you start to include attacks that require multiple types and Energy cards that provide several types, it's a bit trickier. For example, say your Pokémon has a Rainbow Energy and a Darkness Metal Energy attached, and you want to use an attack that costs 1 Darkness and 1 Fire. A human player will tell you it's OK, but a computer will need to figure out that the Rainbow Energy must be used as the Fire requirement rather than the Darkness requirement. I haven't really thought about it that much; can you figure something out?

 

[FL]

The text is only that small because I ripped it straight from a screenshot of the GBC game, just for the sake of demonstration. All text will be regular size and font unless otherwise necessary. The same goes for the icons. I'm bad at creating graphics.

The pocket icons in the Library only just fit horizontally. They probably won't fit vertically, and even if they did, they would take up valuable horizontal space which could be used for displaying long card names (I'd like to know what the longest card name is).

If the longest card have a great name (like more than 40 characters), consider putting "..." in some card names that have more that 20-30 characters, with full name restricted to card details.

You don't seem to understand how pockets work. The pockets physically exist, with cards physically inside each of them; they're not a filter on one big list of cards. A particular card cannot appear in multiple pockets. I don't even think there's any need at all for an "All cards" pocket.

I know this, but if you have only type filters (yes, I know that this is an example), this have the same effect. Please note that is very easy to get lost with a huge number of cards, several filters are necessary.

 

[the__end]

Yes, Essentials has a 512x384 screen. However, it also has the option of halving this, and playing at 256x192, which means if graphics aren't made to suit this smaller size, they'll look odd when they're shrunk. I know, only a prat would play at the smaller size, but I'd still like for the screens to suit those dimensions if possible.

You're still assuming that the card information screen will be nothing more than displaying a screen-filling image of the entire card at once. That screen's design hasn't been decided yet.

well cards cant be made to suit the smaller size without losing important details...
and this kit should be compatible with essentials and not copy anything essentials has right? ^^
imo this kit should have the screen size of 512x384 and if people want to add this kit to essentials they have to use essentials at 512x384 screen size as well...

and i dont assume that only the cards will be displayed on the card info screen...
if we insert the cards on the right (or left) side of the info screen in the size i suggested there will be enough space (almost half of the screen) where more stuff can be written/shown/added...

Since this is going to only be playable on a PC, you should make use of its advantages. For example, use RMXP's full resolution instead of the DS's tiny screen size - you'll be able to fit more on the screen, and card images will be easier to read. Also, try to implement mouse controls; it's much easier just to hover your mouse over a card to see what it does, or drag it to move it between your library and your deck, than to use the keyboard for the same things.

you forget that this kit will be compatible with essentials...
so adding full screen and mouse control will most likely not implemented...

They also allow you to filter the list of visible cards in various ways, such as by card type or expansion set. Filtering in particular I don't think I could live without; I know you want to organise the cards into pockets, but what if I want to find a Stage 1 Pokémon capable of doing at least 80 damage with one attack, regardless of type? With your plan, I'd have to manually search through hundreds, possibly thousands, of cards.

i agree with you that filters are important but i think adding them at the beginning of the kit would make things more complicated then they need to be... ^^

If the longest card have a great name (like more than 40 characters), consider putting "..." in some card names that have more that 20-30 characters, with full name restricted to card details.

for to long names using a smaller font would be the best way to solve the problem...

 

[Maruno]

First, ditch the deck editing layout from the Game Boy game. It's a real pain to work with to make decks - you can't see your actual decklist anywhere while editing. This makes stuff like adding energy cards to the deck annoying, since you don't have a list of how many Pokémon of each type you're using.

If you have a better design in mind, show me. Don't just say "I don't like this design" without offering an alternative. For the one specific gripe you mentioned, a number next to each pocket's icon could indicate how many cards in that pocket are in one's deck.

Since this is going to only be playable on a PC, you should make use of its advantages. For example, use RMXP's full resolution instead of the DS's tiny screen size - you'll be able to fit more on the screen, and card images will be easier to read. Also, try to implement mouse controls; it's much easier just to hover your mouse over a card to see what it does, or drag it to move it between your library and your deck, than to use the keyboard for the same things.

You're missing the point that I'm making this as an add-on to Essentials (because it has useful code I want to use). I'm restricted by what Essentials does (i.e. screen size, no mouse). If you're suggesting that I turn it into a standalone project, then say so. And if that's the case, I might as well make it in Java or something free and even less restrictive, and etc. etc. I need to stop somewhere, and all I know is Essentials, so it might as well be there.

If there's an existing project I can contribute to instead, let me know and I'll consider jumping ship.

Take a look at some PC versions of TCGs and how their interfaces work. Figure out their problems and how to fix them; use the things that work in your own game. For example, the ones I've played show both your library and your decklist at the same time on the deck editing screen, side by side. They also allow you to filter the list of visible cards in various ways, such as by card type or expansion set. Filtering in particular I don't think I could live without; I know you want to organise the cards into pockets, but what if I want to find a Stage 1 Pokémon capable of doing at least 80 damage with one attack, regardless of type? With your plan, I'd have to manually search through hundreds, possibly thousands, of cards.

Why would you ever need to search for such a card? The way I understand the card game, you make decks based around elements, so having Pokémon cards arranged by element is a good start. I've already said I want to ignore anything further than that for now.

Please bear in mind that I'm not a genius who can just whip up anything he wants but is choosing to restrict himself just for the sake of it. I'm lacking in many areas of knowledge, and any restrictions I have are to make my life easier and to avoid areas I know I'm not capable of tackling. I don't have experience with filters or list sorting.

Once again, if you can think of a better system, show it to me rather than make offhanded comments along the lines of "system X is better because of a vaguely described feature whose relevance and importance to your project isn't even explained or justified".

I second the 'recipes' suggestion. The main thing I didn't like about the Game Boy game was that if I wanted to use my Double Colorless Energy cards in a new deck, I'd have to remove them from the deck that's using them first; a waste of time, especially since I'd have to move them back if I wanted to go back to that deck.
Discarding/trading/etc cards isn't a big problem - after each discard/trade/etc, go through each decklist, and if they contain any cards in a greater quantity than you actually have, fix it. This means you can trade cards that are currently in a deck too, which is a nice thing to be able to do.

Decks are already recipes. You cannot get rid of a card if it is being used in a deck. A deck is not allowed to be incomplete, for simplicity.

In regards to acquiring cards, I think it would be best to let the developer decide whether to use currency or just get cards after winning. On the note of acquiring cards, please implement a switch that gives the player access to unlimited quantities of every card in the game, or at least a command that gives the player 4 of each card (and 60 of each Basic Energy/Arceus card). Some people want to earn their cards themselves, while others (like me) just want to build decks. I understand if you don't want to put this in, though!

I would try to simulate the card game as closely as possible, so things like Pokémon Powers and Abilities would stay as they are. It wouldn't be impossible for someone using the kit to change this if they wanted to.

I'd rather have something that exists and works first, before trying to cater to people just wanting a duel simulator. I don't think I ever would anyway, because that's not a game and it's not what I want to make.

Of course it will work as much like the TCG as possible; otherwise there's no point saying it's a TCG-based game.

I made a small start in implementing a Pokémon TCG system, and one of the things I found troublesome was deciding whether you have enough Energy to use an attack. With only Basic Energy cards or only single-type attack costs, this is easy. But once you start to include attacks that require multiple types and Energy cards that provide several types, it's a bit trickier. For example, say your Pokémon has a Rainbow Energy and a Darkness Metal Energy attached, and you want to use an attack that costs 1 Darkness and 1 Fire. A human player will tell you it's OK, but a computer will need to figure out that the Rainbow Energy must be used as the Fire requirement rather than the Darkness requirement. I haven't really thought about it that much; can you figure something out?

I store attack costs in an array (e.g. [Fire,Fire,Colorless]). When checking whether a cost can be met, I would create a "cost pool" from this, and an "energy pool" from the attached energies (Rainbow counts as Rainbow for now, but some other energy-providing effects are counted). I would then delete energy pairs from each pool. From what's left in the cost pool, remove one per Rainbow energy (this is the final step; other Energy cards like Blend Energy should be considered before it, as they're more limited). In the end, if the cost pool is empty, you can afford it.

It's just a matter of considering the most restricted energy providers first (Fire Energy can only provide 1 Fire) and the least restricted last (Rainbow can provide 1 anything).

For attack effects along the lines of "+10 damage per attached Water energy not used to pay for this attack", that amount could probably be calculated afterwards, using what's left in the energy pool.

If the longest card have a great name (like more than 40 characters), consider putting "..." in some card names that have more that 20-30 characters, with full name restricted to card details.

I know this, but if you have only type filters (yes, I know that this is an example), this have the same effect. Please note that is very easy to get lost with a huge number of cards, several filters are necessary.

It's quicker to start with pockets as I've described than to apply a filter you're probably going to use anyway.

I'm still ignoring filters for now, anyway.

well cards cant be made to suit the smaller size without losing important details...
and this kit should be compatible with essentials and not copy anything essentials has right? ^^
imo this kit should have the screen size of 512x384 and if people want to add this kit to essentials they have to use essentials at 512x384 screen size as well...

and i dont assume that only the cards will be displayed on the card info screen...
if we insert the cards on the right (or left) side of the info screen in the size i suggested there will be enough space (almost half of the screen) where more stuff can be written/shown/added...

You could still have the big graphics, but show only the top or bottom half at once (like in Asobikata but alternating/scrolling between its two screens). That's an example of how to overcome your concern; whether it's a good design or not is irrelevant, because it's a design you didn't suggest (proving that you're still stuck on the idea of the entirety of the card being shown at once). Think outside the box and consider all possibilities, even bad ones.

 

[the__end]

You could still have the big graphics, but show only the top or bottom half at once (like in Asobikata but alternating/scrolling between its two screens). That's an example of how to overcome your concern; whether it's a good design or not is irrelevant, because it's a design you didn't suggest (proving that you're still stuck on the idea of the entirety of the card being shown at once). Think outside the box and consider all possibilities, even bad ones.

well you won... ^^
i just told you my opinion of the easiest way to show the cards with the best possible quality...
but if you think that there is a better way or that someone will find a better way its fine with me... ^^

and it would work only limited if you "cut" the cards in two halves because you just considered the height of the screen...
the half card would take the complete width of the screen (it dont even fit completely) without leaving space to add anything else...
i know that you are just giving examples for showing me that there could be alternative ways...
but imo there arent without giving up on other things...

 

[☆Rei☆]

Your first suggestion is meaningless, since it isn't a solution in itself but just a restating of the problem. The only relevant part is where you imply that there's only one kind of function code, which covers any and all possible effects of anything.

Basically, how do you know which effect a particular card has? You can either code in an effect which happens only when the card is XYZ, or you can define the card to have a function code and then code in an effect which happens for any card with that function code. I'm suggesting the latter, since it allows for reusing of some common card effects (e.g. "Flip a coin and paralyse the target if Heads.").

There will be an equivalent of PokeBattle_Effects, which contains some of the more common effects that can happen (e.g. paralysing a Pokémon). However, putting every single possible effect in here is pointless, as most will only be used for one card and may as well go in PokeBattle_MoveEffects under the appropriate function code.

No, I think having a PokeBattle_MoveEffects for card effects (probably one for an attack's effect and one for any other kind of effect), plus creating a PokeBattle_Move entity for each attack and effect when the card is played (and remaining while the card is still in play) is the best option I can think of. It may use elements of your code.

I'm sure I'm not explaining this fully enough, but I have a vague picture in my head. It's a complicated picture. It'd be easier if there were no effects in the game.

I guess it's best for you to do this, I do know the basis of what you mean though and I think a full explanation would be helpful for me.

I've already made scripts which compile the new PBS files and access that data, so I don't think I need to muck around with any ini files. I'm not sure why you mentioned this.

The basis of the Pokemon.txt is built in the manor of an ini, and I do not recall ruby having an ini loader. I just thought that it would provide some use.

 

[Awkward Squirtle]

Firstly, I apologise for forgetting this is an extension to Essentials - it slipped my mind when I was writing the reply.

Here's a layout I quickly threw up for the deck edit screen:

You can see the deck contents in the right pane, and switch between deck and library panes with a key press (ideally with a smooth slide animation).
There's still probably a lot missing, but you get the idea. 256x192 isn't much to work with :/

You don't necessarily make a deck based around a type. Sure, it's the easiest way, and starting players will probably do that. But more advanced players might want to make decks based around other things than type.
For example, the most popular (and powerful) deck back when the TCG was new was based around strong basic Pokémon that had efficiently-costed attacks (e.g. Hitmonchan, a 70HP Pokémon that deals 20 damage for a single Energy, or Electabuzz, capable of paralysing opponents with just a single Energy and dealing 40 damage with two).
It would be useful to have some sort of filtering function for this kind of thing.

Define a simple set of filters, such as type and evolutionary stage, and allow multiple filters (of different types) to be on at once. And allow sorting by values such as HP, attack damage, or even Pokédex number. That should be enough to satisfy the majority of players.

I would personally allow people to have incomplete decks, as long as they have at least one complete deck to use. Surely it can't be difficult to implement a check for this/automatically switch to a complete deck if cards are removed from the current deck?

In regards to Energy costs, you're proposing a greedy algorithm (always choose the most limited Energy first). This won't necessarily work. Imagine you have an attack that costs [Metal, Darkness], and your attached energies are [BlendWLFM, DarknessMetal]. Using the greedy algorithm, you'd match DarknessMetal first, and match it with the first cost (Metal). Then, you'd pair BlendWLFM with Darkness, and what do you know, it doesn't match. You might say "well then, you'd start by pairing DarknessMetal to Darkness". But how does the game know to do this? Once you have a method that you think works, can you prove it works, for all possibilities?
Anyway, I have a suggestion on the same topic in regards to 'optional' Energy costs (e.g. Secret Wonders Blastoise's Hydro Pump). I'd give such attacks a preference as to what Energy should be left over (alternatively what Energy should be used for the attack). Blastoise's Hydro Pump should prioritise keeping Water Energy aside for its effect. If you just used the greedy algorithm, a Blastoise with 3 Water Energy and a Blend Energy GFPD would assign the 3 Waters to the main cost, leading to a 50 damage attack (when it could have done 70).

Filters/sorting in Ruby/RGSS are both really easy. You can use code blocks to supply sort/filter criteria to Ruby's built-in methods. For example, this code sorts a list of cards by HP (the <=> method returns -1, 0, or 1 depending on the results of comparing the left value with the right value, used by the sort method):

sortedList = cardList.sort {|a, b| a.hp <=> b.hp}

And this filters out only stage 2 cards:

stage2 = cardList.find_all {|card| card.stage == Stage2}

If you don't have experience with something, it's an opportunity to expand your skills in that area. Don't just say "I don't know how to do it, so it's not happening" ;)

 

[Maruno]

I guess it's best for you to do this, I do know the basis of what you mean though and I think a full explanation would be helpful for me.

I would need to have made half the battle system before I figured out enough details to let me explain it fully. I'm mainly going on instinct at the moment.

There's so much that could go on at once in a battle that it's very off-putting. And that's not even considering the AI, which is a topic I will absolutely avoid at all costs. I'm starting to wonder if it would be easier to make it a network play-only game instead (i.e. play against other people online rather than a computer, which is also very complicated which is my point).

Firstly, I apologise for forgetting this is an extension to Essentials - it slipped my mind when I was writing the reply.

Here's a layout I quickly threw up for the deck edit screen:

You can see the deck contents in the right pane, and switch between deck and library panes with a key press (ideally with a smooth slide animation).
There's still probably a lot missing, but you get the idea. 256x192 isn't much to work with :/

You don't necessarily make a deck based around a type. Sure, it's the easiest way, and starting players will probably do that. But more advanced players might want to make decks based around other things than type.
For example, the most popular (and powerful) deck back when the TCG was new was based around strong basic Pokémon that had efficiently-costed attacks (e.g. Hitmonchan, a 70HP Pokémon that deals 20 damage for a single Energy, or Electabuzz, capable of paralysing opponents with just a single Energy and dealing 40 damage with two).
It would be useful to have some sort of filtering function for this kind of thing.

Define a simple set of filters, such as type and evolutionary stage, and allow multiple filters (of different types) to be on at once. And allow sorting by values such as HP, attack damage, or even Pokédex number. That should be enough to satisfy the majority of players.

I would personally allow people to have incomplete decks, as long as they have at least one complete deck to use. Surely it can't be difficult to implement a check for this/automatically switch to a complete deck if cards are removed from the current deck?

I think the small screen size is too limiting after all, considering what it needs to show.

Obviously the design of the Library (and other screens) needs a lot of work. That's probably why games have whole teams of designers who know what they're doing, and we... don't.

I'd still like for some segregation in the Library, though, even if I dismiss the many-pockets interpretation (subtle physics pun). Surely you couldn't object to keeping Trainers/Energies/Pokémon cards separate? For one, it'd make filters easier.

Allowing incomplete decks is a can of worms. What if you sell a card that was used in every one of your complete decks, thus making them all incomplete? What if you toss cards so you only have 59 left, and aren't able to gain any new ones? You'll say that such situations are rare/unlikely, or the user's fault (which is true), or that the game should forbid the losing of a card were this to happen (in which case, it's easy to extrapolate this argument to come up with "no incomplete decks allowed" which is what I've done). If you suggest that a deck which becomes incomplete like this should be filled in with a random card from the Library just to keep it complete, what about if there are no cards which can legally be added to it? Again, unlikely, but still a can of worms.

In regards to Energy costs, you're proposing a greedy algorithm (always choose the most limited Energy first). This won't necessarily work. Imagine you have an attack that costs [Metal, Darkness], and your attached energies are [BlendWLFM, DarknessMetal]. Using the greedy algorithm, you'd match DarknessMetal first, and match it with the first cost (Metal). Then, you'd pair BlendWLFM with Darkness, and what do you know, it doesn't match. You might say "well then, you'd start by pairing DarknessMetal to Darkness". But how does the game know to do this? Once you have a method that you think works, can you prove it works, for all possibilities?
Anyway, I have a suggestion on the same topic in regards to 'optional' Energy costs (e.g. Secret Wonders Blastoise's Hydro Pump). I'd give such attacks a preference as to what Energy should be left over (alternatively what Energy should be used for the attack). Blastoise's Hydro Pump should prioritise keeping Water Energy aside for its effect. If you just used the greedy algorithm, a Blastoise with 3 Water Energy and a Blend Energy GFPD would assign the 3 Waters to the main cost, leading to a 50 damage attack (when it could have done 70).

This is what I was saying earlier in this post about too many things going on at once. The simplest way out would be for the player to manually choose which cards are used for each part of the cost, but obviously this isn't appealing. No, I tell a lie: the simplest way out would be to not include difficult cards, but I'm sure people would complain about that.

One option would be to simulate all possible combinations of energy that the attached energy could provide, and check each of those against the cost. This would also work for Blastoise's effect, whereby each (cost-meeting) combination has the cost subtracted and the game accepts the result which has the most Water energy left over. This initially strikes me as rather inefficient (moreso for higher numbers of Colorless in the cost), but actually might not be so bad (and it'd be much easier to code than any "preference" method). It's not as though this needs to be calculated that often (once per turn at most).

Filters/sorting in Ruby/RGSS are both really easy. You can use code blocks to supply sort/filter criteria to Ruby's built-in methods. For example, this code sorts a list of cards by HP (the <=> method returns -1, 0, or 1 depending on the results of comparing the left value with the right value, used by the sort method):

sortedList = cardList.sort {|a, b| a.hp <=> b.hp}

And this filters out only stage 2 cards:

stage2 = cardList.find_all {|card| card.stage == Stage2}

If you don't have experience with something, it's an opportunity to expand your skills in that area. Don't just say "I don't know how to do it, so it's not happening" ;)

The Pokédex includes filters, and some menus in Essentials have sorting in them (usually alphabetical). I know I could figure something out. I just wanted to make sure it was necessary before I devoted any time to it (which I'm still not convinced of). Figuring out how to incorporate it into the designs is a big task, and it's an important part of the code.

I'm not doing this game because I want to expand my horizons and skills (if I were, I'd learn C++ or another useful language to do it in). I just thought it'd be nice if something like this existed for RMXP, and I was in the mood to play around. Not knowing how to do something is a valid excuse for me, particularly if it's something that obviously needs a lot of learning to achieve - I have other things to do.

 

[Awkward Squirtle]

Please don't make the TCG network-play only before implementing proper network play for the main game :P

A simple AI isn't impossible to code. Make it attach Energy to Pokémon that don't have enough (prioritising the Active Pokémon), use the attack that does the most damage (ideally, program attack effects to influence this, as in poccil's battle AI), and use Trainer cards when appropriate (vague, but there are a ton of effects you'd have to consider individually).
A more advanced AI would consider longer-term effects and what the opponent can do (for example, only using a Potion if it would actually save their Pokémon), and use tactics like attaching extra Energy to an unevolved Pokémon to prepare it for its evolved form. Of course, the latter would also require the AI to know how the components of its deck interact, so it might be a little ambitious.

Hmm... Thinking about the interface a bit more, maybe a horizontal layout could work for the deck edit screen? If the small card images are clear enough, you have more horizontal space to fit cards onto the screen. But then you can't really have much info in the card list.
Horizontal for the deck, vertical for your card library maybe?

Why does not letting the player sell/trade cards that would cause them to have no legal decks extrapolate to not letting them have any illegal decks whatsoever?
It's useful to have incomplete decks. For example, if I'm working on acquiring cards to make a Blastoise deck, I want to be able to make an incomplete Blastoise deck to see what cards I still need to get, rather than having to fill the rest in with pointless cards (I won't be playing the deck until it's complete anyway).
And some random code you might find useful:

def hasLegalDeckAfterRemoving(card, quantityToRemove)
  quantity = library.quantity(card) - quantityToRemove
  for deck in decks
    if deck.quantity(card) <= quantity
      return true
    end
  end
  return false
end

Brute-forcing Energy costs would certainly work, but as you say, it would be inefficient. If you have m Energy attached, and an attack needs n Energy, you need to check n permutations of m Energy. I don't know of any attacks that have a total cost of more than 5, and realistically I don't think anyone will be attaching more than 10 Energy to a Pokémon. But that still leaves over 30000 ways you could pair them up.
Duplicate attached Energy reduces the actual number of unique permutations, so you can skip those. You can also define attacks to not care about Energy ordering (for example, any attack that only uses one type of Energy and doesn't do anything with the leftover Energy should be correctly catered to with the greedy approach).

Finally, as a side note, Ruby is no less useful than C++ - a language doesn't have to be hyper-efficient to be useful. I know C++, but still use Ruby a lot. Its versatile syntax that lets you do things like the one-line sort/filters above, and not requiring compilation, makes it good when you just want to get stuff done :P

 

[Maruno]

A simple AI isn't impossible to code. Make it attach Energy to Pokémon that don't have enough (prioritising the Active Pokémon), use the attack that does the most damage (ideally, program attack effects to influence this, as in poccil's battle AI), and use Trainer cards when appropriate (vague, but there are a ton of effects you'd have to consider individually).
A more advanced AI would consider longer-term effects and what the opponent can do (for example, only using a Potion if it would actually save their Pokémon), and use tactics like attaching extra Energy to an unevolved Pokémon to prepare it for its evolved form. Of course, the latter would also require the AI to know how the components of its deck interact, so it might be a little ambitious.

Making the computer do something isn't so hard. Making it do something logical (i.e. don't attach worthless energies) is harder. Making it look like it knows what it's doing is very much a difficult task.

Hmm... Thinking about the interface a bit more, maybe a horizontal layout could work for the deck edit screen? If the small card images are clear enough, you have more horizontal space to fit cards onto the screen. But then you can't really have much info in the card list.
Horizontal for the deck, vertical for your card library maybe?

Horizontal in what sense? The sense that, in your drawing of the Deck Editor, the cards in the deck are drawn vertically?

I have a bit of an idea for a design. It looks a lot like that Yu-Gi-Oh! screenshot posted earlier, but with the "pocket" tabs at the top rather than the bottom, and the filter bar at the bottom. When deck-building, there would be an extra "pocket" tab for the deck - you couldn't see both it and the Library at once, but you could at least see it at all.

Why does not letting the player sell/trade cards that would cause them to have no legal decks extrapolate to not letting them have any illegal decks whatsoever?
It's useful to have incomplete decks. For example, if I'm working on acquiring cards to make a Blastoise deck, I want to be able to make an incomplete Blastoise deck to see what cards I still need to get, rather than having to fill the rest in with pointless cards (I won't be playing the deck until it's complete anyway).

Because it makes more sense to the average player to use absolutes. You can either lose cards without restriction, or you can't do anything to a card already in use. It's simpler to understand than "do what you want except for a few cases which are hard to spot and are seemingly random".

If you're placing restrictions on how the player can lose cards, and you must place at least some, then it's both simpler to code and simpler to understand if you "round it off" to the nearest absolute. I honestly don't think this will cause a problem, and it's just you being picky.

Forbidding incomplete decks also makes things simpler to deal with, from my perspective (which is the only one I've got). I've not thought about this too much yet, though.

Brute-forcing Energy costs would certainly work, but as you say, it would be inefficient. If you have m Energy attached, and an attack needs n Energy, you need to check n permutations of m Energy. I don't know of any attacks that have a total cost of more than 5, and realistically I don't think anyone will be attaching more than 10 Energy to a Pokémon. But that still leaves over 30000 ways you could pair them up.
Duplicate attached Energy reduces the actual number of unique permutations, so you can skip those. You can also define attacks to not care about Energy ordering (for example, any attack that only uses one type of Energy and doesn't do anything with the leftover Energy should be correctly catered to with the greedy approach).

It's not combinatorial. In my game, an attack's cost pool will be an array like [0,1,0,0,0,2] (meaning 1 Fire + 2 Colorless), and the available energy pool will be a similar-looking array (i.e. they don't depend on the order in which the cost is listed/the energies are attached). If you only have basic energies attached, there will only be one possible energy pool array, so only one comparison to make. Adding a Blend energy makes it 4 possible arrays to check in turn.

What can/should be done with Rainbow energy is to treat them separately and deal with them last. Checking the remnants of a cost against available Rainbow energies is as simple as counting them. For special effects such as counting a particular energy surplus, a Rainbow energy would automatically be +1 at the end. Similar effects can deal with Rainbow energies however they want/need, and will do so in those effects' function codes only.

Thus, the only cards able to multiply the number of possible energy pool arrays is very limited (5 by my count), and they all either double, triple or quadruple the possibilities only. This makes the number of energy pool combinations equally very limited, and very much acceptable.

Finally, as a side note, Ruby is no less useful than C++ - a language doesn't have to be hyper-efficient to be useful. I know C++, but still use Ruby a lot. Its versatile syntax that lets you do things like the one-line sort/filters above, and not requiring compilation, makes it good when you just want to get stuff done :P

Ruby's fine and all, but knowledge of other languages would be nice. I don't know any others, and if I were to start a project whose aim is to improve my abilities (which this project isn't), then I'd go for C++ or Python. I don't often see Ruby being mentioned 'round the Tubes (not as often as C++, anyway).

 

[Pharetra]

Coding an AI is not something I'd do. It will take so many time that can be spent way better. Players have to think ahead of the game, predict what their opponent is going to do and make strategical choices. I don't know if these can be done by the AI, but I am sure it will not be flawless and it will take a lot of time. A good example can be found on pokemontcg.com, the official online simulator of the Pokémon TCG. The AI there is bad if not terrible.

 

[☆Rei☆]

I know a small basis of coding AIs I have done it before in GM for an RTS test and currently a platformer for interactions with items such as vehicles, ladders, weapons, ect. This seems a little more complicated as I barely know the rules of the TCG, I might attempt a small basis after I learn the rules fully, and alongside of that I am pretty well in RTS games so thinking of good combos for more advanced AIs will be easy for me. I will take a look at the rules again and I will make a demo of what I can make.

 

[Maruno]

I've knocked up a new design for the Library (still in small screen mode, but it works well enough like that). See attached. The deck tab (the grey one at the top right) is only shown during deck-building, and the name/numbers at the top would be changed to the deck's name/size at the same time (and a number put in each tab to show quantities of its cards in the deck). The filter buttons need redesigning to show suitable options (which will be different in each tab, and probably missing altogether in the Energy tab). The colour scheme also needs changing. I'm not sure whether icons-only is a good idea; even if it looks nice, the clarity/meaning may suffer.

As for navigation, when you enter it you'll be at the "top", where you can switch between tabs. Pressing C dives you into the current tab to scroll through the cards within. Pressing Z while in a tab puts your cursor onto the filter icons at the bottom, most of which will show pop-up menus upon pressing C containing the appropriate filter options therein - pressing C therein toggles a filter. The list updates automatically after any filter is toggled. There will be a "cancel all filters" button. Filters will be persistent, even after closing the Library (unless we decide they should only be persistent while in the Library screen instead). Pressing X, of course, goes back. List sorting will always be in alphabetical order.

If mouse support ever gets into this thing, this design fully supports it.

Coding an AI is not something I'd do. It will take so many time that can be spent way better. Players have to think ahead of the game, predict what their opponent is going to do and make strategical choices. I don't know if these can be done by the AI, but I am sure it will not be flawless and it will take a lot of time. A good example can be found on pokemontcg.com, the official online simulator of the Pokémon TCG. The AI there is bad if not terrible.

Thanks for your words of support. :cheeky:

I know a small basis of coding AIs I have done it before in GM for an RTS test and currently a platformer for interactions with items such as vehicles, ladders, weapons, ect. This seems a little more complicated as I barely know the rules of the TCG, I might attempt a small basis after I learn the rules fully, and alongside of that I am pretty well in RTS games so thinking of good combos for more advanced AIs will be easy for me. I will take a look at the rules again and I will make a demo of what I can make.

The big challenge will be to make the computer "look ahead" and make plans. It's not so bad if you just want it to react to what's there right now. As for actual strategies, that's way out there.

If possible, I'd like to not have the AI do things in an ordered manner (i.e. always play Pokémon first and always play trainers last). However, that would be complicated.

Maybe this is how Skynet will begin...

 

[☆Rei☆]

The big challenge will be to make the computer "look ahead" and make plans. It's not so bad if you just want it to react to what's there right now. As for actual strategies, that's way out there.

If possible, I'd like to not have the AI do things in an ordered manner (i.e. always play Pokémon first and always play trainers last). However, that would be complicated.

"look ahead" plans are things which I don't plan on adding immediately but I do have ideas for. I can make simple algorithms quickly by using a series of checks on some obvious info then the minor info lastly, afterwards we determine what is best to put out (if we can place anything) and then do so.

So the ordered manner will not be looked at, also if needed I will add a custom Pseudo-Random algorithm to determine if something really needs the random attribute (I won't use 'rand' as it can be very un-predicting if you want smooth layouts.)

Also, strategies can be pre-determined as of trying to follow along the lines of a generated strategy made after the AI draws the cards and recalculating small portions of it per visible action (unless by chance the AI draws the desired card it wants)
Oh yes, I am reading a long pdf on the rules, I should be done soon but memorizing it all will take a few hours more, and finally playout strategies will take a few days or so. Afterwards all that has been finished I will startup on the AI system. (I am looking in about a week)

Maybe this is how Skynet will begin...

If I remember right, Terminator? I'm not THAT experienced with AIs

 

[TheDarkShark]

I'm not THAT experienced with AIs

Unless someone comes up with an even more revolutionary paradigma than object orientation, I doubt anyone will ever get to that an AI that powerfull. Even though, of course, it will always be broke down to ASM code, but let's not discuss realism in Holywood movies right now, 'kay?
I'm not an expert on AI, and certainly not Ruby, so I won't be much help here, sorry.

First, concerning the toss-cards-in-your-deck-problem: I've never played the Pokémon TCG very much, but I used to play Yu-Gi-Oh! a lot, so I can speak from experience here. We (I and most my friends I played with, that is) used to keep deck-lists, recipes if you want to call them that. Since we didn't have all the must-be-in-your-deck-cards like 20 times, you had to choose one or two decks to stick with, until you either had enough cards or wanted a change. This is why I suggest differing between decks and recipes. Let the player have recipes he can construct decks from, if he's got the cards to do so, but consider the decks physical stacks of cards that must be complete: They couldn't toss cards from their decks, but cards that they used in a recipe may be tossed, even if that recipe could not be used to build a deck from anymore.

The next thing to think about is how to deal with card effects, that automatically (or may be) trigger at a certain point of a turn, right? I don't know Ruby and it's possibilities, but here's what I'd do in a C# based game:
1. The abstract class Card, which is inherited by TrainerCard, PokeCard and EnergyCard has some virtual methods called (or events triggered, for that matter [I haven't thought about this too much, yet]), that must be called at the respective moments. Alternatively, another class CardEffect could be used, which holds a method Activate(), which had to be called. So, at the beginning of the player's turn, you'd call (assuming that activePokemonP is the player's active Pokemon, an instance of the PokeCard class)

activePokemonP.ActivePlayerBeginTurn();
activePokemonP.ActivePlayerTurnBeginning.Invoke(); // Event-based approach
activePokemonP.ActivePlayerBeginTurnEffect.Activate(); // Object oriened approach

Depending on what aproach you'd want to use, of course. I'd recommend both of the latter two, because you wouldn't have to create a new class for each card, but I don't know whether Ruby supports these approaches.

About the energy-problem: stop nuclear powe-- NO I WON'T MAKE THAT JOKE. Not now, anyway.
I'm eager to see a working solution to this, as I'm a little stuck on that one, too. However, asking the player what energies to use isn't even that bad an approach. I've seen it like that in EVERY SINGLE simulation of Magic The Gathering, why not use it here, at least until you're certain your algorithm works in all cases, which, if I was you, I wouldn't be too sure about.

Last but not least; the screen layout(s). If Nintendo could do with 160x160 pixels, we should be able to get this done with... what was it again? 256x192? Yup, that should be more than enough. I'll throw something together later: I think I can provide both, good-looking graphics and a working layout. How about starting with the card-summary screen? It's quite independent from the heavily-discussed library and something you should originally have started with, anyway, since the card-summary-screen will be needed for pretty much all menus. Yes, I'm a fan of the global-to-specific-approach (Is that the correct English term? I'm from Germany, y'know?), simply because it has always proven useful to me

cYa, folks.