Autor Wątek: C++ Problem ze stworzeniem ekwipunku.  (Przeczytany 23201 razy)

Offline Estivo

  • Użytkownik
    • Blog

# Styczeń 06, 2014, 19:06:34
Kompilator : MinGW GCC 4.7.2 32-bit wydania
Building Makefile " H : \ Nevermore \ Ekwipunek \ Makefile.win "
Wykonywanie zrobić ...
mingw32 - make.exe - f " H : \ Nevermore \ Ekwipunek \ Makefile.win " wszystko
g+ + . exe - c Ekwipunek.cpp -o Ekwipunek.o - I " C :/ Program Files/Dev-Cpp/MinGW32/include " - I " C :/ Program Files/Dev-Cpp/MinGW32/lib/gcc/mingw32 / 4.7.2/include/c + + "

W pliku zawarte z Ekwipunek.cpp : 02:00 :
Ekwipunek.hpp : 15:42 : ostrzeżenie: nie- statyczne inicjalizatory członkowskie danych tylko z - std = c + 11 lub - std = gnu + +11 [ domyślnie włączona ]

Ekwipunek.hpp : 16:55 : error : oczekiwano ';' na końcu deklaracji członkiem
Ekwipunek.hpp : 15:35 : error : ' nullptr "nie został uznany w tym zakresie
Ekwipunek.hpp : 15:42 : ostrzeżenie: rozszerzone listy inicjator dostępne tylko z - std = c + 11 lub - std = gnu + +11 [ domyślnie włączona ]
Ekwipunek.cpp : 03:27 : error : zmienna lub pole ' CEkwipunekzalozRzecz " unieważnione
Ekwipunek.cpp : 03:27 : error : ' Gniazdo ' nie został zadeklarowany w tym zakresie
Ekwipunek.cpp : 03:50 : error : Oczekuje wyrażenie podstawowej przed "*" tokenu
Ekwipunek.cpp : 03:51 : error : ' przedmiot ' nie został zadeklarowany w tym zakresie
H : \ Nevermore \ Ekwipunek \ Makefile.win : 34 : przepis na celu " Ekwipunek.o 'nie powiodło się
mingw32 - make.exe : *** [ Ekwipunek.o ] Błąd 1

Proszę.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Acarin1995

  • Użytkownik

# Styczeń 06, 2014, 20:48:21
Jak to naprawić?

Offline ArekBal

  • Użytkownik

# Styczeń 06, 2014, 21:35:28
Właśnie Estivo:
Cytuj
Jak to naprawić?
;)

Offline Xirdus

  • Redaktor

# Styczeń 06, 2014, 21:38:16
Jak to naprawić?
Włączyć C++11. Albo zrezygnować z list inicjalizujących (tzn. tamtego {nullptr}).

Nigdy nie wkejaj do swojego projektu kodu którego nie rozumiesz. Albo go najpierw zrozum, albo zrób daną rzecz w inny, prostszy dla ciebie sposób.

Uprzedzam: stąpasz po bardzo cienkiej nici, kolego - nie lubimy tutaj ludzi typu "zróbcie za mnie grę". Nikt nie ma tutaj chęci myśleć i pisać kod za ciebie. Możemy cię jedynie nakierować jak to masz zrobić samemu. Kolejna prośba o napisanie kodu na cośtam poskutkuje zamknięciem tematu i ostrzeżeniem.



