Tworzenie gry w karty - Pasjans.

[czeri]

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

int x = vCards[numer_indeksu].LastDelimiter("_"); /* gdzie klucz to np. DAMA_PIK */
String jaki_kolor = vCards[numer_indeksu].SubString( x + 1, 4 );
String jaka_karta = vCards[numer_indeksu].SubString( 1, x - 1);

No niewiedziałem, że to można tak zrobić, więc dzięki za podpowiedź.

---

Teraz kwestia tego typu jak sprawdzić czy pod aktualnie przesówaną kartą jest inna karta(czyli przekładanie kart między stosami), mam to zrobić poprzez sprawdzenie aktualnej pozycji karty przenoszonej i sprawdzeniu czy na tej pozycji jest jakaś inna karta i wtedy dopiero sprawdzać jej wartość i kolor czy jest na to jakaś inna metoda.

Przepraszam jeśli moje pytania są głupie ale niestety nie jestem dobry w te klocki i dziękuje za wyrozumiałość

[Cyfrowy Baron]

Teraz kwestia tego typu jak sprawdzić czy pod aktualnie przesówaną kartą jest inna karta(czyli przekładanie kart między stosami),

Układ, czyli kolejność kart jest ustalona w wektorze vCards, przy czym wektor z indeksem 0 reprezentuje kartę na dole, a wektor o indeksie vCards.size() reprezentuje kartę na górze. Jeżeli masz karty na kilku kupkach, to oczywiście karta na jednej kupce nie jest ostatnią na wektorze. By sprawdzić jaka karta znajduje się pod kartą wskazywaną przez kursor, należy od indeksu karty wskazywanej odjąć 1 i już masz wektor z kartą pod spodem karty wskazywanej. Zawsze możesz sprawdzić układ kart sprawdzając kolejność identyfikatorów kart w wektorach. Pamiętaj że wektor sortuje tylko przechowywane identyfikatory, a indeksy zawsze liczone są po kolei czyli 0, 1, 2, 3 ... vector.size()

[czeri]

[j]Układ, czyli kolejność kart jest ustalona w wektorze vCards, przy czym wektor z indeksem 0 reprezentuje kartę na dole, a wektor o indeksie vCards.size() reprezentuje kartę na górze. [...]

Tak sprawdze tylko jakie są karty na kupce startowej a chodzi o to, że mając przykładowo kupki A, B, C, D będe chciał przeciągnąć karte z kupki A na kupkę C to odejmując od indeksu przenoszonej karty 1, sprawdze jaka karta była poniżej w kupce A, a nie jaka jest na kupce C (nad która trzymam aktualnie przenoszoną karte) jaki był zamiar

[Cyfrowy Baron]

a nie jaka jest na kupce C (nad która trzymam aktualnie przenoszoną karte) jaki był zamiar

Mam wrażenie, że nie myślisz. Przecież przesuwając kartę po planszy możesz cały czas sprawdzać, czy kursor nie znajduje się nad innymi kartami, wystarczy z listy sprawdzanych kart wykluczyć aktualnie przeciągana kartę. Lepszym rozwiązaniem jest jednak sprawdzanie w momencie puszczania karty, czyli w zdarzeniu OnMouseUp, co znajduje się pod upuszczaną kartę, czyli w tym zdarzeniu jeszcze przed wykonaniem pozostałych zadań przewidzianych dla tego zdarzenia sprawdzasz co jest pod tą kartą używając funkcji FindCard, tylko trzeba by ją trochę zmodyfikować:
Funkcja FindCard:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

BOOL __fastcall TForm1::FindCard(int X, int Y, String &Key)
{
 for(int i = vCards.size() - 1; i >= 0; i--)
 {
  if(i == moveIndex) break; /* pomijam <- pierwsza zmiana */

  if( (X >= mCards[vCards[i]].x && X <= mCards[vCards[i]].x + 114) &&
      (Y >= mCards[vCards[i]].y && Y <= mCards[vCards[i]].y + 154)
      )
  {
   Key = vCards[i];
   if(moveIndex == -1) moveIndex = i; /* < druga zmiana */
   return true;
  }
 }
 return false;
}

