From: "Sebastjan H." Date: 2012-07-19T17:13:30+09:00 Subject: Re: learning by doing part 2 - tc game "Jesús Gabriel y Galán" wrote in post #1069191: > On Wed, Jul 18, 2012 at 2:02 PM, Sebastjan H. > wrote: >> player_hp = player_hp + card.armor >> if ai_card.type == "dragon" or ai_card.type == "dire wolf" >> ai_hp = ai_hp + ai_card.heal >> >> >> @deck.delete(card) >> @ai_deck.delete(ai_card) >> puts "Player health is #{player_hp}." >> puts "Ai health is #{ai_hp}." >> ------------------------------------------------------------- >> thank you very much. > > > One approach that implies a huge refactor of your datastructures, > would be to have each card object implement its own logic on the game > state: > > class ArmorCard > attr_reader :armor_level > def initialize armor > @armor_level = armor > end > > def perform_action game_state > game_state.increment_player_hp(armor) > end > end > > class HealingSpellCard > attr_reader :spell_level > def initialize spell_level > @spell_level = spell_level > end > > def perform_action game_state > game_state.increment_player_hp(spell_level * 2) #healing spells > heal double their level (example of spell logic) > end > end > > Then you only need to call the perform_action method in each card > object. If you have common logic, such as attack card only differing > in name and attack value, but the attack logic is the same, then you > could model it with a class hierarchy: > > class Card > def is_attack? > false > end > end > > class AttackCard < Card > def is_attack? > true > end > > def perform_action game_state > game_state.increment_player_hp(armor) > if game_state.ai_card.is_attack? > game_state.increment_player_hp(-ai_card.attack) > end > end > end > > class Dragon < AttackCard > attr_reader :armor, :attack > def initialize armor, attack > @armor = armor > @attack = attack > end > end > > And so on. You might have different classes depending on > characteristics or other ways to model it: maybe AttackCard, > SpellCard, etc could be modules you mixin in specific cards, for > example if some card can be both. Then maybe you could have a general > implementation of perform_action in the Card class. It depends. > > I hope this gives you some ideas. > > Jesus. Hi Jesus, I think you are right, this is probably the way to go and much better than branching or making different methods for different combinations of cards (would make game expansions impossible). However, I don't understand the "increment_player_hp". This is just your example, right? I'd have to define this I guess. Furthermore, according to your example above for the AttackCard there is only the definition for the player attack. I'd have to make two of those, also for the AI, right?. And for all other card types as well. regards, seba -- Posted via http://www.ruby-forum.com/.