01.12.2022 01:03
[#61]
Re: automaty skończone
@teh_KaiN, post #59
Zdefiniuj profesjonalne.
Profesjonalne to takie co sa profesjonalne a takie co nie sa sa dla jajec. Najlepiej oceniac recami, uszami i oczami.
Vergeworld z niego korzystano i git, ocenimy efekt koncowy jak juz wyjdzie.
Ta Chaos Arena której prawie nikt z ppa nie ściągnął a na pewno nikt nie kupił jest póki co naszą najlepiej sprzedającą się grą
No i co ja za to moge... jak gre se napiszecie tak bedziecie pozniej ja mieli (nie wiem jak inni... ale ja przynajmniej obejrzalem video na jutubie i tyle mi starczylo)
powstaje również (w bólach trzymania się konfiguracji 7MHz 512+512) port warcrafta 1
Mnie sie ogolnie porty na Amige zle kojarza ale moze cos z tego porta bedzie, bo WC 1 to swietna gierka, a kto to w ogole robi i gdzie ?
moonstone'a w ACE bez problemu byś ulepił tu i teraz
No to rewelacja ! tylko ktos to jeszcze musi napisac... no dalej majstry do boju, ktory tu ogarnia C ?!
01.12.2022 11:01
[#64]
Re: automaty skończone
@teh_KaiN, post #59
(...) oraz trzymać się w miarę bliskiej daty premiery żeby projekt się nie przerósł
Z ciekawości się spytam ile taki projekt trwa ? (roboczo godzin oczywiście).
Nie wiem czy dobrze zrozumiałem, ale chyba dochodzimy do wniosku, że nie jest ważny język w którym piszemy demo/grę a ważne jest by napisać i skończyć projekt. I chyba tego najbardziej brakuje. Skończonych projektów, nieważne czy mniej udanych czy bardziej. Bo gadanie jest tanie i i jak uczy historia nic z tego nie wynika.
Ostatnia aktualizacja: 01.12.2022 11:01:47 przez asman
01.12.2022 11:19
[#65]
Re: automaty skończone
@selur, post #15
To tylko Mit !
Wpisywanie poke'ow do gier, nie mialo nic wspolnego z nauka assemblera. Np. wsrod moich znajomych z kilkudziesieciu osob zaden nie zaczynal od assemblera, ba assembler to byla czarna magia.
Nie wiem jak w świecie C64, ale w gazecie Tajemnice Atari był kurs Assemblera (między innymi cykl "Piszemy DEMO"), była też książki Wojciecha Zientary opisująca całą mapę pamięci Atarynki.
Do tego w sprzedaży był Quick Assembler z polską instrukcją.
Czyli dla Ciebie Mit, bo może na C64 tak to wyglądało, ale to nie znaczy że wszędzie :)
01.12.2022 12:11
[wyróżniony]
[#66]
Re: automaty skończone
@asman, post #64
to zależy od zakresu projektu.
- OpenFire powstawał w 2017 i dalej nie został skończony bo został odłożony na półkę bo trzeba było robić prodkę na RK. Zakres był znany, wizja krystalicznie czysta, po prostu projekt zbyt ambitny. Mnóstwo techa musiało powstać na potrzeby tej gry, mniej więcej już wszystko mamy ogarnięte więc kiedyś wrócimy i to myślę w miarę szybko skończymy.
- tą prodką na RK18 był Aminer, development dalej trwa. Dużo czasu zajęło nam znalezienie tej gry i wymyślenie czym ma być a czym nie - mechanicznie i fabularnie, i to nam przedłużyło produkcję, no i trzeba było dopisać obsługę audio, zdebugować scrollingtrick i parę innych technicznych problemów. Ale nie tylko.
- w 2019 ktoś wpadł na genialny pomysł "zróbmy szybką prodkę na game compo na Revision" gdzie został nam miesiąc czasu do compo - tak powstały GermZy. A właściwie powstawały 1.5 roku. Mieliśmy trochę problemów co do mechanik, też trochę tam błądziliśmy, ale się udało. Pomogło to, że większość techu już mieliśmy, ale nie wszystko - mogliśmy puścić tę grę mniej doszlifowaną ale bez muzyki i z gliczującym audio. Wstrzymaliśmy się, gra mocno czekała na to aż w końcu ogarnę audio (przepisałem na C ptplayera od Phxa i przerobiłem pod ACE'owe zarządzanie OSem), po drodze podszlifowaliśmy gfxy, zmieniliśmy sterowanie na chyba najlepsze możliwe (ale wciąż toporne) i rozsądnie dopracowaliśmy powerupy. No właśnie, po drodze był scope creep bo doszło nam dodawanie wbudowanego edytora map, powerupy, kampania z intrem i outrem. Tak czy inaczej szlus, i zdejmujemy ze stosu zaczętych produkcji wracając do Aminera
- Chaos arena powstawała w 1.5 tygodnia przed dekranczem - żeby nie powtórzyć problemu germzów to wziąłem najprostszy z pomysłów na przyszłe gry jaki spisaliśmy (mamy ich około 20 mniej lub bardziej rozplanowanych), zweryfikowałem czy mam wszystko co technicznie niezbędne do napisania gry i w pierwszym kroku sprawdziłem ile jestem w stanie wyświetlić bobów na jednym ekranie. Liczba była zadowalająca a reszta to już historia. Reszta teamu dostała info że gra w ogóle powstaje w połowie czasu, więc na szybko powstało jakieś audio, mniej placeholderowe grafiki (na compo rycerzyki były jeszcze cudze wzięte z neta). Potem po premierze małe tweaki gry, dodanie jednej mechaniki na którą nie starczyło czasu na compo, finalna grafika i sfx - całość zamknęła się w miesiącu.
Jeśli pytasz o zawodowy projekt to powstaje za długo - coś koło 4-5 lat w teamie ~30 osób, dołączyłem do niego w tym roku. Moja myśl była taka że podszpieguję profesjonalistów jak zarządzają produkcją żeby się po drodze nie wywalić, niestety okazało się że dostałem kontrprzykład.
Moje złote rady jak skończyć grę:
- wiedzieć co chce się zrobić
- robić absolutne minimum, więcej dorzucić w sequelu/dodatku
- robić tylko to co się umie zrobić / ma się tech, jak się nie ma to zawrzeć maksymalnie jedną dużą rzecz której się nie ma (jakieś super audio, albo scroll, albo efekt bez którego gra nie działa)
- jak się ma doświadczenie z pisaniem nowożytnym, to planować projekt tak że to co zrobiłbyś na pececie w dzień zrobisz na Amidze w miesiąc (jak jesteś doświadczony to przelicznik 1 dzień = 1 tydzień)
- zweryfikować szybko czy Amiga to udźwignie i czy gra mechanicznie ma sens - czy fajnie się gra
- w prywatnych kanałach dyskusji wewnątrz LMC mamy ciągle widoczną inskrypcję "j***ć wersje demo" - zrobisz wersję preview na compo a potem nie będzie motywacji żeby skończyć final. Lepiej robić coś po cichu i jak już będzie gotowe to przy okazji wrzucić na compo.
Ostatnia aktualizacja: 01.12.2022 12:23:46 przez teh_KaiN
- OpenFire powstawał w 2017 i dalej nie został skończony bo został odłożony na półkę bo trzeba było robić prodkę na RK. Zakres był znany, wizja krystalicznie czysta, po prostu projekt zbyt ambitny. Mnóstwo techa musiało powstać na potrzeby tej gry, mniej więcej już wszystko mamy ogarnięte więc kiedyś wrócimy i to myślę w miarę szybko skończymy.
- tą prodką na RK18 był Aminer, development dalej trwa. Dużo czasu zajęło nam znalezienie tej gry i wymyślenie czym ma być a czym nie - mechanicznie i fabularnie, i to nam przedłużyło produkcję, no i trzeba było dopisać obsługę audio, zdebugować scrollingtrick i parę innych technicznych problemów. Ale nie tylko.
- w 2019 ktoś wpadł na genialny pomysł "zróbmy szybką prodkę na game compo na Revision" gdzie został nam miesiąc czasu do compo - tak powstały GermZy. A właściwie powstawały 1.5 roku. Mieliśmy trochę problemów co do mechanik, też trochę tam błądziliśmy, ale się udało. Pomogło to, że większość techu już mieliśmy, ale nie wszystko - mogliśmy puścić tę grę mniej doszlifowaną ale bez muzyki i z gliczującym audio. Wstrzymaliśmy się, gra mocno czekała na to aż w końcu ogarnę audio (przepisałem na C ptplayera od Phxa i przerobiłem pod ACE'owe zarządzanie OSem), po drodze podszlifowaliśmy gfxy, zmieniliśmy sterowanie na chyba najlepsze możliwe (ale wciąż toporne) i rozsądnie dopracowaliśmy powerupy. No właśnie, po drodze był scope creep bo doszło nam dodawanie wbudowanego edytora map, powerupy, kampania z intrem i outrem. Tak czy inaczej szlus, i zdejmujemy ze stosu zaczętych produkcji wracając do Aminera
- Chaos arena powstawała w 1.5 tygodnia przed dekranczem - żeby nie powtórzyć problemu germzów to wziąłem najprostszy z pomysłów na przyszłe gry jaki spisaliśmy (mamy ich około 20 mniej lub bardziej rozplanowanych), zweryfikowałem czy mam wszystko co technicznie niezbędne do napisania gry i w pierwszym kroku sprawdziłem ile jestem w stanie wyświetlić bobów na jednym ekranie. Liczba była zadowalająca a reszta to już historia. Reszta teamu dostała info że gra w ogóle powstaje w połowie czasu, więc na szybko powstało jakieś audio, mniej placeholderowe grafiki (na compo rycerzyki były jeszcze cudze wzięte z neta). Potem po premierze małe tweaki gry, dodanie jednej mechaniki na którą nie starczyło czasu na compo, finalna grafika i sfx - całość zamknęła się w miesiącu.
Jeśli pytasz o zawodowy projekt to powstaje za długo - coś koło 4-5 lat w teamie ~30 osób, dołączyłem do niego w tym roku. Moja myśl była taka że podszpieguję profesjonalistów jak zarządzają produkcją żeby się po drodze nie wywalić, niestety okazało się że dostałem kontrprzykład.
Moje złote rady jak skończyć grę:
- wiedzieć co chce się zrobić
- robić absolutne minimum, więcej dorzucić w sequelu/dodatku
- robić tylko to co się umie zrobić / ma się tech, jak się nie ma to zawrzeć maksymalnie jedną dużą rzecz której się nie ma (jakieś super audio, albo scroll, albo efekt bez którego gra nie działa)
- jak się ma doświadczenie z pisaniem nowożytnym, to planować projekt tak że to co zrobiłbyś na pececie w dzień zrobisz na Amidze w miesiąc (jak jesteś doświadczony to przelicznik 1 dzień = 1 tydzień)
- zweryfikować szybko czy Amiga to udźwignie i czy gra mechanicznie ma sens - czy fajnie się gra
- w prywatnych kanałach dyskusji wewnątrz LMC mamy ciągle widoczną inskrypcję "j***ć wersje demo" - zrobisz wersję preview na compo a potem nie będzie motywacji żeby skończyć final. Lepiej robić coś po cichu i jak już będzie gotowe to przy okazji wrzucić na compo.
Ostatnia aktualizacja: 01.12.2022 12:23:46 przez teh_KaiN
01.12.2022 21:26
[#68]
Re: automaty skończone
@karolb, post #65
W C&A i Kebabie były listingi gdzie się wpisywało w Basicu komendy kodu maszynowego. Do tego były kursy asemblera. W książce Bogdana Frelka Commodore 64 też był opis komend 6502 i kilka przykładów, mapa pamięci, reszty trzeba było się samemu nauczyć. Na rynku nie było chyba nic lepszego do asemblera, bo na początku lat '90 obszedłem wszystkie księgarnie, sklepy komputerowe w całej Częstochowie i nic nie było lepszego. Więc żadne mity. Na 8bit przeważnie dla nowicjuszy pierwsze co to było odpalenie Basica (bo był w romie) pobawienie się, natrafienie na ścianę z wydajnością i przesiadka na asembler. A w pierwszych "komputerach domowych" jak Altair albo Kim-1 było tylko wpisywanie z palca komend kodu maszynowego. Kompilatory i interpretery dokupowało się o ile były. Dzięki temu Microsoft się wybił, bo zrobił Basic na domowe komputery.
#66 Zgadzam się, że na Amigę zrobić coś, zabiera o wiele więcej czasu (razy kilka/kilkanaście) niż na PC, czy inną main stream platformę.
Ostatnia aktualizacja: 01.12.2022 21:40:51 przez flops
#66 Zgadzam się, że na Amigę zrobić coś, zabiera o wiele więcej czasu (razy kilka/kilkanaście) niż na PC, czy inną main stream platformę.
Ostatnia aktualizacja: 01.12.2022 21:40:51 przez flops
23.12.2022 20:43
[#69]
Re: automaty skończone
@pisklak, post #57
Wszyscy tu wieszają psy na "go to"... Ale czasami to jest po prostu najprostsze i najczytelniejsze wyjscie. Jeśli np. mamy serio sensownie zrobioną obsługę wyjścia w naszym programie, to bez wzgledu na to jakim jezykiem się posługujemy, to bezpośredni skok do tej procedury po prostu ma sens.
A możesz zapodać taki kawałek kodu który nie może się obejść bez goto?
Jestem bardzo ciekawy, bo bardzo dawno temu też mi się tak wydawało, że bez goto nie da się żyć.
23.12.2022 22:14
[#72]
Re: automaty skończone
@Rafael/ARMO, post #71
Teraz z telefonu nie podam... Ale prosty program.... Ze 200 linii kodu. Na koncu mam kod wyjsciowy gdzie po prostu sprawdzam wszystkie zaalokowane zasoby i jeśli są to je zwalniam. W trakcie dzialania programu jak wystąpi jakiś błąd to po prostu skaczę bezposrednio do tego kodu wyjściowego. Jedno goto (a w zasadzie JUMP bo to. AmigaE). Pewnie da się to zrobić lepiej... Ale o to bym kopii nie kruszył.
24.12.2022 18:21
[#74]
Re: automaty skończone
@Rafael/ARMO, post #71
Ja używam goto w tym samym przypadku jaki linuksowi kernelowcy: inicjalizując wieloetapowo jakiś zasób może parę różnych rzeczy pójść nie tak, każdorazowo robię goto fail. Tu masz przykład. W cpp można by to zastąpić RAII albo od biedy trykaczem, ale w C tego nie masz.
Ostatnia aktualizacja: 24.12.2022 18:23:19 przez teh_KaiN
Ostatnia aktualizacja: 24.12.2022 18:23:19 przez teh_KaiN
24.12.2022 22:27
[#75]
Re: automaty skończone
@teh_KaiN, post #74
W języku C jest odpowiednik klauzuli try/catch z C++.
Są to tzw. dalekie skoki i można wracać wiele poziomów wyżej za pomocą jednej instrukcji. Należy załączyć plik nagłówkowy <setjmp.h> i zadeklarować zmienną typu jmp_buf.
Następnie konstrukcja setjmp(jmp_buf) ustawi miejsce skoku i zwróci wartość 0, zaś instrukcja longjmp(jmp_buf, int) skoczy do miejsca wskazywanego przez setjmp(), tyle że zwróci podaną wartość różną od zera.
Uwaga: Zmienne lokalne muszą być volatile, żeby być widoczne po dalekim skoku.
Prawdę powiedziawszy to taki styl nie pasuje mi, choć jest z powodzeniem wykorzystywany ale głównie w starszym, choć znakomitym kodzie z późnych lat 80.
Jak masz rozpisany flow programu, to setjmp() może sprawować się wyśmienicie.
Są to tzw. dalekie skoki i można wracać wiele poziomów wyżej za pomocą jednej instrukcji. Należy załączyć plik nagłówkowy <setjmp.h> i zadeklarować zmienną typu jmp_buf.
Następnie konstrukcja setjmp(jmp_buf) ustawi miejsce skoku i zwróci wartość 0, zaś instrukcja longjmp(jmp_buf, int) skoczy do miejsca wskazywanego przez setjmp(), tyle że zwróci podaną wartość różną od zera.
jmp_buf buf;
volatile int result;
if ((result = setjmp(buf)) == 0)
{
/* Wykonywane na początku */
}
else
{
/* Wykonywane po skoku */
}Uwaga: Zmienne lokalne muszą być volatile, żeby być widoczne po dalekim skoku.
Prawdę powiedziawszy to taki styl nie pasuje mi, choć jest z powodzeniem wykorzystywany ale głównie w starszym, choć znakomitym kodzie z późnych lat 80.
Jak masz rozpisany flow programu, to setjmp() może sprawować się wyśmienicie.