Click here to Skip to main content
15,889,874 members
Please Sign up or sign in to vote.
1.00/5 (2 votes)
See more:
I have a card game program that I write.
I have - myhand,mytable, and AIhand,AItable.
on the table the fight is taking place.
until now only mytable I write and use.
But AItable?
Should I write a Table class (one for)me and (one for)AI?
Should I make a single table(class or object) for both me and AI?
Do you have a sample for me to look over - a similar case?
Is there a way to create something like a "mini-engine" that will contain only the core of the game and the rest of the details like graphics,objects,etc to be attached to it?
thanks.

What I have tried:

i am thinking at this subject for many years ... :)
Posted

1 solution

What you want to do in situations like this is to declare and implement an interface. Both the player table and AI table will have features that are common, but might be implemented differently; this is where interfaces come in handy. You can even define a base class that implements the part of the interface that could be the same for both (such as Draw()).

Here's a quick sample of how that works, with a goofy psudocode snippet to show how to use it.

C#
public interface ICardHand
{
   int Draw();
   ICardResult PlayCard(ICard card);
}

public abstract class CardHand
{
   public int Draw()
   {
      ... //logic to draw card
      return numberOfCardsInHand;
   }
}

public class PlayerHand : CardHand, ICardHand
{
   public ICardResult PlayCard(ICard card)
   {
      ... //get the card from the UI thread, etc
      return card.Result;
   }
}

public class AIHand : CardHand, ICardHand
{
   public ICardResult PlayCard(ICard card)
   {
      ... //perform card selection through voodoo and whatnot
      return card.Result;
   }
}

public class CardTable
{
   public IEnumerable<icardhand> Players { get; protected set; }
   
   public void Deal()
   {
      foreach(var hand in Players)
      {
         var count = 0;
         while(count < 7)
         {
            count = hand.Draw();
         }
      }
   }
   ...
}


Please bear in mind that I wrote this in 5 minutes with no context whatsoever. This is solely to show you how to code against an interface, not for use (I've had questions that required this caveat, which is why I'm giving it).

This also gives you the flexibility of adding options down the road. If you code against an interface, it doesn't matter if an AI is controlling it or a human. You could use the same code base to run a multi-player game as a single player one.

As for your last question, you should abstract your game engine enough that it doesn't matter how the assets are managed. This will give you options, in case you want to use a different GUI mechanism or need to change out the graphics due to system changes (such as DirectX version updates).

Anyway, just start thinking about how you can structure your game classes and how you want them to relate to each other. Boil it down to as primal of a structure as you can, and that will help you define your interfaces.

Best of luck!
 
Share this answer
 
v2
Comments
Maciej Los 30-Aug-16 10:50am    
5ed!
_Q12_ 30-Aug-16 12:30pm    
thank you !

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900