Thread: [Essentials Script] Pokémon TCG mod
View Single Post
Old September 29th, 2012 (5:48 AM).
TheDarkShark TheDarkShark is offline
Metal Headed Hacker
Join Date: May 2010
Location: Germany
Gender: Male
Nature: Calm
Posts: 56
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.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.
There are two things every Rom-Hacker should learn:
1. Don't give away everything you know!