A teraz pozwól że kontynuuję offtopową dyskusję z Estivo :)
Chyba za bardzo patrzyłem przez pryzmat gry niekonsolowej, stąd rozgraniczenie gracz i npc, ale o do "ekwipunku" npc, to zawsze może mieć tylko eq[5] i loot[2] i jest to zawsze mniej i łatwiej obsłużyć niż robić kolejne eq[25] z racji, że było by około 20 pustych elementów (ofc jeżeli byłby to vector bez zarezerwowanego rozmiaru, to inna sprawa).
eq[5] jest dokładnie tak samo skomplikowane jak eq[25]. eq[5] i loot[2] jest bardziej skomplikowane od eq[25], bo masz dwie tablice a nie jedną (choć pozwala to na loot niezależny od prawdziwego ekwipunku). To o czym mówisz to zużycie pamięci - ostatnia rzecz, która powinna OP obchodzić. vector jest lepszy od gołej tablicy też z kilku innych powodów, przede wszystkim znasz dokładny rozmiar bez żadnej dodatkowej zmiennej.

Zawsze można zrobić wskaźnik na ekwipunek, i jeżeli pusty to wiemy ze nie jest graczem, bądź nie ma nic do wypadnięcia. dużo jest możliwość, tylko zależy co się chce osiągnąć.
W grze masz 1 gracza i dziesiątki NPC. Jeśli te dziesiątki NPCów mają jedno pole które zawsze jest nullem tylko po to, by tą samą klasą można było objąć gracza, to coś jest bardzo nie tak z twoim designem. Jeśli oddzielisz ekwipunek od gracza, problem znika - nie ma żadnego wskaźnika który musisz nullować.

Hmm nie wiem po co pchać tu coś w unie. Chodziło mi by zrobił eq na normalniej tablicy, a nie na vectorze, bo tutaj mamy stały rozmiar eq(chyba, że gracz kupi większy plecak).
Sory, kawałek o uniach napisałem dlatego że myślałem, że chcesz trzymać przedmioty przez wartość.

Kwestia CPrzedmiot. Chciał sprzedawać więc musi dodać unsigned (short - 65k ) int wartość, czy tam cena, który będzie trzymał np. wartość zakupu, a sprzedażny była by 3 razy mniejsza.
Tak. Warto tu zaznaczyć, że jeśli OP będzie chciał dodać do przedmiotów jakąkolwiek właściwość, to będzie musiał utworzyć dodatkową zmienną ;) BTW - znowu niepotrzebnie martwisz się o pamięć. W znakomitej większości przypadków int będzie tak samo dobry, jak nie lepszy od short.

Offline Estivo

  • Użytkownik
    • Blog

# Styczeń 06, 2014, 21:57:32
Cytuj
eq[5] jest dokładnie tak samo skomplikowane jak eq[25]. eq[5] i loot[2] jest bardziej skomplikowane od eq[25], bo masz dwie tablice a nie jedną (choć pozwala to na loot niezależny od prawdziwego ekwipunku). To o czym mówisz to zużycie pamięci - ostatnia rzecz, która powinna OP obchodzić. vector jest lepszy od gołej tablicy też z kilku innych powodów, przede wszystkim znasz dokładny rozmiar bez żadnej dodatkowej zmiennej.

I tak i nie. To już zależne kto jak spogląda na świat. Mnie byłoby wygodniej trzymać taką tablice niż vector.

Cytuj
W grze masz 1 gracza i dziesiątki NPC. Jeśli te dziesiątki NPCów mają jedno pole które zawsze jest nullem tylko po to, by tą samą klasą można było objąć gracza, to coś jest bardzo nie tak z twoim designem. Jeśli oddzielisz ekwipunek od gracza, problem znika - nie ma żadnego wskaźnika który musisz nullować.

Ok a komunikacja gracz <-> eq? W takim przypadku najlepiej było by oddzielić CGracz, CNpc.

Cytuj
Tak. Warto tu zaznaczyć, że jeśli OP będzie chciał dodać do przedmiotów jakąkolwiek właściwość, to będzie musiał utworzyć dodatkową zmienną ;) BTW - znowu niepotrzebnie martwisz się o pamięć. W znakomitej większości przypadków int będzie tak samo dobry, jak nie lepszy od short.

Akurat nie chodziło mi tutaj o pamięć. Może po części, ale głównie z powodu, że i tak nie wykorzysta całości  u_int.

