07.09.2017 03:49
[#391]
Re: Zapowiedzi nowych gier
@Hexmage960, post #390
Ostatnio mam kilka obowiązków, więcej czasu będę miał w drugiej połowie września. Jednakże przygotowałem trochę grafiki do gry strategicznej - zróżnicowaną ziemię.
Zawsze miałem problem z namalowaniem trawy, ziemi, tym razem udało mi się to całkiem dobrze. Efekt możecie obejrzeć poniżej. W ostatniej chwili manipulowałem trochę z paletą, dałem więcej zieleni.
Jak widzicie grafika nie tyczy się Diuny, ale zupełnie innej scenerii, zniszczonej Konfliktem ziemi. Cel jednak jest ten sam.
Od pewnego czasu bardzo dobrze się czuję i kontynuuję wreszcie raz zaczęte projekty. Na pewno przygotuję coś grywalnego na GameDev Compo. Daję słowo, że wreszcie doczekałem się tego, na co czekałem wiele lat, czyli zdrowia.
Spodziewajcie się również mojego artykułu o asemblerze w najnowszym Amigazynie.
Jeśli macie uwagi co do zamieszczonej grafiki to śmiało piszcie, choć tak jak napisałem do połowy września nie będę miał czasu na poprawki.
Później jednak zajmę się poprawianiem i ulepszaniem tej grafiki. Ale pamiętajcie, że lepsze jest wrogiem dobrego.
Pozdrawiam serdecznie.
Zawsze miałem problem z namalowaniem trawy, ziemi, tym razem udało mi się to całkiem dobrze. Efekt możecie obejrzeć poniżej. W ostatniej chwili manipulowałem trochę z paletą, dałem więcej zieleni.
Jak widzicie grafika nie tyczy się Diuny, ale zupełnie innej scenerii, zniszczonej Konfliktem ziemi. Cel jednak jest ten sam.
Od pewnego czasu bardzo dobrze się czuję i kontynuuję wreszcie raz zaczęte projekty. Na pewno przygotuję coś grywalnego na GameDev Compo. Daję słowo, że wreszcie doczekałem się tego, na co czekałem wiele lat, czyli zdrowia.
Spodziewajcie się również mojego artykułu o asemblerze w najnowszym Amigazynie.
Jeśli macie uwagi co do zamieszczonej grafiki to śmiało piszcie, choć tak jak napisałem do połowy września nie będę miał czasu na poprawki.
Później jednak zajmę się poprawianiem i ulepszaniem tej grafiki. Ale pamiętajcie, że lepsze jest wrogiem dobrego.
Pozdrawiam serdecznie.
07.09.2017 09:29
[#393]
Re: Zapowiedzi nowych gier
@Koyot1222, post #392
Tak, pora wczesna, szczerze mówiąc to późna, jako że do późna wczoraj siedziałem przy DPaincie.
Będę to kontynuował, wyleczyłem się z tego problemu niemożności powrotu do rozpoczętych projektów. Naprawdę był to problem chorobowy. Coś tam w głowie przeszkadzało.
Piszę też równocześnie silnik, ale zbyt wcześnie by coś pokazywać.
Grafika w obecnej formie jest niezła, mała powtarzalność dzięki wielu kafelkom, no i miła dla oka. Mam zamiar zrobić poprawki - dodać więcej kolorów, no i zabrać się za jakieś budynki.
W każdym razie rysuje mi się dużo przyjemniej (programuje również).
Będę to kontynuował, wyleczyłem się z tego problemu niemożności powrotu do rozpoczętych projektów. Naprawdę był to problem chorobowy. Coś tam w głowie przeszkadzało.
Piszę też równocześnie silnik, ale zbyt wcześnie by coś pokazywać.
Grafika w obecnej formie jest niezła, mała powtarzalność dzięki wielu kafelkom, no i miła dla oka. Mam zamiar zrobić poprawki - dodać więcej kolorów, no i zabrać się za jakieś budynki.
W każdym razie rysuje mi się dużo przyjemniej (programuje również).
13.11.2017 18:03
[#394]
Re: Zapowiedzi nowych gier
@Hexmage960, post #393
Hej! Ja odkopuję wątek by tylko wkleić moją ostatnią pracę (napisałem ten dokument kilka dni temu). Określiłem już wszystkie niezbędne elementy silnika mojego RTSa. Ostatni fragment dot. silnika rysującego jeszcze nie jest gotowy. Najważniejszy jest jednak punkt 1 i 2, które są dość wyczerpująco opisane.
Na bazie tego dokumentu jestem w stanie podjąć pracę nad grą.
Proszę się nie martwić, że rzucam sporo teorii a mało praktyki - zapewniam, że część tych wywodów już realizuję w postaci kodu.
Miłego czytania.
--
Projekt Dune 3.
Jest to wielopłaszczyznowy projekt.
Liczy się systematyczna praca.
1. Pomysł.
Absolutny punkt nr 1 pracy to pomysł.
Gra będzie klonem Dune 2 z ulepszonym interfejsem
oraz dodatkowymi elementami.
Co to jest ulepszony interfejs?
- Zaznaczanie wielu jednostek na raz;
- Wygodniejsze wydawanie poleceń.
Co to za dodatkowe elementy?
- Tryby gry: potyczka;
- Dobry gracz komputerowy;
- Opcjonalnie: tryb dla wielu graczy.
Zacznę pracę od napisania silnika gry.
Jednocześnie będzie tworzony konstruktor gry.
Silnik dzieli się jednak na wiele elementów.
Określmy i opiszmy je.
2. Podział i Plan Pracy
A. Silnik RTS - jest to mechanizm współdziałania takich elementów,
jak pole gry, jednostki, budynki, pociski, wybuchy i inne elementy.
B. Wyświetlanie i aktualizacja bieżącego pola bitwy na ekranie.
C. Interfejs do wydawania poleceń.
Przy czym Interfejs (punkt C) można zastąpić graczem komputerowym.
Wyświetlanie (punkt B) będzie optymalizowane pod względem szybkości
oraz wykorzystania pamięci graficznej.
Z kolei punkt B (również C) można zastąpić przez konsolę (na etapie
budowania gry).
Silnik RTS to podstawowy element. Co potrzebujemy? Zestawmy elementy:
- Pole gry - jest to obszar, na którym rozgrywa się bitwa.
Charakterystyka:
- Składa się z kwadratowych pól;
- Posiada wymiary - szerokość oraz wysokość;
- Każde pole składa się z kilku elementów:
- Ikona grafiki terenu (ustalona);
- Ilość surowca na polu (0%-100%), dotyczy pól przyprawowych;
- Wytrzymałość betonu (0%-100%), dotyczy płyt i murów betonowych;
- Obiekt powiązany z polem, np. jednostka, budynek itp.
- Obiekty, dzielą się na:
- Budynki, prostokątny zestaw pól (np. 2x2 lub 3x3) który
symbolizuje budynek. Struktura budynku jest zdefiniowana na zewnątrz,
zaś na polu jest numer tej struktury.
Struktura posiada szereg pól charakteryzujących strukturę, jak:
- Punkty wytrzymałości (0%-100%);
- Ród, do którego budynek należy;
- Współrzędne lewego górnego rogu budynku;
- itp.
- Jednostki, podobnie jak budynki, okupują pola, przy czym w odróżnieniu
od nich, mogą się przemieszczać na sąsiednie pola.
Ich pozycja określona jest przez pole, które zajmują oraz - pole
do którego się przemieszczają i przesunięcie (0-15).
- Pociski - są to animowane obiekty, posiadające tylko kilka cech.
- Wybuchy i inne animacje - są to animowane obiekty zajmujące pola,
nieruchome.
- Rody, posiadają szereg informacji nt. poszczególnych stron konfliktu.
Posiadają też takie informacje jak np. zużycie energii elektrycznej
przez budynki, ilość kredytów i inne.
- Statystyki - opisują pewne charakterystyki elementów w grze, modyfikowane
dla każdej mapy, lub przez edytor świata gry, jak np. prędkość jednostek,
ich koszt budowy, punkty wytrzymałości różnych pancerzy, czy
zasięg wież itp.
- Wydarzenia - elementy dodatkowe powiązane z mapą, jak np. zadania
do wykonania na danej mapie i inne rzeczy urozmaicające rozgrywkę itp.
Poza tym dochodzą wszelakie rzeczy dot. kampanii itp., ale to już
poza głównym silnikiem.
Wyświetlanie i aktualizacja:
Co jakiś odcinek czasu aktualizowany jest obraz na monitorze.
Dla Dune 3 będzie odbywać się to z częstotliwością 50 Hz.
Obiekty animowane będą aktualizowane w tym tempie (ich pozycja, klatka
animacji). Jednakże pozostałe elementy będą aktualizowane rzadziej.
Rysowanie będzie odbywać się za pomocą Blittera (kopiowanie, przesuw)
oraz - CPU (tekstury, transpozycja), pod kontrolą Coppera.
Na linii 0 Coppera, będzie ładowana nowa Copperlista. Następnie co linijkę
będzie wykonywany specjalny program, który aktualizuje grafikę na ekranie
w sposób szybki i zoptymalizowany, wykorzystujący CPU i Blitter pod kontrolą
Coppera.
Jak to będzie działać?
Otóż w pamięci będzie zlokalizowany program, co zrobić z danym fragmentem
ekranu (wskazywany przez bitplany: a0, a1, a2, a3) oraz, jak daleko skoczyć.
CPU będzie zajmował się jednym playfieldem, a Blitter - drugim.
Przykład:
Polecenie będzie zapisane w 32 bitach. W młodszym słowie będzie polecenie,
a w starszym - argument. Dalsze argumenty będą w kolejnych słowach.
Polecenie nr 0 mówi: wyczyść pamięć (wstaw zera) w kolejnych n słowach.
move.l (a0),d0 ; Pobieramy polecenie
move.w (a1,d0.w*2),d1 ; Pobieramy offset
jsr (a2,d1.w*2) ; Skaczemy
...
swap d1 ; Pobieramy argument
.next:
clr.l (a3) ; Czyścimy bitplany
clr.l BPR(a3)
clr.l BPR*2(a3)
clr.l BPR*3(a3)
adda.l #4,a3
dbf d1,.next
rts
Na bazie tego dokumentu jestem w stanie podjąć pracę nad grą.
Proszę się nie martwić, że rzucam sporo teorii a mało praktyki - zapewniam, że część tych wywodów już realizuję w postaci kodu.
Miłego czytania.
--
Projekt Dune 3.
Jest to wielopłaszczyznowy projekt.
Liczy się systematyczna praca.
1. Pomysł.
Absolutny punkt nr 1 pracy to pomysł.
Gra będzie klonem Dune 2 z ulepszonym interfejsem
oraz dodatkowymi elementami.
Co to jest ulepszony interfejs?
- Zaznaczanie wielu jednostek na raz;
- Wygodniejsze wydawanie poleceń.
Co to za dodatkowe elementy?
- Tryby gry: potyczka;
- Dobry gracz komputerowy;
- Opcjonalnie: tryb dla wielu graczy.
Zacznę pracę od napisania silnika gry.
Jednocześnie będzie tworzony konstruktor gry.
Silnik dzieli się jednak na wiele elementów.
Określmy i opiszmy je.
2. Podział i Plan Pracy
A. Silnik RTS - jest to mechanizm współdziałania takich elementów,
jak pole gry, jednostki, budynki, pociski, wybuchy i inne elementy.
B. Wyświetlanie i aktualizacja bieżącego pola bitwy na ekranie.
C. Interfejs do wydawania poleceń.
Przy czym Interfejs (punkt C) można zastąpić graczem komputerowym.
Wyświetlanie (punkt B) będzie optymalizowane pod względem szybkości
oraz wykorzystania pamięci graficznej.
Z kolei punkt B (również C) można zastąpić przez konsolę (na etapie
budowania gry).
Silnik RTS to podstawowy element. Co potrzebujemy? Zestawmy elementy:
- Pole gry - jest to obszar, na którym rozgrywa się bitwa.
Charakterystyka:
- Składa się z kwadratowych pól;
- Posiada wymiary - szerokość oraz wysokość;
- Każde pole składa się z kilku elementów:
- Ikona grafiki terenu (ustalona);
- Ilość surowca na polu (0%-100%), dotyczy pól przyprawowych;
- Wytrzymałość betonu (0%-100%), dotyczy płyt i murów betonowych;
- Obiekt powiązany z polem, np. jednostka, budynek itp.
- Obiekty, dzielą się na:
- Budynki, prostokątny zestaw pól (np. 2x2 lub 3x3) który
symbolizuje budynek. Struktura budynku jest zdefiniowana na zewnątrz,
zaś na polu jest numer tej struktury.
Struktura posiada szereg pól charakteryzujących strukturę, jak:
- Punkty wytrzymałości (0%-100%);
- Ród, do którego budynek należy;
- Współrzędne lewego górnego rogu budynku;
- itp.
- Jednostki, podobnie jak budynki, okupują pola, przy czym w odróżnieniu
od nich, mogą się przemieszczać na sąsiednie pola.
Ich pozycja określona jest przez pole, które zajmują oraz - pole
do którego się przemieszczają i przesunięcie (0-15).
- Pociski - są to animowane obiekty, posiadające tylko kilka cech.
- Wybuchy i inne animacje - są to animowane obiekty zajmujące pola,
nieruchome.
- Rody, posiadają szereg informacji nt. poszczególnych stron konfliktu.
Posiadają też takie informacje jak np. zużycie energii elektrycznej
przez budynki, ilość kredytów i inne.
- Statystyki - opisują pewne charakterystyki elementów w grze, modyfikowane
dla każdej mapy, lub przez edytor świata gry, jak np. prędkość jednostek,
ich koszt budowy, punkty wytrzymałości różnych pancerzy, czy
zasięg wież itp.
- Wydarzenia - elementy dodatkowe powiązane z mapą, jak np. zadania
do wykonania na danej mapie i inne rzeczy urozmaicające rozgrywkę itp.
Poza tym dochodzą wszelakie rzeczy dot. kampanii itp., ale to już
poza głównym silnikiem.
Wyświetlanie i aktualizacja:
Co jakiś odcinek czasu aktualizowany jest obraz na monitorze.
Dla Dune 3 będzie odbywać się to z częstotliwością 50 Hz.
Obiekty animowane będą aktualizowane w tym tempie (ich pozycja, klatka
animacji). Jednakże pozostałe elementy będą aktualizowane rzadziej.
Rysowanie będzie odbywać się za pomocą Blittera (kopiowanie, przesuw)
oraz - CPU (tekstury, transpozycja), pod kontrolą Coppera.
Na linii 0 Coppera, będzie ładowana nowa Copperlista. Następnie co linijkę
będzie wykonywany specjalny program, który aktualizuje grafikę na ekranie
w sposób szybki i zoptymalizowany, wykorzystujący CPU i Blitter pod kontrolą
Coppera.
Jak to będzie działać?
Otóż w pamięci będzie zlokalizowany program, co zrobić z danym fragmentem
ekranu (wskazywany przez bitplany: a0, a1, a2, a3) oraz, jak daleko skoczyć.
CPU będzie zajmował się jednym playfieldem, a Blitter - drugim.
Przykład:
Polecenie będzie zapisane w 32 bitach. W młodszym słowie będzie polecenie,
a w starszym - argument. Dalsze argumenty będą w kolejnych słowach.
Polecenie nr 0 mówi: wyczyść pamięć (wstaw zera) w kolejnych n słowach.
move.l (a0),d0 ; Pobieramy polecenie
move.w (a1,d0.w*2),d1 ; Pobieramy offset
jsr (a2,d1.w*2) ; Skaczemy
...
swap d1 ; Pobieramy argument
.next:
clr.l (a3) ; Czyścimy bitplany
clr.l BPR(a3)
clr.l BPR*2(a3)
clr.l BPR*3(a3)
adda.l #4,a3
dbf d1,.next
rts
13.11.2017 19:12
[#396]
Re: Zapowiedzi nowych gier
@Krashan, post #395
Ten fragment kodu źródłowego w asemblerze to tylko przykładowa ilustracja, zresztą mocno niedopracowana.
Silnik rysujący będę opracowywał, ale to dopiero jako punkt B (czyli później).
Tak jak napisałem, najważniejsze są paragrafy Pomysł oraz Plan/podział pracy bo te są w gruncie rzeczy kompletne.
Ostatnia aktualizacja: 13.11.2017 19:16:52 przez Hexmage960
Silnik rysujący będę opracowywał, ale to dopiero jako punkt B (czyli później).
Tak jak napisałem, najważniejsze są paragrafy Pomysł oraz Plan/podział pracy bo te są w gruncie rzeczy kompletne.
Ostatnia aktualizacja: 13.11.2017 19:16:52 przez Hexmage960
13.11.2017 20:04
[#397]
Re: Zapowiedzi nowych gier
@Hexmage960, post #394
Hex,
pomijam ten ciąg znaków na dole bo nic mi on nie mówi. (I rację ma Krashan że mieszanie kodu i scenarisza gry w jednym poście to jest słaby pomysł. Za moment będzie tu niezłe San Francisco)
Próbuję natomiast poukładać sobie w głowie ten plan i powiem CI że jest jakiś taki mocno chaotyczny (dla mnie). Co chwile jest pole.. pole jest obszarem gry a za moment chyba pole jest kafelkiem terenu. Przeskakujesz z zagadnienia na zagadnienie nie rozróżniając tego w żaden sposób. (bez urazy, jakbym z moją gadał. Rozpocznie mi 6 tematów zanim dotrze do mnie ten pierwszy)
Mam wrażenie że to jest bardziej twój szkic/brudnopis w którym część rzeczy siedzi nadal w Twojej głowie a zapisane jest tylko słowo klucz, niż plan produkcji którym można/należy się podzielić.
Co to np jest ustalona ikona grafiki terenu?
Dlaczego pod rodem masz podpięte info o zużyciu energii na budynku a np nie ma charakterystyk pojazdów... czy może bardziej charakterystyk pojazdów specjalnych dla danej frakcji.
Dodatkowa funkcjonalność w postaci trybów gry... rozumiem że kampania też będzie?
Interfejs do wydawania poleceń można zastąpić graczem komputerowym? WTF? To jak mam wydawać polecenia jednostkom? auto-calculate battle?
Oddziel sobie część "fabularną" od mechaniki (gry) od kodu.
Spisz sobie osobno w pierwszej to co ma być dla gracza widoczne/używalne. Scenariusze, kampanie, grafika, muzyka... to co widzi użytkownik końcow i z czym może coś zrobić.
Osobno opisz sobie co powoduje że dzieje się to powyżej w kontekście mechaniki gry. Tu wpadną statystyki budynków, pojazdów, drzewka rozwoju, tryby rozgrywki, mechanizm działania poszczególnych rzeczy w odniesieniu do elementów gry (jeśli chcesz miećczołg wybuduj fabrykę, elektrownię, i toi toia.. itp)
a całkiem osobno spisuj to jak powyższe A+B ma wyglądać w kodzie gry.
Tak przynajmniej ja bym zrobił żeby się nie zgubić w natłoki różnorodnych informacji podanych w jednym worku.
pomijam ten ciąg znaków na dole bo nic mi on nie mówi. (I rację ma Krashan że mieszanie kodu i scenarisza gry w jednym poście to jest słaby pomysł. Za moment będzie tu niezłe San Francisco)
Próbuję natomiast poukładać sobie w głowie ten plan i powiem CI że jest jakiś taki mocno chaotyczny (dla mnie). Co chwile jest pole.. pole jest obszarem gry a za moment chyba pole jest kafelkiem terenu. Przeskakujesz z zagadnienia na zagadnienie nie rozróżniając tego w żaden sposób. (bez urazy, jakbym z moją gadał. Rozpocznie mi 6 tematów zanim dotrze do mnie ten pierwszy)
Mam wrażenie że to jest bardziej twój szkic/brudnopis w którym część rzeczy siedzi nadal w Twojej głowie a zapisane jest tylko słowo klucz, niż plan produkcji którym można/należy się podzielić.
Co to np jest ustalona ikona grafiki terenu?
Dlaczego pod rodem masz podpięte info o zużyciu energii na budynku a np nie ma charakterystyk pojazdów... czy może bardziej charakterystyk pojazdów specjalnych dla danej frakcji.
Dodatkowa funkcjonalność w postaci trybów gry... rozumiem że kampania też będzie?
Interfejs do wydawania poleceń można zastąpić graczem komputerowym? WTF? To jak mam wydawać polecenia jednostkom? auto-calculate battle?
Oddziel sobie część "fabularną" od mechaniki (gry) od kodu.
Spisz sobie osobno w pierwszej to co ma być dla gracza widoczne/używalne. Scenariusze, kampanie, grafika, muzyka... to co widzi użytkownik końcow i z czym może coś zrobić.
Osobno opisz sobie co powoduje że dzieje się to powyżej w kontekście mechaniki gry. Tu wpadną statystyki budynków, pojazdów, drzewka rozwoju, tryby rozgrywki, mechanizm działania poszczególnych rzeczy w odniesieniu do elementów gry (jeśli chcesz miećczołg wybuduj fabrykę, elektrownię, i toi toia.. itp)
a całkiem osobno spisuj to jak powyższe A+B ma wyglądać w kodzie gry.
Tak przynajmniej ja bym zrobił żeby się nie zgubić w natłoki różnorodnych informacji podanych w jednym worku.
13.11.2017 20:27
[#398]
Re: Zapowiedzi nowych gier
@softiron, post #397
Mam wrażenie że to jest bardziej twój szkic/brudnopis w którym część rzeczy siedzi nadal w Twojej głowie a zapisane jest tylko słowo klucz, niż plan produkcji którym można/należy się podzielić.
Mój tekst jest rzeczywiście mocno techniczny i opisuje zagadnienia od strony dewelopera, a nie gracza.
I rację ma Krashan że mieszanie kodu i scenarisza gry w jednym poście to jest słaby pomysł.
Oczywiście zgoda.
Co to np jest ustalona ikona grafiki terenu?
Sorki, rzeczywiście to mocno techniczna sprawa. Postaram się wytłumaczyć:
Otóż jak mamy pole (komórkę) z ustalonym rodzajem terenu, to właściwa ikona jest dobierana w zależności od rodzaju terenu na polach sąsiadujących.
Ustalona ikona oznacza, że dobierane to jest przed właściwą rozgrywką, a nie na bieżąco.
Dlaczego pod rodem masz podpięte info o zużyciu energii na budynku a np nie ma charakterystyk pojazdów... czy może bardziej charakterystyk pojazdów specjalnych dla danej frakcji.
Ponieważ ród zawiera informacje ogólne dot. rodu w bieżącej rozgrywce (np. ilość czasu potrzebną do uzbrojenia następnego pocisku Death Hand).
Wszelakie charakterystyki masz w tzw. statystykach, o czym wspominam w dokumencie.
Dodatkowa funkcjonalność w postaci trybów gry... rozumiem że kampania też będzie?
Oczywiście kampania jest w planach.
Interfejs do wydawania poleceń można zastąpić graczem komputerowym? WTF? To jak mam wydawać polecenia jednostkom? auto-calculate battle?
No i znów przepraszam, bo to kwestia techniczna. Mianowicie jednostkom może wydawać polecania albo gracz za pomocą panelu dowodzenia, albo komputer za pomocą swojego panelu dowodzenia. Połączyłem te dwie rzeczy.
Oddziel sobie część "fabularną" od mechaniki (gry) od kodu.
Spisz sobie osobno w pierwszej to co ma być dla gracza widoczne/używalne. Scenariusze, kampanie, grafika, muzyka... to co widzi użytkownik końcow i z czym może coś zrobić.
Tak, taka dokumentacja rzecz jasna powstanie, ale w kolejności po tej deweloperskiej.
Osobno opisz sobie co powoduje że dzieje się to powyżej w kontekście mechaniki gry. Tu wpadną statystyki budynków, pojazdów, drzewka rozwoju, tryby rozgrywki, mechanizm działania poszczególnych rzeczy w odniesieniu do elementów gry (jeśli chcesz miećczołg wybuduj fabrykę, elektrownię, i toi toia.. itp)
Tak, statystyki, mechanika to rzecz bardzo ważna. Ja muszę najpierw stworzyć silnik, który będzie posiadał te parametry. Następnie będzie można te parametry dowolnie modyfikować.
Mam nadzieję, że nie ma już niejasności.
Próbuję natomiast poukładać sobie w głowie ten plan i powiem CI że jest jakiś taki mocno chaotyczny (dla mnie). Co chwile jest pole.. pole jest obszarem gry a za moment chyba pole jest kafelkiem terenu.
Uważam, że ten dokument za wyjątkiem ostatniego paragrafu nie jest zbyt chaotyczny. "Pole", jako komórka i "Pole gry" jako plansza to oczywiście dwa różne terminy.
Przygotuję jednakże dopracowaną, drugą wersję dokumentu, bo pracuję na bieżąco nad tym projektem.
Ostatnia aktualizacja: 13.11.2017 20:39:09 przez Hexmage960
13.11.2017 22:16
[#399]
Re: Zapowiedzi nowych gier
@Hexmage960, post #398
A olej Ty te dokumenty.
Siedzę teraz po uszy w OpenFire próbując napisać AI botów. Potem przyjdzie czas na kolejne pojazdy i inne ficzery a już teraz z mojego kodu robi się spaghetti. Oczywiście ktoś mądry mógłby powiedzieć że trzeba było sobie zaplanować. A guzik prawda. Sposób wyświetlania turretów zmieniał się już 2 razy i w kolejce jest trzeci, pewnie nie ostatni. Bo zmieniają się wymagania, zmienia się flow gry chcąc dodać kolejną rzecz i tamta implementacja najzwyczajniej w świecie na to nie pozwala. I tego nie przeskoczysz, bo trzeba by nie wiem ile lat to planować by uwzględnić wszystko, a potem gdzieś po drodze by się okazało że wszystko to działa za wolno i trzeba ficzery kroić.
Weź swój kod i zacznij lepić. Napiszesz jedną implementację. Jak okaże się że jest słaba w jakimś względzie to się zbranczujesz i napiszesz kolejną. Porównasz efekty końcowe i zostaniesz przy jednym z dwóch rozwiązań. I tak w kółko, A lub B. Po drodze ktoś zobaczy że z Twojego lepienia coś powstaje i być może dorzuci Ci się z grafiką. Być może ktoś się okaże też bardziej obcykany z UX i podpowie Ci jak zrobić ergonomiczny interfejs użytkownika. Okaże się że Twój kod Ci tego nie dźwignie i znowu będziesz musiał przerabiać. Nie unikniesz tego. A dokumentacja ważne żeby była w kluczowych momentach, nie musi być ładna, wystarczą komentarze w kodzie. Tak żebyś za miesiąc lub pół roku lub 3 lata później mógł do tego wrócić i szybko przypomnieć sobie jak to działa.
Zmuszenie gry do działania pod użytkownika + grafika to jakieś 20% tego co trzeba odwalić by zrobić przekonujące AI. Niech ta gra najpierw będzie brzydka, niech wymaga 060, niech ma najbardziej toporny interfejs i najgorsze scrollowanie ekranu. Ale niech będzie do zagrania, to potem będzie co szlifować. Mówiłeś mi w październiku że w obecnym stanie OpenFire może wypaść dobrze. A guzik, wypadło słabo (i słusznie) dlatego, że to był goły engine bez żadnego gameplayu. A po co Ci wygłaskana mechanika, skoro nie można tego wprawić w ruch żeby cieszyło?
To samo z c2p. Po kiego Ci ono, skoro potem nie masz pomysłu jak tego użyć (zwłaszcza w dune)? Potrzebowałem wygenerować 64 obroty klatek każdego pojazdu, więc zrobiłem to macierzą transformacji z najgorszym możliwym i najwolniejszym c2p jakie tylko można napisać. Jest badziewne ale robi robotę, bo potrzebuję go tylko podczas loadingu. Gdybym miał bezsensownie szlifować ten kawałek kodu to bym nigdy poza ten loading nie wyszedł.
Ostatnia aktualizacja: 13.11.2017 22:20:36 przez teh_KaiN
Siedzę teraz po uszy w OpenFire próbując napisać AI botów. Potem przyjdzie czas na kolejne pojazdy i inne ficzery a już teraz z mojego kodu robi się spaghetti. Oczywiście ktoś mądry mógłby powiedzieć że trzeba było sobie zaplanować. A guzik prawda. Sposób wyświetlania turretów zmieniał się już 2 razy i w kolejce jest trzeci, pewnie nie ostatni. Bo zmieniają się wymagania, zmienia się flow gry chcąc dodać kolejną rzecz i tamta implementacja najzwyczajniej w świecie na to nie pozwala. I tego nie przeskoczysz, bo trzeba by nie wiem ile lat to planować by uwzględnić wszystko, a potem gdzieś po drodze by się okazało że wszystko to działa za wolno i trzeba ficzery kroić.
Weź swój kod i zacznij lepić. Napiszesz jedną implementację. Jak okaże się że jest słaba w jakimś względzie to się zbranczujesz i napiszesz kolejną. Porównasz efekty końcowe i zostaniesz przy jednym z dwóch rozwiązań. I tak w kółko, A lub B. Po drodze ktoś zobaczy że z Twojego lepienia coś powstaje i być może dorzuci Ci się z grafiką. Być może ktoś się okaże też bardziej obcykany z UX i podpowie Ci jak zrobić ergonomiczny interfejs użytkownika. Okaże się że Twój kod Ci tego nie dźwignie i znowu będziesz musiał przerabiać. Nie unikniesz tego. A dokumentacja ważne żeby była w kluczowych momentach, nie musi być ładna, wystarczą komentarze w kodzie. Tak żebyś za miesiąc lub pół roku lub 3 lata później mógł do tego wrócić i szybko przypomnieć sobie jak to działa.
Zmuszenie gry do działania pod użytkownika + grafika to jakieś 20% tego co trzeba odwalić by zrobić przekonujące AI. Niech ta gra najpierw będzie brzydka, niech wymaga 060, niech ma najbardziej toporny interfejs i najgorsze scrollowanie ekranu. Ale niech będzie do zagrania, to potem będzie co szlifować. Mówiłeś mi w październiku że w obecnym stanie OpenFire może wypaść dobrze. A guzik, wypadło słabo (i słusznie) dlatego, że to był goły engine bez żadnego gameplayu. A po co Ci wygłaskana mechanika, skoro nie można tego wprawić w ruch żeby cieszyło?
To samo z c2p. Po kiego Ci ono, skoro potem nie masz pomysłu jak tego użyć (zwłaszcza w dune)? Potrzebowałem wygenerować 64 obroty klatek każdego pojazdu, więc zrobiłem to macierzą transformacji z najgorszym możliwym i najwolniejszym c2p jakie tylko można napisać. Jest badziewne ale robi robotę, bo potrzebuję go tylko podczas loadingu. Gdybym miał bezsensownie szlifować ten kawałek kodu to bym nigdy poza ten loading nie wyszedł.
Ostatnia aktualizacja: 13.11.2017 22:20:36 przez teh_KaiN
13.11.2017 23:51
[#400]
Re: Zapowiedzi nowych gier
@teh_KaiN, post #399
Siedzę teraz po uszy w OpenFire próbując napisać AI botów. Potem przyjdzie czas na kolejne pojazdy i inne ficzery a już teraz z mojego kodu robi się spaghetti. Oczywiście ktoś mądry mógłby powiedzieć że trzeba było sobie zaplanować. A guzik prawda.
Nie chcę niczego sugerować (bo mam mało doświadczenia, pewnie mniej niż Ty), ale może wystarczy zrobić swoją grę bardziej modularną? Czyli wydzielić część rysowania tych turretów?
Planowanie rzeczywiście nie uwzględnia wszystkiego. To jest krok początkowy tworzenia software. Później nazywa się to pielęgnacja. Ja sporo dokumentuję, bo lubię mieć czarno na białym jak ta gra ma wyglądać i z czego się składać.
I tego nie przeskoczysz, bo trzeba by nie wiem ile lat to planować by uwzględnić wszystko, a potem gdzieś po drodze by się okazało że wszystko to działa za wolno i trzeba ficzery kroić.
Zależy to od stopnia skomplikowania gry. Niektóre rzeczy w złożonej grze naprawdę trzeba zaplanować, szczególnie opisać złożony świat.
Ja działam w ten sposób, że najpierw obliczam koszt programu, tak żebym później nie był zaskoczony, że coś działa za wolno. Staram się zrobić porządny zapas, przy czym mam trochę bardziej komfortową sytuację bo robię dla A1200. Dla A500 optymalizacja gra dużo większą rolę, głównie ze względu na procesor.
Ja jakiś czas temu miałem problemy z płynną animacją obiektów na Amidze, jednak dzięki samozaparciu udało mi się te rzeczy rozwiązać.
Weź swój kod i zacznij lepić.
I tak się składa, że dziś wieczór sporo już ulepiłem.
Napisałem już w języku C takie elementy:
- Struktura pola i planszy (z atrybutami: rodzaj terenu, ikona, dodatek, czyli melanż lub beton oraz typ obiektu i obiekt),
- Funkcje alokacji mapy i ustawiania wybranych atrybutów pól,
- Zapis i odczyt plansz z plików Interchange File Format (IFF).
Dzięki zastosowaniu IFF mam możliwość rozbudowywania formatu mapy. Póki co są dwa chunki: DUNE MPHD zawierający nagłówek mapy, czyli wysokość i szerokość oraz DUNE MAP czyli właściwa dwuwymiarowa tablica złożona z pól. Zapis i odczyt działają dobrze.
Pisanie gry będę kontynuował w wolnym czasie.
Zmuszenie gry do działania pod użytkownika + grafika to jakieś 20% tego co trzeba odwalić by zrobić przekonujące AI. Niech ta gra najpierw będzie brzydka, niech wymaga 060, niech ma najbardziej toporny interfejs i najgorsze scrollowanie ekranu. Ale niech będzie do zagrania, to potem będzie co szlifować.
Jest to dobre podejście, ale moim zdaniem pewne rzeczy po prostu trzeba zrobić zawczasu.
Przede wszystkim konstrukcja gry musi być opracowana wcześniej, bo trudno takie coś później szlifować.
Oczywiście złym pomysłem jest robienie niemożliwych do realizacji założeń, typu planować ogromną liczba elementów gry. Lepiej budować grę stopniowo i dodawać do niej nowe atrakcje.
Dlatego warto narzucić sobie pewne ograniczenia, podobnie jak programiści narzucają sobie: program w 4kB, czy 64kB. W programowaniu na Amidze ta technika przydaje się, ze względu na przykład na ograniczoną pojemność dyskietki - 880kB.
To samo z c2p. Po kiego Ci ono, skoro potem nie masz pomysłu jak tego użyć (zwłaszcza w dune)?
Manipulacja grafiką w formacie chunky może się przydać. Na przykład do kilku efektów specjalnych. Być może też silnik rysujący będzie z niego korzystać (jako jeden z elementów). Piszę "może", bo silnikiem rysującym się jeszcze nie zająłem.
14.11.2017 08:34
[#401]
Re: Zapowiedzi nowych gier
@Hexmage960, post #400
Modularność w pełnym tego słowa znaczeniu sprawdza się tylko i wyłącznie na platformach nowożytnych gdzie masz zapas mocy przerobowej pozwalający na abstrakcję. Co z tego że rozdzieliłem sobie rysowanie i przeliczanie obiektów na ekranie, skoro przy pojazdach jedno trwało 10ms a drugie 3ms. Po zgnieceniu tego w jeden kod zszedłem do 10ms na obie te rzeczy. Dalsze optymalizacje skróciły ten czas jeszcze bardziej.
Wiele rzeczy będziesz robił po raz pierwszy. Wspomniane AI. Czas rzeczywisty. Różne tryby interakcji (tryb budowania, tryb sterowania jednostkami). Tutaj wiele rzeczy może Cię zaskoczyć i spowodować, że jednej rzeczy której nie przewidziałeś nie dasz rady ładnie zintegrować z resztą kodu. Lepszym wg mnie działaniem jest napisanie tego jakkolwiek, późniejsza analiza co jest potrzebne i reorganizacja istniejącego kodu by było w miarę ładnie. Czynność powtórzyć paręnaście razy.
Pamiętaj, że piszesz na Amigę. Jeszcze bardziej ambitnie, bo z wykorzystaniem graphics.library i wszystkich bolączek z tym związanych zamiast wszystko samemu. Z mojego doświadczenia wynika, że na tej platformie coś wygląda na wykonywalne wtedy i tylko wtedy gdy przymyka się oko na któreś z ograniczeń sprzętu. Bo jak przyjdzie co do czego to zawsze coś przeszkadza, zawsze coś będzie upierdliwe, albo okaże się że liczby mówiące o wydajności pewnych rzeczy zakładają najmniej niekorzystny scenariusz (vide prędkość blittera i obliczenia czasu blitu, nie uwzględniające bitplane'ów ani coppera).
Grę którą na nowożytnej platformie napisałbym w miesiąc (openFire) tutaj pisze się ponad rok, oczywiście spędzając na tym caluteńki wolny czas. Proxy swoje Impsbru, które spokojnie napisałby w tydzień, pisał w miesiąc. Villages było projektem na dwa miesiące i po dwóch latach męki nigdy nie zostało skończone. Na ile czasu szacujesz pisanie swojej gry pomijając złośliwości/złożoności architektury Amigowej?
Wiele rzeczy będziesz robił po raz pierwszy. Wspomniane AI. Czas rzeczywisty. Różne tryby interakcji (tryb budowania, tryb sterowania jednostkami). Tutaj wiele rzeczy może Cię zaskoczyć i spowodować, że jednej rzeczy której nie przewidziałeś nie dasz rady ładnie zintegrować z resztą kodu. Lepszym wg mnie działaniem jest napisanie tego jakkolwiek, późniejsza analiza co jest potrzebne i reorganizacja istniejącego kodu by było w miarę ładnie. Czynność powtórzyć paręnaście razy.
Pamiętaj, że piszesz na Amigę. Jeszcze bardziej ambitnie, bo z wykorzystaniem graphics.library i wszystkich bolączek z tym związanych zamiast wszystko samemu. Z mojego doświadczenia wynika, że na tej platformie coś wygląda na wykonywalne wtedy i tylko wtedy gdy przymyka się oko na któreś z ograniczeń sprzętu. Bo jak przyjdzie co do czego to zawsze coś przeszkadza, zawsze coś będzie upierdliwe, albo okaże się że liczby mówiące o wydajności pewnych rzeczy zakładają najmniej niekorzystny scenariusz (vide prędkość blittera i obliczenia czasu blitu, nie uwzględniające bitplane'ów ani coppera).
Grę którą na nowożytnej platformie napisałbym w miesiąc (openFire) tutaj pisze się ponad rok, oczywiście spędzając na tym caluteńki wolny czas. Proxy swoje Impsbru, które spokojnie napisałby w tydzień, pisał w miesiąc. Villages było projektem na dwa miesiące i po dwóch latach męki nigdy nie zostało skończone. Na ile czasu szacujesz pisanie swojej gry pomijając złośliwości/złożoności architektury Amigowej?
14.11.2017 09:44
[#402]
Re: Zapowiedzi nowych gier
@teh_KaiN, post #401
No ale te ograniczenia w pewnym stopniu nakłada koder sobie sam, wybierając docelowy konfig na którym program/gra ma działać. Ale faktem jest że bez dobrej znajomości architektury Amigi to może być chyba ciężko się połapać co będzie OK a co już nieco ponad miarę załozonego docelowego konfigu.
A co do nowożytnych platform (oraz w mniejszym stopniu mocnych amigowych konfigów) to jest zupełnie inny świat. Tam jeśli chodzi o "proste" 2D to i tak wszystko można zrobić prockiem mając (prawie) całokowitą kontrolę.
A co do nowożytnych platform (oraz w mniejszym stopniu mocnych amigowych konfigów) to jest zupełnie inny świat. Tam jeśli chodzi o "proste" 2D to i tak wszystko można zrobić prockiem mając (prawie) całokowitą kontrolę.
14.11.2017 12:18
[#403]
Re: Zapowiedzi nowych gier
@teh_KaiN, post #401
Modularność w pełnym tego słowa znaczeniu sprawdza się tylko i wyłącznie na platformach nowożytnych gdzie masz zapas mocy przerobowej pozwalający na abstrakcję.
Pierwsza interpretacja: Przez abstrakcję rozumiem zamknięcie pewnych rzeczy w czarnych skrzynkach - funkcje/metody/struktury/klasy.
Te rzeczy są przydatne, bo upraszczają nam pracę. Tworzymy funkcje i struktury dla wygody.
Nie musi się to koniecznie przekładać na programowanie obiektowe, chociaż może.
Jasne jest, że robienie metod typu get() i set() z jedną instrukcją w postaci osobnych procedur jest kosztowne i to należy realizować tylko w postaci kodu in-line (chociażby poprzez makra).
Pamiętaj jednak, że często tak bywa, że optymalizacje chowamy wewnątrz tych skrzynek. Procedura DrawTurret() ma nam narysować wieżyczkę, ale jak to zrobi - nas nie interesuje. Może zrealizować to za pomocą wspomagania sprzętowego.
Jeżeli znasz system Amigi to pewnie wiesz, że rysowanie w bibliotekach graficznych jest zoptymalizowane poprzez szereg mechanizmów i funkcji. Można z tego brać przykład przy pisaniu własnych procedur.
1. Przykładowo jak do portu okienka dostarczona zostanie wiadomość o konieczności odświeżenia części okienka, my możemy zamknąć operacje rysowania pomiędzy klauzulę BeginRefresh()/EndRefresh(), dzięki czemu operacje będą dotyczyć tylko obszaru zmodyfikowanego.
2. Istnieją funkcje SetWriteMask() oraz SetMaxPen(), które redukują koszt rysowania, ustalając które bitplany mają być modyfikowane oraz jaki jest maksymalny kolor który chcemy rysować w dany RastPort.
Piszę o tym po to, by zobrazować że warstwy abstrakcji czasami mają efekt odwrotny - optymalizują (przyśpieszają), a nie spowalniają algorytmy.
Jeżeli nie jesteś zdecydowany czy robić wieżyczki za pomocą Sprite'ów czy BOBów to zrób inną implementację, ale interfejs (protokół) zrób jednolity.
--
Druga interpretacja: Można rozumieć to też w ten sposób, że na Amidze trzeba koniecznie pisać pod Coppera i Blittera bezpośrednio, bez warstw pośredniczących.
OK, systemowe funkcje rysujące można jak najbardziej zastąpić własnymi, szybkimi funkcjami. Ale pamiętaj że i tak tworzymy wówczas własną warstwę abstrakcji ze wszystkimi jej zaletami i wadami.
Najlepiej tak zaimplementować funkcje, by zużywały jak najmniej zasobów typu czas procesora, a najwięcej ze wspomagania sprzętowego, typu płynny przesuw czy DMA.
Poza tym warto określić już na początku jakiej szybkości animacji potrzebujemy. 25/30Hz najpewniej starczy nam na wszystko.
Wiele rzeczy będziesz robił po raz pierwszy. Wspomniane AI. Czas rzeczywisty. Różne tryby interakcji (tryb budowania, tryb sterowania jednostkami). Tutaj wiele rzeczy może Cię zaskoczyć i spowodować, że jednej rzeczy której nie przewidziałeś nie dasz rady ładnie zintegrować z resztą kodu.
Ja bardzo lubię reorganizowanie kodu, i praktykuję to. Na pewno podczas pracy pojawią się różne niespodzianki. Jednakże wg mnie nie warto pisać kodu "byle jak, byle działało".
Tak jak wspominałem, obliczam koszty algorytmów. To oznacza, że jestem w stanie określić ile mam dostępnych zasobów w danej części programu. Na animację ekranu zostanie przeznaczone sporo czasu Blittera oraz Copper, ale akurat Amiga sprawdza się w animacji z mojego doświadczenia całkiem dobrze.
Pamiętaj, że piszesz na Amigę. Jeszcze bardziej ambitnie, bo z wykorzystaniem graphics.library i wszystkich bolączek z tym związanych zamiast wszystko samemu.
Jeżeli zastosuję wspomniane przeze mnie wyżej metody optymalizacyjne oraz będę obliczać koszt czasowy i pamięciowy, to wówczas dam radę zmieścić się w ramce.
Na pewno do mojego kodu w C dołączę kilka procedur w asemblerze, bo wtedy zmieszczenie się w ramce stanie się dużo łatwiejsze.
W każdym razie w moich projektach z reguły ograniczenia sprzętowe nigdy nie stawały mi na drodze. Recepta jest dość prosta - robić sobie zapas i jednak oszczędzać.
Na ile czasu szacujesz pisanie swojej gry pomijając złośliwości/złożoności architektury Amigowej?
Piszę to w wolnym czasie (głównie wieczorami) więc na razie nie chcę określać konkretnego terminu zakończenia pracy. Ale będę to robił etapami, a pierwszy etap prac myślę, że do gwiazdki uda się zrobić.
Pierwszy etap to będzie realizacja w postaci kodu następujących rzeczy:
- Planszy,
- Budynków (ich struktura i praca),
- Jednostek (ich struktura i czynności),
- Rodów,
- Efektów/animacji,
- Statystyk.
Ostatnia aktualizacja: 14.11.2017 12:34:15 przez Hexmage960
29.11.2017 19:36
[#408]
Re: Zapowiedzi nowych gier
@nogorg, post #407
Zapowiada się bardzo ciekawie, choć przyznam że angielski mówiony nie jest moją najmocniejszą stroną. Obejrzę ten film w całości. Dziękuję za jego zamieszczenie. Warto brać przykład od kogoś kto zna się na rzeczy i potrafi robić to, co robi.
Widzę, że pan z filmu ma fajny warsztat pracy, w tym parę syntezatorów.
Ja też mam całkiem sporo doświadczenia, bo rozpracowałem kilka gier na Amigę, poznając ich wewnętrzną budowę (głównie formaty, ale czasem również działanie): Benefactor, Dune 2, Gloom, Boulder Daesh.
Dzięki temu wiem jak takie gry działają i jak je konstruować. Jestem jednak też osobą kreatywną i potrafię wnieść sporo własnej inwencji.
Obecnie robię edytor map i parametrów do mojej gry.
Ostatni zrzut ekranu działającego programu wygląda tak:
Edytor zamieszczę dopiero jak będzie ukończony. Choć i tak, to jest tylko etap pracy. Czeka mnie zakodowanie samego silnika.
Także mówiąc jednym słowem - zamieszczę grę jak będzie gotowa. When it's done. Mam nadzieję, że będzie mi to iść teraz prędzej bo zdrowie dopisuje.
Widzę, że pan z filmu ma fajny warsztat pracy, w tym parę syntezatorów.
Ja też mam całkiem sporo doświadczenia, bo rozpracowałem kilka gier na Amigę, poznając ich wewnętrzną budowę (głównie formaty, ale czasem również działanie): Benefactor, Dune 2, Gloom, Boulder Daesh.
Dzięki temu wiem jak takie gry działają i jak je konstruować. Jestem jednak też osobą kreatywną i potrafię wnieść sporo własnej inwencji.
Obecnie robię edytor map i parametrów do mojej gry.
Ostatni zrzut ekranu działającego programu wygląda tak:
Edytor zamieszczę dopiero jak będzie ukończony. Choć i tak, to jest tylko etap pracy. Czeka mnie zakodowanie samego silnika.
Także mówiąc jednym słowem - zamieszczę grę jak będzie gotowa. When it's done. Mam nadzieję, że będzie mi to iść teraz prędzej bo zdrowie dopisuje.
29.11.2017 19:47
[#409]
Re: Zapowiedzi nowych gier
@Hexmage960, post #408
Hex, gość jest tak zajebisty że dał też napisy :)
W ogóle to jest człowiek orkiestra. Rysuje, komponuje i koduje. Jakby miał zderzaki, inny układ podwozia i bardziej odpicowaną maskę to bym się ożenił :)
A te ramki z kafelków to może zdejmij. Fajnie że się przy planowaniu odróżnia ale to masz część kafelka więc w rzeczywistości tego tam być nie może. No chyba że tak planujesz wygląd mapy. Może opcja grid on/off w samym edytorze? albo w grze nawet?
wrzuciłbyś coś znowu :)
W ogóle to jest człowiek orkiestra. Rysuje, komponuje i koduje. Jakby miał zderzaki, inny układ podwozia i bardziej odpicowaną maskę to bym się ożenił :)
A te ramki z kafelków to może zdejmij. Fajnie że się przy planowaniu odróżnia ale to masz część kafelka więc w rzeczywistości tego tam być nie może. No chyba że tak planujesz wygląd mapy. Może opcja grid on/off w samym edytorze? albo w grze nawet?
wrzuciłbyś coś znowu :)
29.11.2017 21:26
[#411]
Re: Zapowiedzi nowych gier
@Hexmage960, post #410
Pracowałem dzisiaj przy edytorze i jest wszystko z kodem OK, ale mam pewną zagwozdkę co do grafiki. Otóż na razie mam tylko te kafelki skały i piasku (skała wygląda bardzo ładnie), ale ale - w grze będzie potrzebna tona innej grafiki.
Zastanawiam się nad jedną z opcji, czy:
Chciałbym namalować własny szkic, ale nie chcę by traciło na tym tempo rozwoju kodu. Zatem może pozostałe dwie opcje.
Docelowo chciałbym zrobić zupełnie własną grafikę (ale wersja z PC-tową grafiką też jest kusząca).
Wymyśliłem dzisiaj nazwę swojej (naszej?) gry - Dune 2: Fan Enhancement Edition. Tak żeby nie było konfliktu z właścicielami praw do Dune 2. Takich fanowskich rozszerzeń jest w sieci bardzo dużo i są legalne.
Ostatnia aktualizacja: 29.11.2017 21:27:54 przez Hexmage960
Zastanawiam się nad jedną z opcji, czy:
- użyć kolorowych prostokątów, czyli zamienników,
- użyć 256-kolorowej grafiki z Dune 2: Building of a Dynasty z PC-ta.
- namalować wstępną własną grafikę - szkic (ew. później poprosić o pomoc grafika),
Chciałbym namalować własny szkic, ale nie chcę by traciło na tym tempo rozwoju kodu. Zatem może pozostałe dwie opcje.
Docelowo chciałbym zrobić zupełnie własną grafikę (ale wersja z PC-tową grafiką też jest kusząca).
Wymyśliłem dzisiaj nazwę swojej (naszej?) gry - Dune 2: Fan Enhancement Edition. Tak żeby nie było konfliktu z właścicielami praw do Dune 2. Takich fanowskich rozszerzeń jest w sieci bardzo dużo i są legalne.
Ostatnia aktualizacja: 29.11.2017 21:27:54 przez Hexmage960
29.11.2017 21:36
[#412]
Re: Zapowiedzi nowych gier
@Hexmage960, post #411
A napisz co potrzebujesz.
Jesli do testow na szybko to mozesz zapelnic czymkolwiek dostepne sloty.
Jesli juz to Fan Enhanced Edition. Wychodzi mnie ze Selur jest naszym babokiem ktorym babki strasza malych amigowcow... Nie chce Cie nim straszyc ale wiesz jaki Twoja wersja bedzie miala skrot?
;)
D2:FEE
Jesli do testow na szybko to mozesz zapelnic czymkolwiek dostepne sloty.
Jesli juz to Fan Enhanced Edition. Wychodzi mnie ze Selur jest naszym babokiem ktorym babki strasza malych amigowcow... Nie chce Cie nim straszyc ale wiesz jaki Twoja wersja bedzie miala skrot?
;)
D2:FEE
29.11.2017 21:46
[#413]
Re: Zapowiedzi nowych gier
@softiron, post #412
Potrzebuję na początek budynków. Teren z grubsza jest. Przydałoby się narysować (lub pobrać z Dune 2 z PC-ta) wygląd podstawowych budynków. Jakie to budowle? Standardowe, czyli plac budowy, elektrownia, rafineria itp.
Tak na marginesie to chciałbym by Harkonnenowie budowali nieco inaczej niż Atrydzi. Harkonnenowie będą wznosili budynki tylko w tzw. strefie industrialnej. Zaś Atrydzi za pomocą pojazdów MCV. To taka koncepcja, którą wymyśliłem wcześniej.
Tak na marginesie to chciałbym by Harkonnenowie budowali nieco inaczej niż Atrydzi. Harkonnenowie będą wznosili budynki tylko w tzw. strefie industrialnej.
Zaś Atrydzi za pomocą pojazdów MCV. To taka koncepcja, którą wymyśliłem wcześniej. 29.11.2017 22:12
[#414]
Re: Zapowiedzi nowych gier
@Hexmage960, post #413
Myślę sobie, że jak zamierzasz grę skończyć to na razie możesz użyć nawet czarnych kafelków z napisami "skała", "piasek", "strefa industrialna". Jak logika gry będzie gotowa to pomyślisz o docelowej grafice. Żeby potem nie było żalów od artysty, który się napracował bez sensu, bo zmieniła się na ten przykład koncepcja wszystkiego.
29.11.2017 22:12
[#415]
Re: Zapowiedzi nowych gier
@Hexmage960, post #413
Panie Robercie.
Prosze i blagam niech Pan nie pisze wiecej na tym forum.
Moze to Panu sprawia przyjemnosc ale normalnym amigowcom co czytają na co dzien to forum pewnie nie.
Wg mnie pisze Pan o czyms o czym nie na Pan zielonego pojecia. Zakladam ze nigdy Pan nie skonczy tej gry czy czegos tam o czym Pan ciagle pisze.
Moze jak Pana to przerasta to niech Pan skonczy najpierw swoja strone czy bloga i na tym poprzestanie.
Ja sie nie znam, moze juz sie starzeje, jestem h..... jak ktos mnie ostatnio nazwał ze swiata amigowego i kompletnie zielony z programowania ale czytac ze zrozumieniem jeszcze potrafie i wnioski wyciągam.
Jeszcze pare postow i bedzie Pan pierwszym userem ktorego dodam do ignorowanych.
Ostatnia aktualizacja: 29.11.2017 22:14:32 przez JacK_Swidnik
Prosze i blagam niech Pan nie pisze wiecej na tym forum.
Moze to Panu sprawia przyjemnosc ale normalnym amigowcom co czytają na co dzien to forum pewnie nie.
Wg mnie pisze Pan o czyms o czym nie na Pan zielonego pojecia. Zakladam ze nigdy Pan nie skonczy tej gry czy czegos tam o czym Pan ciagle pisze.
Moze jak Pana to przerasta to niech Pan skonczy najpierw swoja strone czy bloga i na tym poprzestanie.
Ja sie nie znam, moze juz sie starzeje, jestem h..... jak ktos mnie ostatnio nazwał ze swiata amigowego i kompletnie zielony z programowania ale czytac ze zrozumieniem jeszcze potrafie i wnioski wyciągam.
Jeszcze pare postow i bedzie Pan pierwszym userem ktorego dodam do ignorowanych.
Ostatnia aktualizacja: 29.11.2017 22:14:32 przez JacK_Swidnik
29.11.2017 22:51
[#417]
Re: Zapowiedzi nowych gier
@JacK_Swidnik, post #415
Nie napisał kiedy chce skończyć
Do emerytury może się doczekam, a jako fan Franka Herberta
dam kredyt zaufania.
ps. jak byłem w jego wieku też chciałem być bohaterem
pps. tylko po co wciągać na tym etapie poważnych grafików ??
Daj cień szansy na ukończenie to sami się odezwą - coś ala koyot przy grze "Blask"
Do emerytury może się doczekam, a jako fan Franka Herberta
dam kredyt zaufania.
ps. jak byłem w jego wieku też chciałem być bohaterem
pps. tylko po co wciągać na tym etapie poważnych grafików ??
Daj cień szansy na ukończenie to sami się odezwą - coś ala koyot przy grze "Blask"
29.11.2017 23:02
[#419]
Re: Zapowiedzi nowych gier
@JacK_Swidnik, post #415
Przydalo by Ci sie troche empatii. Rozumiem cos delikatnie doradzic, tudziez lekko skrytykowac, ale proszenie by sie juz nigdy nie odzywac na forum jest slabe. Na szczescie Robert chamem nie jest wiec na pewno Ci nie pocisnie wiazanki jak by to zrobilo 99% ludzi tutaj.
Ja nie cierpie na zadna chorobe psychiczna, a programowac nie umiem, wiec podziwiam go za to co potrafi mimo swojej strasznej choroby. Nie jeden moglby sie od niego uczyc. I nie wiem czy jestem "normalnym amigowcem", ale nie przeszkadzaja mi w ogole jego kulturalne posty
Ja nie cierpie na zadna chorobe psychiczna, a programowac nie umiem, wiec podziwiam go za to co potrafi mimo swojej strasznej choroby. Nie jeden moglby sie od niego uczyc. I nie wiem czy jestem "normalnym amigowcem", ale nie przeszkadzaja mi w ogole jego kulturalne posty
29.11.2017 23:03
[#420]
Re: Zapowiedzi nowych gier
@JacK_Swidnik, post #415
Wg mnie pisze Pan o czyms o czym nie na Pan zielonego pojecia.
To zapytam się co Pan ma na myśli to pisząc?
Jeszcze pare postow i bedzie Pan pierwszym userem ktorego dodam do ignorowanych.
Proszę się nie martwić. Większość aktywności spędzam wśród artystów i programistów na forum prywatnym.
Prosze i blagam niech Pan nie pisze wiecej na tym forum.
Chodzi Panu o całe to forum PPA? Jeszcze nie słyszałem, żeby zabierali użytkownikom prawo uczestniczenia w forum prócz tzw. bana. Ale taki dostaje się za złamanie regulaminu.
Ja uważam, że należę do grona bardziej kulturalnych osób na tym forum.