Welcome to the PokéCommunity!

Hi there! Thanks for visiting PokéCommunity. We’re a group of Pokémon fans dedicated to providing the best place on the Internet for discussing ideas and sharing fan-made content. Welcome! We’re glad you’re here.

In order to join our community we need you to create an account with us. Doing so will allow you to make posts, submit and view fan art and fan fiction, download fan-made games, and much more. It’s quick and easy; just click here and follow the instructions.

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.

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):

Code:

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

And this filters out only stage 2 cards:

Code:

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"

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).

Quote originally posted by 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?

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.

Quote originally posted by Awkward Squirtle:

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).

Quote originally posted by Awkward Squirtle:

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):

Code:

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

And this filters out only stage 2 cards:

Code:

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.

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:

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

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.

Quote originally posted by Awkward Squirtle:

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.

Quote originally posted by Awkward Squirtle:

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.

Quote originally posted by Awkward Squirtle:

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.

Quote originally posted by Awkward Squirtle:

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

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).

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.

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.

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.

Quote originally posted by P-Sign:

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.

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.

"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)

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)

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.

__________________

There are two things every Rom-Hacker should learn:
1. Don't give away everything you know!

For an AI looking forward, why not do the opposite of the AI does? What I mean is, in Pokemon Essentials, the AI checks for moves, type advantages, etc. So why not so something similar-ish, but on the player's side? so check the players energy to attacks, types, etc. just an Idea

Also, in terms of effects, why not define the basic ones with parameters(e.g. Many cards have multiplication damage, based on coin flips. So why not have an effect of, flip a coin x times, attack does Y times the number of b. So the function code, if I'm not mistaken, assuming the code is 012, then coin is getting flipped twice, and it is times 50, and it's based on heads, then the code would be 012(2, 50, true). Not sure if valid though) It's just an idea, but would really help save space

Sorry it took me so long, I had some trouble with a virus and needed to setup windows anew. BUT I managed to save most my data, so here you go:
(The colorful stuff in the background is a placeholder for card images)
Oookay, explanation time - in the top-left we have #1, top-right is #2, center-left is #3 and so on:
#1 - Pokémon Card summary page 1: pretty self-explanatory, right? The red stuff would only be visible during battle, since it is unneeded, even unchanged information during deck construction etc.
#2 - Pokémon Card summary page 2:the idea is, that you scroll through moves and PokéBody / PokéPower and press A (if we were using a GBA, idk what the corresponding keyboard key for RMXP is) to jump to something similar to screen #4, only that the top-bar would still contain the HP value and element symbol. The dark line between the PokéBody and the moves would not always be placed under the first entry, but under the last PokéBody / -Power.
#3 - Trainer Card summary page 1: the card image and the cardname. Shouldn't be hard to implement, right?
#5 (yup, I skipped #4, you'll see why) - Energy Card summary page 1: the only page for basic energies, since they don't need much information
#4 - Trainer / Special Energy Card summary page 2: you've guessed it by now, right? The card's effect is shown. Yay!

Very well, that's pretty much it. I'll put a *.zip-file in the attachements, containing the *.pdn-files, the preview and the finished *.png-files.

Since I don't seem to be able shut my mouth any longer, I'll comment on my own post, concerning the suggested code: Even though you could use events for the moves (like 'Move1Used.Invoke();' 'Move2Used.Invoke();' and 'PokePowerUsed.Invoke();') I'd recommend using OOP instead, since then you could just say Pokemon.Moves[0..3].Use(), assuming there was a pokemon with, like, 2 PokePowers and 2 moves. PokeBodies don't need to be counted, since they aren't manually activated, if I remember correctly. Then, you'd have to use lots of objects, of course.

Maybe we just do our work very differently. Like I said, I like to start with the very basic stuff and build everything around it. Anyway, should you have read my previous posts, you might've noticed that I did mention some of my ideas concerning the library and the battle system.
Anyway, when I referred to the card image, I was actually referring to the card's artwork panel. I didn't measure the side ratio, so I'm not too sure it actually fits perfectly, but I didn't have any Pokémon Cards at hand when I did the layout.
Concerning the battle info on the card summary screen; I think it might really come in handy for players planning their turn while looking through all the cards on the field and their hand. Assume you would have to constantly switch between the battle field screen and the summary screen. That'd be pretty annoying, since there can be 2x5 (bench) + 2x1 (active) + 1 (stadium) + 7 (hand) = 20 cards of interest, not even counting (special-)energy cards. I imagine it to be a lot more comfortable to use L and R or something to swicth from one card's summary to another one's. In that case, the player should be able to see information, such as a pokémon's HP and status. Also, it's just one boolean variable to consider (since you need to render the info anyway, you can probably just copy the draw-logic), it can't be such a pain to implement that with Ruby, can it? I know, you had a similar discussion about the filters already, I just want you to consider it before just scrapping the idea for simplicity.

cYa

__________________

There are two things every Rom-Hacker should learn:
1. Don't give away everything you know!