Myślę, że offtopu nam starczy ;)


// korekta tagów -Xirdus
« Ostatnia zmiana: Styczeń 06, 2014, 22:08:23 wysłana przez Xirdus »

Offline Acarin1995

  • Użytkownik

# Styczeń 15, 2014, 11:05:50
Witam ponownie... zrobiłem chwilowo coś w tym stylu:
i
//Postac.cpp
nt CPostac::usunzEkwipunku()
{
int slot = 0 ;
    cout << "Podaj cyfre slotu przedmiotu ktorego chcesz wyrzucic:" << endl ;
    cin >> slot ;
   
    if (slot >= 0 && slot < plecak.size())
    {
        int idplecak = plecak.size() - 1 ;
        plecak [slot] = plecak[idplecak] ;//replace element to be deleted with the last element in the vector
        plecak.pop_back () ; //delete last element
       
    }
   
    else if (slot == plecak.size())
    {
        cout << "Wyrzucono" << endl << endl ;
    }

}
int CPostac::wyswietlEkwipunek()
{
if (plecak.empty())   
            cout << "Nic nie masz w plecaku."<<endl;   
        else
{
cout << "Posiadasz w plecaku " << plecak.size() << " przedmiotow."<<endl;   
cout << ""<<endl;
        cout << "Twoje przedmioty:"<<endl;   
        for (int i = 0; i < plecak.size(); ++i)   
            {
            cout <<i<<"."<< plecak[i]->nazwa << endl;
        }
            cout<<""<<endl;
}     

}
int CPostac::uzyjPrzedmiot()
{

}

int CPostac::zalozPrzedmiot()
{
bron= new CSztylet;
}

int CPostac::zdejmijPrzedmiot()
{
}
i teraz mam pytanie nie wiem jak zrobić metodę: załóż i zdejmij przedmiot.... Sloty: Głowa, korpus, nogi, stopy, dlonie, lewa reka, prawa reka... Proszę o pomoc.

Offline Xirdus

  • Redaktor

  • +1
# Styczeń 15, 2014, 18:42:30
enum class Slot // enum class to jeden z bajerów C++11
{
    Reka,
    Noga,
    Tylek,
    Count // ten tutaj to nie slot, tylko ilość wszystkich slotów (musi byc na końcu)
}

class Player
{
    int equipment[Slot.Count];
}

Ten int to albo numer itema w bazie danych (jeśli ją zrobiłeś - patrz moje poprzednie posty), albo numer itema w plecaku (nie polecam, choć widzę że bardzo jesteś przywiązany do idei "założone itemy zostają w plecaku" - brotip: nie rób tego jeśli nie musisz). Możesz zastąpić inta stringiem (jeśli na nim opierasz bazę danych) lub inteligentnym wskaźnikiem na klasę bazową przedmiotu (nie polecamale działa).

I po raz kolejny mówię: nie rób osobnej klasy na każdy przedmiot!

Offline Acarin1995

  • Użytkownik

# Styczeń 15, 2014, 20:03:44
Każdy typ broni np. miecz ma inne statystyki. np. miecz ma szybkość ataku 1.0 a sztylety 1,2 topory 0.9. Z tego dziedziczyć będą pod typy... np. stalowy miecz, żelazny miecz. Nie wiele mi mówi ten kod. :(... Wolałbym by przedmiot znikał po założeniu z plecaka, jak i pojawiał się po zdjęciu. ;) Dzięki za pomoc.

Offline Xirdus

  • Redaktor

# Styczeń 15, 2014, 20:20:30
Każdy typ broni np. miecz ma inne statystyki. np. miecz ma szybkość ataku 1.0 a sztylety 1,2 topory 0.9. Z tego dziedziczyć będą pod typy... np. stalowy miecz, żelazny miecz.
Tera to żeś dowalił -.-

