• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Which Pokémon Masters protagonist do you like most? Let us know by casting a vote in our Masters favorite protagonist poll here!
  • Red, Hilda, Paxton, or Kellyn - which Pokémon protagonist is your favorite? Let us know by voting in our poll!
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

Pokémon TCG Adventure [Recruiting]

As promised, I'm excited to announce that I have finished the rebalance process for the 2800 cards that will appear in the initial (Kanto and Johto) release. All of them now use updated wording consistent with the most up-to-date wording of things (currently Scarlet & Violet), and their power levels roughly correspond to the XY era of the game. I still need to go back over the first couple hundred cards to give them a double check since I didn't have as much of an idea what I was doing when I started 2 years ago, and I need to put all the data in a more readable and usable format instead of just being in one big google doc, so that people can actually work with it for deck building, but the most tormentous and menial part of the project is essentially complete.

I am still recruiting for people willing to contribute to the project in any way, whether that's assistance with programming, game design, deckbuilding, art, music, or just willingness to help out with some menial tasks that anyone could do, given the right instructions (for example, cropping the art from cards, resizing them and reducing the colors and giving them the correct filenames). So far it's been essentially just me, with a slight bit of input or feedback from a couple other people now and then, which has why this has taken so long so far.
 
but the most tormentous and menial part of the project is essentially complete.

Er, not quite. Rebalancing the cards is a lot of time and effort, but there's some leeway there. If you give a Pokemon 10 HP more or less than it should have, it's probably not the end of the world. On the other hand, writing the code to deal with the effects of pokemon attacks and pokemon powers is going to be a pain in the ass, because there is a very clear way the game should run in almost all situations, and if you get the code wrong, it's going to be fairly obvious to the player. And there are roughly twice as many attacks as there are Pokemon, many of them unique.

I ran into that exact snag myself, actually. I had an idea to write an AI in Python that could play the Pokemon card game on its own, but I got stuck once I realized just how much work I would need to do to code each pokemon attack, and how likely it would be for the game to end up as a huge pile of spaghetti code if I wasn't extremely careful how I structured it.

I still occasionally work on the AI program, primarily focusing on getting it structured correctly, because the last thing I want to do is wind up writing a nest of tangled exceptions to the core game logic that are a huge pain to debug.

EDIT: If you want, I could share what I have so far. I've already made some progress on Haunter's Transparency/the baby rule (enemy must succeed at a coin flip or their attack fails) and Swift (ignores weakness/resistance/other effects on the defending pokemon).
 
Last edited:
Er, not quite. Rebalancing the cards is a lot of time and effort, but there's some leeway there. If you give a Pokemon 10 HP more or less than it should have, it's probably not the end of the world. On the other hand, writing the code to deal with the effects of pokemon attacks and pokemon powers is going to be a pain in the ass, because there is a very clear way the game should run in almost all situations, and if you get the code wrong, it's going to be fairly obvious to the player. And there are roughly twice as many attacks as there are Pokemon, many of them unique.

I ran into that exact snag myself, actually. I had an idea to write an AI in Python that could play the Pokemon card game on its own, but I got stuck once I realized just how much work I would need to do to code each pokemon attack, and how likely it would be for the game to end up as a huge pile of spaghetti code if I wasn't extremely careful how I structured it.

I still occasionally work on the AI program, primarily focusing on getting it structured correctly, because the last thing I want to do is wind up writing a nest of tangled exceptions to the core game logic that are a huge pain to debug.

EDIT: If you want, I could share what I have so far. I've already made some progress on Haunter's Transparency/the baby rule (enemy must succeed at a coin flip or their attack fails) and Swift (ignores weakness/resistance/other effects on the defending pokemon).
I was very precise with my words there. I said the most menial part is complete, not the most difficult or important. I don't consider coding to be menial, I generally consider it fun, as a form of problem solving. A lot more interesting than repeatedly copying and pasting blocks of text, changing numbers and manually typing out reworded descriptions while having to constantly search the most recent wording of any given effect 2000 times, at least. Trust me when I say that a lot more went into it than just "should this have 10 more HP?" Balance-wise, it was only the first pass anyway. Stuff will be updated as needed when the game is in a state to be playtested.