Zdarzenie OnMouseUp:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

void __fastcall TForm1::Image1MouseUp(TObject *Sender, TMouseButton Button,
          TShiftState Shift, int X, int Y)
{
 Screen->Cursor = crDefault;
 if(!moveCard) return;

 /* najpierw sprawdzam na jaka kartę kładę */
 String Key;
 if(FindCard(X, Y, Key))
 {
  ShowMessage("Kładziesz na kartę: " + Key);
 }
 // koniec sprawdzania

 String vText = vCards[moveIndex];
 int size = vCards.size() - 1;


 for(int i = moveIndex; i < size; i++) /* przesuwanie karty na wierzch */
 {
   String vText = vCards[i];
   vCards[i] = vCards[i + 1] ;
   vCards[i + 1] = vText;
 }

 moveIndex = -1;
 DrawCards();
 moveCard = false;
}

Jak widzisz do zmiany funkcji wystarczy niewielka modyfikacja kodu, trzeba tylko dokładnie zrozumieć jak działa, czyli co z czego wynika.
Sugeruję tworzyć jak najwięcej funkcji, gdyż wtedy łatwo jest modyfikować kod, np. do sprawdzania karty pod spodem również można stworzyć funkcję:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

String __fastcall TForm1::GetBackCard(int X, int Y)
{
 String Key = "brak karty";
 FindCard(X, Y, Key);

 return Key;
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Image1MouseUp(TObject *Sender, TMouseButton Button,
          TShiftState Shift, int X, int Y)
{
 Screen->Cursor = crDefault;
 if(!moveCard) return;

 /* sprawdzam na jaką kartę kładę */
 String komunikat = "Kładziesz na kartę: " + GetBackCard(X, Y);
 ShowMessage(komunikat);

 String vText = vCards[moveIndex];
 int size = vCards.size() - 1;


 for(int i = moveIndex; i < size; i++) /* przesuwanie karty na wierzch */
 {
   String vText = vCards[i];
   vCards[i] = vCards[i + 1] ;
   vCards[i + 1] = vText;
 }

 moveIndex = -1;
 DrawCards();
 moveCard = false;
}

To niestety nie będzie tak do końca działać poprawnie, sytuację może jednak poprawić nieco utworzenie odrębnej funkcji do sprawdzania karty pod spodem:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

void __fastcall TForm1::FindBackCard(int X, int Y, String &Key)
{
 Key = "brak karty";
 for(int i = vCards.size() - 1; i >= 0; i--)
 {
  if(i == moveIndex) continue;

  if( (X - scPoint.x + 114 >= mCards[vCards[i]].x &&
       X - scPoint.x <= mCards[vCards[i]].x + 114) &&
      (Y - scPoint.y + 154 >= mCards[vCards[i]].y &&
       Y - scPoint.x <= mCards[vCards[i]].y + 154)
      )
  {
   Key = vCards[i];
   return;
  }
 }
}
//---------------------------------------------------------------------------
String __fastcall TForm1::GetBackCard(int X, int Y)
{
 String Key = "brak karty";
 FindBackCard(X, Y, Key);

 return Key;
}

To już działa chyba w pełni poprawnie, jednak nie testowałem tego zbyt dokładnie.

---

Dobrze byłoby również zastąpić pętlę ze zdarzenia OnMouseUp przywołującą kartę na wierzch odpowiednią funkcją, którą ja nazwałem BringCardToFront:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

void __fastcall TForm1::BringCardToFront(const int vold, const int vnew)
{
 if(vold < 0) return;
 String vText = vCards[vold];

 vCards.erase(vCards.begin() + vold);

 if(vnew >= vCards.size()) vCards.push_back(vText);
 else vCards.insert(vCards.begin() + vnew, vText);

}
//---------------------------------------------------------------------------
void __fastcall TForm1::Image1MouseUp(TObject *Sender, TMouseButton Button,
          TShiftState Shift, int X, int Y)
{
 Screen->Cursor = crDefault;
 if(!moveCard) return;

 String komunikat = "Kładziesz na kartę: " + GetBackCard(X, Y);
 ShowMessage(komunikat);

 String vText = vCards[moveIndex];
 int size = vCards.size() - 1;

 BringCardToFront(moveIndex, vCards.size());

 moveIndex = -1;
 DrawCards();
 moveCard = false;
}

Funkcja może przesuwać kartę na dowolną pozycję, czyli niekoniecznie na ostatnią, wystarczy jako pierwszy argument podać aktualną pozycję karty, a jako drugi argument nową pozycję karty.
Pamiętaj, że indeksy wektorów liczą się od 0, więc podając pozycję 53 tak naprawdę przesuwasz kartę na pozycję 54, czyli w talii zawierającej 54 na pozycję ostatnią.

Tworząc funkcje nie zapomnij o ich deklaracji w pliku nagłówkowym w sekcji private lub public.

---

[polymorphism]

Drobna optymalizacja.

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

BOOL __fastcall TForm1::FindCard(int X, int Y, String &Key)
{
        for(int i = vCards.size() - 1; i >= 0; i--)
        {
                if(i == moveIndex) break;

                POINT &pt = mCards[vCards[i]];
               
                if( (X >= pt.x && X <= pt.x + 114) && (Y >= pt.y && Y <= pt.y + 154))
                {
                        Key = vCards[i];
                        if(moveIndex == -1) moveIndex = i;
                        return true;
                }
        }
        return false;
}

W sumie wartości vectora jak i klucze mapy powinny być liczbami (enum?). No i nie jestem pewny, czy ta mapa w ogóle jest tu potrzebna...

[Cyfrowy Baron]

No i nie jestem pewny, czy ta mapa w ogóle jest tu potrzebna...

Gdzieś muszą być przechowywane pozycje kart, a pozycja karty musi być powiązana z konkretną kartą, stąd mapa. Gdybym użył kolejnego wektora, to miałbym tylko indeksy wektora i pozycje kart, ale nie mógłbym ich powiązać z konkretnymi kartami, gdyż ułożenie kart w wektorze vCards jest zmienne i nie jest w żaden sposób powiązane z indeksami tego wektora. Poza tym potrzebna będzie kolejna mapa do przechowywania wartości kart. Można by oczywiści używać jednej mapy, która zamiast typu TPoint przechowałaby strukturę zawierającą wartości typu int x, int y i int value, gdzie value przechowywałaby wartość karty, ale to niestety skomplikowałoby bardziej kod i to co zaoszczędziłbym na mapach zmarnotrawiłbym przy aktualizacji map, gdyż każda zmiana pozycji karty wymagałaby również dopisania wartości karty, a przecież wartości się nie zmieniają. Co się zmienia w programie? Kolejność kart w wektorze vCards i pozycja kart w mapie, przy czym kolejność kart w mapie pozostaje niezmieniona. Używając wektora zamiast mapy, musiałbym przy zmianie kolejności kart w wektorze vCards zmieniać dokładnie tak samo położenie kart w drugim wektorze przechowującym ich pozycje, dzięki mapie nie muszę tego robić.

W sumie wartości vectora jak i klucze mapy powinny być liczbami (enum?).

Karty są przechowywane w zasobach, a co za tym idzie mają kolejne numery zasobów, więc można by użyć liczb, jednak zasoby mają również identyfikatory w postaci nazw, które reprezentują konkretne liczby, dzięki temu łatwiej sprawdzić z która kartą ma się do czynienia, a wektor przechowuje wartość typu String, która określa identyfikator zasobów. Stwierdzenie, że powinny być jest dla mnie nie zrozumiałe, gdyż nie muszą nimi być. Dzięki temu, że używam nazw mam większe możliwości zarządzania kartami, gdyż mogę to robić zarówno za pomocą liczb jak i identyfikatorów. Co do typu enum to jest zbędny, gdyż w zasobach znajduje się tablica String, która zawiera typ wyliczeniowy. Na początku rozważałem użycie tylko wartości liczbowych, ale nie spełniało to moich oczekiwań.
Co się tyczy optymalizacji, to nie jest jedyne fragment kodu, który da się zoptymalizować.

[polymorphism]

Gdzieś muszą być przechowywane pozycje kart, a pozycja karty musi być powiązana z konkretną kartą, stąd mapa.

Pozycja x i y karty wynika z jej pozycji w stosie - w tym przypadku mamy 4 stosy u góry... powinny być jeszcze 4 u dołu, jeśli dobrze kojarzę tę grę (nie znoszę gier karcianych ). Zatem przy rysowaniu łatwo wyliczyć ich pozycję na ekranie.

Karty są przechowywane w zasobach, a co za tym idzie mają kolejne numery zasobów, więc można by użyć liczb, jednak zasoby mają również identyfikatory w postaci nazw

Przecież wygodniej to trzymać jako jedną długą bitmapę, która trzyma wszystkie karty. Pozycję karty w takiej bitmapie łatwo wyliczyć.

Stwierdzenie, że powinny być jest dla mnie nie zrozumiałe, gdyż nie muszą nimi być.

Oczywiście, że nie muszą. Ale są lepsze i gorsze rozwiązania.

Dzięki temu, że używam nazw mam większe możliwości zarządzania kartami, gdyż mogę to robić zarówno za pomocą liczb jak i identyfikatorów.

To akurat nie ma żadnego związku, bo mogę powiedzieć to samo, tyle że w drugą stronę Zresztą logika programu nie potrzebuje identyfikatorów tekstowych, poza wspomnianymi nazwami zasobów, ale to się da spokojnie ominąć i uprościć.

Co do typu enum to jest zbędny, gdyż w zasobach znajduje się tablica String, która zawiera typ wyliczeniowy.

Nie rozumiem...

[Cyfrowy Baron]

Pozycja x i y karty wynika z jej pozycji w stosie - w tym przypadku mamy 4 stosy u góry... powinny być jeszcze 4 u dołu, jeśli dobrze kojarzę tę grę (nie znoszę gier karcianych ). Zatem przy rysowaniu łatwo wyliczyć ich pozycję na ekranie.

Ależ skąd. Karta może znajdować się w dowolnej pozycji na planszy. Ty zakładasz, że są stosy w ściśle określonym miejscu, nawet gdyby tak było, to i tak gdzieś trzeba by przechowywać numer stosu na którym karta się znajduje, czyli w praktyce do każdej karty zamiast pozycji na planszy musiałbym przypisać stos.

Przecież wygodniej to trzymać jako jedną długą bitmapę, która trzyma wszystkie karty. Pozycję karty w takiej bitmapie łatwo wyliczyć.

Wcale nie wygodniej, gdzieś musiałbym trzymać informacje o pozycji kart w bitmapie, a tak mam każą bitmapę oddzielnie, więc nie muszę jej wycinać z bitmapy zbiorczej za każdym razem gdy jest mi potrzebna. Teraz wystarczy sięgnąć po potrzebną kartę. Windows'owy pasjans również ma przechowywane karty oddzielnie.

Oczywiście, że nie muszą. Ale są lepsze i gorsze rozwiązania.

Dla mnie lepszym rozwiązaniem jest użycie mapy, która przechowuje zmieniające się pozycje kart oraz wektora którzy przechowuje nazwy identyfikatorów zasobów.

Zresztą logika programu nie potrzebuje identyfikatorów tekstowych, poza wspomnianymi nazwami zasobów, ale to się da spokojnie ominąć i uprościć.

Logika programu nie wymaga również by to były identyfikatory liczbowe, zważywszy na to, że mam do wyboru albo klucz String albo klucz int. Dzięki zastosowaniu klucza String, by sprawdzić co przechowuje dany klucz mapy lub wektor nie muszę zaglądać do tablicy String w zasobach, gdyż mogę pobrać nazwę bezpośrednio z klucza, w przeciwnym razie musiałbym pobrać z wektora numer karty a potem zajrzeć do zasobu STRINGTABLE i zobaczyć jaka jest karta pod tym numerem.

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

int x = vCards[numer_indeksu].LastDelimiter("_"); /* gdzie klucz to np. DAMA_PIK */
String jaki_kolor = vCards[numer_indeksu].SubString( x + 1, 4 );
String jaka_karta = vCards[numer_indeksu].SubString( 1, x - 1);

Nie rozumiem...

Patrze STRINGTABLE w zasobach id_cards.rc:

KOD text:   �  UKRYJ  �

KOD text:   �  POKAŻ  �

#define I9_PIK 1
#define I10_PIK 2
#define WALET_PIK 3
#define DAMA_PIK 4
#define KROL_PIK 5
#define AS_PIK 6
#define I9_KIER 7
#define I10_KIER 8
#define WALET_KIER 9
#define DAMA_KIER 10
#define KROL_KIER 11
#define AS_KIER 12
#define I9_KARO 13
#define I10_KARO 14
#define WALET_KARO 15
#define DAMA_KARO 16
#define KROL_KARO 17
#define AS_KARO 18
#define I9_TREFL 19
#define I10_TREFL 20
#define WALET_TREFL 21
#define DAMA_TREFL 22
#define KROL_TREFL 23
#define AS_TREFL 24

STRINGTABLE
BEGIN
I9_PIK "I9_PIK"
I10_PIK "I10_PIK"
WALET_PIK "WALET_PIK"
DAMA_PIK "DAMA_PIK"
KROL_PIK "KROL_PIK"
AS_PIK "AS_PIK"
I9_KIER "I9_KIER"
I10_KIER "I10_KIER"
WALET_KIER "WALET_KIER"
DAMA_KIER "DAMA_KIER"
KROL_KIER "KROL_KIER"
AS_KIER "AS_KIER"
I9_KARO "I9_KARO"
I10_KARO "I10_KARO"
WALET_KARO "WALET_KARO"
DAMA_KARO "DAMA_KARO"
KROL_KARO "KROL_KARO"
AS_KARO "AS_KARO"
I9_TREFL "I9_TREFL"
I10_TREFL "I10_TREFL"
WALET_TREFL "WALET_TREFL"
DAMA_TREFL "DAMA_TREFL"
KROL_TREFL "KROL_TREFL"
AS_TREFL "AS_TREFL"
END

Podczas tworzenia kodu rozważałem możliwości, które tutaj przedstawiłeś, jak chociażby przechowywanie w wektorze numeru identyfikatora karty, a nie nazwy zasobu, ale uznałem, że nazwa lepiej się sprawdzi. Gdybym coś zyskiwał używając tylko wektorów zamiast np. map to zrobiłbym to.
Jeżeli masz własna koncepcję to przedstaw ją, ale tak bym mógł to przetestować i sprawdzić, czy rzeczywiście jest to lepsze w ujęciu całościowym, a nie w odniesieniu tylko do jednej funkcji programu.

[polymorphism]

Ty zakładasz, że są stosy w ściśle określonym miejscu (...)

Nie zakładam, tylko tak jest, nawet w Twojej aplikacji.

nawet gdyby tak było, to i tak gdzieś trzeba by przechowywać numer stosu na którym karta się znajduje

A po co?!

Wcale nie wygodniej, gdzieś musiałbym trzymać informacje o pozycji kart w bitmapie

Oczywiście, że nie. Wszystkie karty mają taką samą szerokość, wystarczy indeks karty pomnożyć przez jej szerokość.

Dla mnie lepszym rozwiązaniem jest użycie mapy,

Powinieneś kierować się tym, co jest obiektywnie lepsze, szczególnie gdy tłumaczysz coś początkującemu.

Logika programu nie wymaga również by to były identyfikatory liczbowe (...)

Czyżby? Przykład:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

for(int i = vCards.size() - 1; i >= 0; i--)
{
        ...
        POINT &pt = mCards[vCards[i ]];
        ...                    
}

robisz:

i (identyfikator liczbowy) tekst pt (wartość)

zamiast:

i (identyfikator liczbowy) pt (wartość)

Podejrzewam, że znalazłbym więcej tego typu odwołań.

p.s. przypominam, że każde odwołanie do elementu w mapie poprzez operator[] ma złożoność logarytmiczną. To nie tablica.

Patrze STRINGTABLE w zasobach id_cards.rc:

Ale tam typu wyliczeniowego nie ma. Zresztą nieważne. Wiem, o co Ci chodzi...

Jeżeli masz własna koncepcję to przedstaw ją, ale tak bym mógł to przetestować i sprawdzić,

Nie bardzo rozumiem, na czym miałoby to testowanie polegać, przecież ja nie piszę w VCL-u, a kod w wx'ach nic by Ci nie dał. Wizualnie wyglądałoby to podobnie, więc nie wiem, co te testy by dały.

Jeśli chodzi o samą koncepcję, jest prosta - vectory trzymające indeksy kart.

[Cyfrowy Baron]

Tak więc czeri ma już wybór, może to zrobić po Twojemu, może trzymać się mojej koncepcji, gdyż już jej nie zmienię i do końca będę to ciągnął, możesz również stworzyć własną koncepcję opartą jak to chciał początkowo na TStringList i TImageList. Ty możesz przedstawić zupełnie inny program, możesz też nanosić poprawki do kodu który będę tutaj przedstawiał. I to w zasadzie powinno zakończyć tą dyskusję. Gdybym zaczynał ten program od początku i uwzględniłbym Twoje uwagi to w efekcie i tak dotarłbym do punktu w którym jestem. Rozważałem użycie tylko wektora z indeksami zasobów, ale niestety program nie działa tak jak to założyłem, więc w moim programie pozostaną wektor do przechowywania nazw identyfikatorów, chociaż zmiana na identyfikatory liczbowe nie pociągałaby za sobą zmian w reszcie kodu, pozostanie mapa do przechowywania pozycji kart, gdyż jest potrzebna i nie widzę sposobu na to my zamienić ją na wektora, a stosów w zasadzie niema, gdyż te cztery stosy na początku to stworzyłem tylko by zobrazować jak to ma wyglądać i moja koncepcja wogóle nie zakłada istnienia stosów jako takich, mogą oczywiście powstać w trakcie grania, ale całość opiera się i tak na kartach a nie na stosach. Moja koncepcja zakłada również stworzenie jeszcze jednej mapy z kluczem String i wartością int reprezentującą wartość karty.
W taki sposób będę rozwijał ten program i taką koncepcję będę stosował, gdy zostanie zadane pytanie odnośnie tego co już tutaj przedstawiłem.
Udzielając odpowiedzi w wątku zwracaj się raczej do czeri i to jemu proponuj rozwiązania, gdyż to nie ja tworzę ten program i jeżeli natknę się na problem, którego nie będę w stanie rozwiązać, to porzucę projekt o czeri sam będzie musiał dalej kombinować. Póki co to w zasadzie ja tworzę ten projekt i poza tym co zaproponowałem w tym temacie to nic więcej nie istnieje, może poza Twoją niedokończoną koncepcją, ale ja nie będę rozwijał Twojej koncepcji, gdyż nie pasuje do tego co sam opracowałem.

[polymorphism]

Udzielając odpowiedzi w wątku zwracaj się raczej do czeri i to jemu proponuj rozwiązania, gdyż to nie [ja(?)] tworzę ten program (...)
Póki co to w zasadzie ja tworzę ten projekt (...)

No i dlatego z Tobą dyskutuje na ten temat, a nie z czerim.

[Cyfrowy Baron]

Ja jednak koncepcji nie zmienię, gdyż to co proponujesz nie będzie działać, a to dlatego, że ja wogóle nie zakładam w programie istnienia stosów, lecz pojedyncze karty, a tak wogóle to program rozwijałem udzielając odpowiedzi na konkretne pytania, a nie tworząc grę. W dalszej części pracy nad tą grą konieczne będzie stworzenie stosów jednak ja będę się trzymał wektora i map. Dodanie stosów wymaga opracowania nowej koncepcji, jednak ja nie jestem zdeterminowany dokończyć tą grę. Pokazuję możliwości, całą grę będzie musiał stworzyć czeri.

[czeri]

Dzięki za wszystkie koncepcje napewano skorzystam, ale dopiero po sesji, bo Chcę napisać tego pasjansa (miał być na projekt ale będzie po) Tylko muszę przysiąść przy tym na dłużej, żeby zrozumieć kod i co z czego się bierze i na co wpływa, bo nie ukrywam nie jest to łatwy kod jak dla mnie