Klas powinno być jak najmniej. Im mniej klas tym lepiej. Żelazny miecz różni się od stalowego tylko siłą - więc ta sama klasa. Łuk różni się od miecza tylko siłą i rodzajem zadawanych obrażeń - ta sama klasa. Zbroja różni się od miecza wszystkim, a jedyne co je łączy to to że można je założyć - tak więc osobne klasy które dziedziczą po wspólnej klasie bazowej. Im mniej takich przypadków jak ten ostatni tym lepiej.

Offline Acarin1995

  • Użytkownik

# Styczeń 15, 2014, 20:31:52
Dzięki za poradę. W takim razie jak stworzyć przedmioty? I jak je nakładać by znikały z ekwipunku? można dodać do klasy CPancerz: enum Slot { korpus, glowa, nogi, stopy }; ale nie rozumiem jak to nakładać szukałem w internecie, ale tam co najwyżej było w innym stylu to robione i w dodatku na strukturach. Więc czy mogę prosić jakąś wskazówkę?

Offline Rolek

  • Użytkownik

  • +1
# Styczeń 15, 2014, 23:26:07
I jak je nakładać by znikały z ekwipunku?
Jak umieszczasz przedmiot w nowym slocie to usuwaj go ze starego.

Offline Xirdus

  • Redaktor

# Styczeń 16, 2014, 00:04:07
Dzięki za poradę. W takim razie jak stworzyć przedmioty? I jak je nakładać by znikały z ekwipunku? można dodać do klasy CPancerz: enum Slot { korpus, glowa, nogi, stopy }; ale nie rozumiem jak to nakładać szukałem w internecie, ale tam co najwyżej było w innym stylu to robione i w dodatku na strukturach. Więc czy mogę prosić jakąś wskazówkę?
Po pierwsze, struktury to dokładnie to samo co klasy (mówię o C++, bo w innych językach to już inna bajka). Generalnie klas używa się to obiektów bez publicznych zmiennych, a struktur do obiektów bez metod.

Po drugie, nikt ci nie napisze gry. Ekwipunek jest zbyt blisko związany z całą resztą architektury gry żeby można było skopiować czyjś kod i wkleić do twojego projektu. Żeby takie coś zadziałało, musiałbyś skopiować od razu całą grę. Dlatego lepiej, żebyś podpatrzył sobie jak to robią inni, a w swojej grze wymyślić to od podstaw, całkowicie po swojemu.

Offline Acarin1995

  • Użytkownik

# Styczeń 16, 2014, 07:41:06
Hm... W takim razie trzeba stworzyć vektory przechowujące po jednym przedmiocie? Czy istnieje jakiś bardziej optymalny sposób? Bo sloty są jako typ wyliczeniowy a więc jak pod nie podpisać przedmioty by znikały z plecaka? Vektorami? Oraz jak tworzyć przedmioty np. Miecz nie będące klasami?

Offline Estivo

  • Użytkownik
    • Blog

# Styczeń 16, 2014, 08:36:07
Eh człowieku.
1. Zrób sobie klasę item, która będzie dziedziczona w klasie np. weapon i armor. Czy mają się różnić to chyba powinieneś wiedzieć.

2. w klasie bohatera zrób sobie wskaźnik weapon* bron; armor *cos[4]; i trzymaj wskaźniki na te cale itemki, a gdy będziesz je zdejmował to wskaźnik równaj do nullptr (NULL)

3.Bron trzymaj w jakimś kontenerze i wyłuskuj z niego adres po ID (np. player.equip(items.getItemByID(2)) ) i tyle

Prostszego rozwiązania nie widzę.

Co do struktur, to klasa z wszystkimi elementami publicznymi ;) Też może dziedziczyć i być dziedziczna.

Offline Rolek

  • Użytkownik

# Styczeń 16, 2014, 11:15:52
Bo sloty są jako typ wyliczeniowy a więc jak pod nie podpisać przedmioty by znikały z plecaka?
Zrób sobie "item" Nic i wypełniaj nim puste sloty.