Thread: [Essentials script] Pokémon TCG mod
View Single Post
  #55    
Old September 28th, 2012, 07:00 AM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
Quote:
Originally Posted by Awkward Squirtle View Post
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 View Post
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 View Post
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 View Post
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 View Post
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).
__________________
Reply With Quote