I appreciate the offer to share what you have, but it likely wouldn't be particularly applicable to the way I'm doing things. (For one thing, I am not using the Baby Rule. All Babies have been updated to the XY standard of having the Sweet Sleeping Face Ability and putting themselves to sleep when attacking.) More importantly, it wouldn't directly translate to the engine I'm building. I plan to code the attacks in a modular fashion, building an attack editor where each possible function an attack can have (coin flips, damage and so on) are all nodes that can be dragged around and connected visually. The goal is for nothing to be hardcoded, all effects of attacks must be coded under the assumption they could appear on any attack in any way. (Once the editor is finished, even someone with no programming experience would be able to code most attacks, although I'll have to continuously add more nodes for unique effects, but having gone through them all once already, I have a good idea of how many that will be).

Enemy AI is another matter entirely that I'm not touching yet, but it will likely start with a straightforward "simulate every possible option and pick the one with the best outcome" algorithm, with a lot of fine tuning. (I will cheat a bit with some AI having manual data input though, like which cards should be prioritized when searching a deck)

In any case, as an update: I will be taking a break from this project for the next 3 months, so you won't hear much from me in that time.
 
I was very precise with my words there. I said the most menial part is complete, not the most difficult or important. I don't consider coding to be menial, I generally consider it fun, as a form of problem solving. A lot more interesting than repeatedly copying and pasting blocks of text, changing numbers and manually typing out reworded descriptions while having to constantly search the most recent wording of any given effect 2000 times, at least.
Fair enough!

rust me when I say that a lot more went into it than just "should this have 10 more HP?" Balance-wise, it was only the first pass anyway. Stuff will be updated as needed when the game is in a state to be playtested.
Oh, yeah, no, I didn't mean to imply that I thought that was the case. I just meant to emphasize the need for precision in coding in a way that isn't quite there when you're just rebalancing Pokemon.
I appreciate the offer to share what you have, but it likely wouldn't be particularly applicable to the way I'm doing things. (For one thing, I am not using the Baby Rule.
Honestly, I meant that in the sense of, "Here's how I solved the issue of cancelling an attack or making it ignore certain effects".

I plan to code the attacks in a modular fashion, building an attack editor where each possible function an attack can have (coin flips, damage and so on) are all nodes that can be dragged around and connected visually. The goal is for nothing to be hardcoded, all effects of attacks must be coded under the assumption they could appear on any attack in any way. (Once the editor is finished, even someone with no programming experience would be able to code most attacks, although I'll have to continuously add more nodes for unique effects, but having gone through them all once already, I have a good idea of how many that will be).
Wow. That's gonna be a lot of work, since there are a lot of unique attacks. Good luck with that. Seriously.
Enemy AI is another matter entirely that I'm not touching yet, but it will likely start with a straightforward "simulate every possible option and pick the one with the best outcome" algorithm, with a lot of fine tuning. (I will cheat a bit with some AI having manual data input though, like which cards should be prioritized when searching a deck)
I don't really understand the math behind it, but I'm planning to use Monte Carlo simulations with UCB1, where you simulate the possible outcomes a bunch of times and use that to select the best outcome. I may instead use UCT, which builds a series of nodes and travels down them until it gets to the end, where it randomly simulates the rest of the game, and uses the results of that simulation to update the node values. It creates more accurate predictions, but I'd need to cheat a bit and make all the cards visible to the AI to make it work.
 
Last edited:
Honestly, I meant that in the sense of, "Here's how I solved the issue of cancelling an attack or making it ignore certain effects".
Well, feel free to send it to me by all means. I may well get something out of looking at it. Currently my plan for things like ignoring effects is for literally everything to be couched in "is this active right now?" checks at all times.
 
Well, feel free to send it to me by all means. I may well get something out of looking at it. Currently my plan for things like ignoring effects is for literally everything to be couched in "is this active right now?" checks at all times.
Bear in mind that this is all high-level, structural stuff, and I haven't actually started implementing it, but my idea was to create a class that contains a list containing references/pointers to the active effect functions, a pointer to the current location in the list, and functions that are effectively commands for the list, such as run_next(), skip_next(), skip_all(), skip(effect_name), skip(type, location, etc.) skip_to(effect_name), etc.

Also, ChatGPT keeps suggesting I use an event-driven approach if I want to avoid spaghetti code for this project, and that seems like it might be a good way to structure the code. Here's my best understanding of what that would look like:

An event manager is a class that's basically a list of the active effects, which are functions or references/pointers to functions (depending on the language). The event manager also contains functions to add or remove effects from the manager list, as well as some way of keeping track of what phase/event connects to what effect/function/event listener/event handler (they're all the same thing), possibly with separate lists, or even separate event manager objects, for each phase.

Each phase of gameplay (draw phase, attack phase, etc.) would be considered an event. When the manager is told that a phase/event happens, it goes down the list of functions/effects/event listeners/event handlers that have been mapped to that phase and calls each function on the list, including access to game state information that the functions would need to know and/or modify. This would neatly tie into my idea from the first paragraph of putting the effects all in a list.
 
Last edited:
I don't know if this is helpful or not, but I made some changes to my planned structure that I think add a lot of flexibility, and I can't think of anybody else who might be interested in hearing about it, so you're my audience. :P

The initial impetus for this change was trying to figure out how to handle cards like Pokemon Tower: "If the effect of a Pokémon Power, attack, Energy card, or Trainer card would put a card in a discard pile into its owner's hand, that card stays in that discard pile instead."

The solution I came up with was to break each action (anything that triggers and resolves at the same time, usually player-triggered) down into what I call "atomic actions", such as "move a card from one location to another" or "deal a specific amount of damage". (This is not to be confused with the more common programming definition of "atomic", which has to do with thread safety.) Before an atomic action actually executes, information about the function name and its inputs are passed to the different effects (anything that persists on the game board) to see if any of them trigger. If none of them do, the atomic action executes as normal. If one of more of the effects trigger, they can do things like change variables in the code and skip effects, actions, and phases.

So Dragonair uses the Hyper Beam attack, which deals damage and moves an energy from a pokemon to the discard pile. But a custom stadium card in play explicitly prevents energy removal effects. During the attack phase Dragonair attacks, triggering two actions: "damage(20)" and "move(target=selected energy card, from=defending pokemon, to=discard)". The first atomic action, damage(20), causes all active effects to check the function name and inputs. No effects trigger at this, so control moves to the energy removal action. Again, the effects check the function name and inputs. This time, the stadium card effect recognizes that the information matches the trigger it has, so it tells the event manager to skip past the energy removal action, nullifying it.

This does mean that a second event manager (or a separate section of the first event manager) will probably need to be used to handle the effects separately from the actions, which are in turn separate from the phases.

...I think. I'm not entirely sure how separate "phases" and "actions" are or should be.

I haven't given it a lot of thought, but the effects themselves will probably also need to check to see if they trigger other effects.

I also had a plan for using node graphs to handle pokemon powers that disable or are disabled by other effects, potentially causing cascading effects (e.g. paralysis on Toxic Gas Muk, on Dodrio's Retreat Aid), but I would want to figure out how such pokemon powers interact with the adjusted structure before I worry about that.
 
Last edited:
You're doing a good job of putting into words some concepts I had internalized and plans I generally already had but hadn't fully fleshed out. It may be best to send them in DMs in the future, but I appreciate it, will likely look them over again once I get to that point.
 
Ahhh, I just found this after planning to make my own version of this project but using godot….. oh well, wishing you luck in your endeavor. Do you mind me asking where you're getting the images for the cards? I've looked pretty much everywhere I could look but I found nothing other than scan that vary in size and quality. Especially for the evolutions because they all have that little indicator that they evolved from something right over the picture.
 
Ahhh, I just found this after planning to make my own version of this project but using godot….. oh well, wishing you luck in your endeavor. Do you mind me asking where you're getting the images for the cards? I've looked pretty much everywhere I could look but I found nothing other than scan that vary in size and quality. Especially for the evolutions because they all have that little indicator that they evolved from something right over the picture.
By all means feel free to make your own regardless, or if you want to put our heads together and work together, that's an option too. I'm not that attached to Unity, either. The basic framework and UI stuff that I had done so far is actually the quickest and easiest part compared to actually making the card effects and everything else.

As far as card art, I use various sources, but there are no good sources for getting the card art on its own as they haven't really released them (with the exception of a few leaks and promo arts here and there, and some more modern cards where the artists posted the art on twitter). Pkmncards.com is a great resource, as well as bulbapedia. I crop the art from the card images on sites like that, and if there are parts that are in the way like the evolutions, I either strategically crop those parts out, or I use some tools like photoshop's context-aware fill tool, or various online AI tools that I've played around with in order to fill in the blank parts. If necessary, I touch them up or paint in the details myself. Afterwards, I employ some filters on them as well to get them looking like the kind of DS-era pixely style I'm going for.

Anyway, I'm just coming off my 3 month break that I was taking from this project so I may resume it in the next month or so, but obviously I have nothing new to talk about since I've spent the past 3 months focusing on other things.
 
Back
Top