I have read all the posts in this thread, and absorbed the information therein (although perhaps not some of the more techy stuff since I'm not at that stage yet). Please bear this in mind even if I don't respond to it all - I write it down and think about it a lot.

Anyway...

Progress update
See attached. Yes, it's the Card Library screen (and the Deck Builder screen). What you see is actually coded and actually works... pretty much. All graphics can easily be placeholders if better artwork comes along.

The Library shows 9 cards at once, each with an icon and quantity. Each pocket displays the number of cards in it. Ignore the item icon overlapping with the card picture, because I've not done that yet. Moving between pockets is the same as for the Bag, i.e. left and right.

Selecting a card allows you to either examine or toss it. You can toss any cards that aren't being used in a deck - if you try to toss more than are spare, the game will say so and ask if you want to toss just the spare ones instead.

Filters are fully supported, although I've only bodged one in so far ("Basic Pokémon only", as you can see in the screenshot). The pocket quantity doesn't change even if you apply filters. Filters are per-pocket and persistent. Once a GUI has been invented to allow filter toggling, it will be available from a menu which pops up by pressing Alt - this menu will also contain a "Remove all filters" option and a couple of sorting options (alphabetical, "smart"). The exact filter/sorting options are undecided so far. Free sorting (like in most of the Bag's pockets) is also available, and applying a sort option is a one-off rearranging action when selected rather than constant reins.

The Deck Builder is built on the Library, and does whatever it can do. However, cards cannot be tossed. The numbers in each pocket's tab indicate how many cards from that pocket are in the deck; again, these numbers are unaffected by filters. Adding/removing cards from the deck is done by pressing S/D. There is already a 4-cards-of-the-same-name restriction, but it doesn't apply to Basic Energy cards. The deck list cannot be filtered or sorted, and will always be arranged in the "smart" way (see below).

The Alt options menu will also contain a "Rename Deck" option, and an option to change the deck's icon - the icon is decoration only, and separate to the "incomplete/complete/main deck" icon.

It is intended that decks can be left incomplete, unless it is the main deck which must be complete.

--------------------

The "smart" sorting method is a bit involved. The cards are first grouped into types, with monsters coming before trainers coming before energies. Trainers are then divided into trainers/stadium/item/whatever, with each group in alphabetical order, and energies are similar but with basic/special types. Pokémon are grouped together according to evolution family (in ascending order), and are then put into element super-groups according to the type of the first Pokémon in that group (e.g. Eevee-related cards will be in the Colourless group).

The only part of this I've done so far is the "monsters then trainers then energies" for decks only. Coding the other aspects of it, particularly the evolution family grouping, will be... interesting.

--------------------

There are many things still to do before the Library/Deck Builder is actually usable. There is no "choose deck to work on" screen yet, nor a way to save/discard changes. The aforementioned filters and sorting options need to be created. And so on. I just thought you might like to know what's going on.

EDIT: I couldn't attach a file when I made this post, so I had to create it then edit it before I was allowed to attach the screenshots. Seems like a bug with the forum to me.

I've done almost nothing in this project since my last post, due to lack of interest and my working on Essentials instead. Recently, I've wanted to get started on the duel scripts, which meant I needed a design. So I hacked up screenshots of Asobikata and made the attached. They still need tidying up, of course.

The idea is that everything will take place on one of three views of the playing field (player's side, centre or opponent's side), ideally with a smooth scrolling between each one. There'll be a few sub-screens too (e.g. one for choosing a prize card, one for listing cards to choose from), but they'll be overlaid on the field. It's very ambitious, I know.

There's just enough space for 2 Active Pokémon, but not if either is paralysed or asleep (which rotates the card sideways; I could forego card rotations in favour of status icons instead). Double battles aren't something I'm worrying about right now, though.

I've done almost nothing in this project since my last post, due to lack of interest and my working on Essentials instead. Recently, I've wanted to get started on the duel scripts, which meant I needed a design. So I hacked up screenshots of Asobikata and made the attached. They still need tidying up, of course.

The idea is that everything will take place on one of three views of the playing field (player's side, centre or opponent's side), ideally with a smooth scrolling between each one. There'll be a few sub-screens too (e.g. one for choosing a prize card, one for listing cards to choose from), but they'll be overlaid on the field. It's very ambitious, I know.

There's just enough space for 2 Active Pokémon, but not if either is paralysed or asleep (which rotates the card sideways; I could forego card rotations in favour of status icons instead). Double battles aren't something I'm worrying about right now, though.

The main thing I noticed is the prize card area needs to be bigger. You will need to fit 6 cards for most duels. I'm not really a fan of the color, but that's just my opinion. Other that that it looks nice

I came up with the attached for the 6-prizes version. I know there's limited space, but you can always "zoom in" to them if you need to. I remember seeing one card while randomly browsing Bulbapedia (I like to look at the cards and imagine how to make them work) which allows you to increase the number of prize cards, so I don't yet know how that's going to work. It's a minor worry at the moment.

Eventually the project will support the choosing of which backgrounds to use. The green was just ripped from the Asobikata game (and I happen to like it - it's like a felt card table).

The PokéCommunity

Meta

Pokémon characters and images belong to The Pokémon Company International and Nintendo. This website is in no way affiliated with or endorsed by Nintendo, Creatures, GAMEFREAK, or The Pokémon Company International. We just love Pokémon.