[#31] Re: GameX - pomysł na zwiększenie produkcji gier

@Klub Amigi RNS, post #21

Napiszę z punktu użytkownika, bo takim jestem, żaden ze mnie programista. Ale sama idea jest dobra. Każda inicjatywa jest dobra jeśli znajdzie koniec-skuteczny. Bo narobić się można, a później się okaże że na darmo, bo nikt nie skorzysta.

Wg. mnie jest to przyszłościowa sprawa z tymi grami. Prostsze gry wracają do łask. Wielu ludzi wraca do klasyków żeby odpalać WHDLoad, ale większość z całej gamy tego amigowego pakietu to chłam aż szkoda odpalać.

Fajnie by było jakby się pokazywało coś nowego. Podam przykład jak na tym można zarabiać. Ostatnio zalegalizowałem sobie gierkę WARBLADE, od Vidgala..nawet zassałem przy okazji amigową ostatnią wersję Galagi. Gra kosztowała 5 dolców, czyli coś około 3.7 funta. W Polsce powinna kosztować 5 zł. I szybko PalPayem poszło.
Jakby pokazywały się na Amigę podobnie gierki za podobną cenę myślę że by szły jak woda. Stworzyć odpowiednią stronę i działać i zarabiać.. OK

Tylko jedno mi chodzi po głowie, żeby pogodzić wszystkich, klasyki, PPC, karty grafiki itp... żeby każdy sprzęt był odpowiednio zaspokojony...

[#32] Re: GameX - pomysł na zwiększenie produkcji gier

@snajper, post #11

Panowie! Nie zabijajcie marzeń! :)


Klub Amigi RNS: Stary, rób swoje, idź pod prąd, udowodnij wszystkim... najlepiej pokaż jakiegoś wstępnie działającego gotowca.

Dyskutowanie o tym jakież to będzie wspaniałe projektu nie posunie do przodu - będzie wstępne demo - to będzie o czym pogadać.

Z partyjnym pozdrowieniem,
Sachozol



Ostatnia modyfikacja: 05.10.2011 22:36:36
[#33] Re: GameX - pomysł na zwiększenie produkcji gier

@sachy, post #32

Lepi niech imć Klub cos wreszcie skonczy.

[#34] Re: GameX - pomysł na zwiększenie produkcji gier

@Klub Amigi RNS, post #29

Wiem, że kolega MDW pisał gry na Amigę klasyczną, teraz zajmuje się nowoczesnymi platformami, ale chyba rozumie scenę retro. Głównie z myślą o niej ma być ten pakiet.

Aaa, jeżeli tylko retro to ja się nie wtrącam. :) Przestało mnie kręcić 2D w 2000 roku.

A tak nawiasem mówiąc to obracając się na forach gdzie ludzie piszą gry na dzisiejsze platformy pisząc o najbardziej wypasionej nowej maszynie dla AmigaOS4/MorphOS jestem traktowany jak maksymalne retro. Nawet wśród developerów iPhone4/iPad2 jestem użytkownikiem retro maszyny z retro możliwościami. :)

[#35] Re: GameX - pomysł na zwiększenie produkcji gier

@sachy, post #32

z cyklu czarny humor...

[wycięto niewybredny żart]

;)
[#36] Re: GameX - pomysł na zwiększenie produkcji gier

@Klub Amigi RNS, post #1

Pomysł wydaje się dobry, ale nawet taki pakiet trzeba umieć wykorzystać, dlatego uważam, że lepiej byś zrobił gdybyś przygotował cykl wideo tutoriali na temat jak zrobić grę np. w BlitzBasicu, AmigaE, Amosie czy w czym tam programujesz na klasyku. Do tego stworzyć bibliotekę postaci, dźwięków, które można wykorzystać w grze i masz ten sam efekt, ale mniejszym nakładem pracy (moim zdaniem). OK


No ja czekam na taki kurs (C++/C) dla Morphos-a.
[#37] Re: GameX - pomysł na zwiększenie produkcji gier

@Ender, post #36

ender
a co z twoim projektem...?
dość długo śledziłem twój wątek i widzę że chwilowo cisza?

[#38] Re: GameX - pomysł na zwiększenie produkcji gier

@carrion, post #37

Za radą kolegów odstawiłem przygodówkę, bo to trudniejsze zadanie i aktualnie kombinuję z prostą platformówką. Mam fajne książki, ale żeby móc je efektywnie wykorzystać, nie mogę robić takich przerw w nauce programowania, a dwójka małych dzieci i inne obowiązki jednak na taka ciągłość nie pozwalają. Nawet ostatnio do ArtEffecta nie zajrzałem, a wygląda naprawdę dobrze jak na moje potrzeby. Oj wszedłeś mi na ambicję ;) OK
[#39] Re: GameX - pomysł na zwiększenie produkcji gier

@Ender, post #38

Ok.ok wiem co to znaczy dzieci... Tez mam dwójke.
Co do platformowki...
To sa na amidze jakies gotowe edytory do robienia map z klockow w takich platformowkach? Bo że zrobisz to na klockach (powiedzmy 32x32pix) to chyba pewne? ;)
Ogólne pytanie poei no być czy sa tego typu narzedzia do projektowania ekranów do gier. Czy opisywany w tym wątku engine przewiduje ekrany/mapy budowane z kłocków 2d/3d?

[#40] Re: GameX - pomysł na zwiększenie produkcji gier

@carrion, post #39

Może to zabrzmi głupio, ale chciałbym zaprogramować to w C++, a nie korzystać z gotowców (BackBone czy jakoś tak). Te z amigi klasycznej niekoniecznie "zagadają" z nowszymi systemami, a nowszych pakietów nie ma. Zdobytą wiedzę, chcę wykorzystać w bardziej ambitnych projektach. Tak czy inaczej historia/fabuła gry platformówki wydaje się ciekawa. Teraz trzeba ciekawy system rozgrywki zrobić.



Ostatnia modyfikacja: 07.10.2011 22:04:46
[#41] Re: GameX - pomysł na zwiększenie produkcji gier

@MDW, post #26

Nie wyobrażam sobie większej produkcji, która byłaby równie atrakcyjna na A500, 7MHz 1MB RAM i nowych Amigach z normalną kartą graficzną i procesorem min. 1GHz.

Zanim taka gra powstanie, to wczesniej czlowiek stanie bosa noga na Jowiszu ..ale w koncu trzeba miec na cos nadzieje, na Marsa polecimy juz za kilka lat na pewno a stamtad juz tylko zabi skok na Jowisza.



Ostatnia modyfikacja: 07.10.2011 22:13:45
[#42] Re: GameX - pomysł na zwiększenie produkcji gier

@selur, post #41

Zanim taka gra powstanie, to
wczesniej czlowiek stanie bosa noga
na Jowiszu ..


No to to akurat dosyć trudne będzie...
siedzi, pije i chrupki

[#43] Re: GameX - pomysł na zwiększenie produkcji gier

@carrion, post #39

Czy opisywany w tym wątku engine przewiduje ekrany/mapy budowane z kłocków 2d/3d?


Tak, budowanie map z małych klocków jak najbardziej ma się pojawić.

--
Teraz chciałbym troszkę napisać o tym nad czym pracowałem między opublikowaniem tego tematu a dniem dzisiejszym (czyli w przeciągu kilku dni). Myślę, że stosowne byłoby założenie strony z postępem prac, może w formie bloga, umieszczałbym tam nowości w miarę często, może raz na tydzień. Póki co jeśli ktoś chce zaznajomić się z moją dotychczasową twórczością zapraszam na swoją dobrze znaną stronę, którą niedawno odświeżyłem (strona jest bardzo prosta, bo piszę ją w HTMLu).

Zatem pracowałem troszkę nad stroną internetową po angielsku (póki co niedostępną on-line), która opisywałaby projekt, oraz nad konstrukcją gier pisanych w tym języku.

Projekt tego typu jest duży i składa się z wielu części. Ważna jest kolejność wykonywania poszczególnych części. Pierwszym elementem, nad którym postanowiłem pracować to konstrukcja gier pisanych w tym języku. Pomyślałem co jest potrzebne by ułożyć prostą grę z duszkami i doszedłem do pewnych wniosków, które poniżej zamieszczę.

Innym elementem, nad którym będę pracować w praktyce na końcu jest gramatyka tego języka. Na końcu, ponieważ gramatyka jest potrzebna dopiero przy pracy nad kodem kompilatora, pozwoli mi napisać stosowny automat (czyli program kompilujący).

Wnioski są następujące: prosta gra z duszkami jest pewną konstrukcją, w której na planszy obecne są: tło oraz te duszki (bohater i przeciwnicy), no a silnik gry polega na pewnych wydarzeniach, które są wykonywane pod wpływem zmiany stanu kontrolera (joysticka). Oprócz tego wykonywane są funkcje animujące obiekty obecne na planszy.

Oznacza to, że grę tego typu można skonstruować definiując tylko pewne funkcje, które będą działać na zasadzie przerwań, a następnie uruchamiając całą tę maszynerię. Odchodzi w zasadzie potrzeba konstruowania proceduralnego programu, ponieważ pewne wydarzenia się nie zmieniają (jak naciskanie kontrolera).

Zatem tak: może jakaś część z Was pamięta moją grę z balonikami. Postaram się napisać tutaj jak taki program wyglądałby w GameX jako dobry przykład. Więc wymyśliłem, że gra będzie składać się z sekcji data oraz function. W sekcji data definiujemy pewne zmienne, zaś w sekcji function definiujemy funkcje programu. Gra musi posiadać dwie funkcje: Start(), wykonywany przed właściwym rozpoczęciem gry oraz Main().

W sekcji Info typu data byłyby zawarte przypisania pewnym stałym programu, czyli m.in. preferowana platforma oraz gatunek gry. Skupmy teraz uwagę na sekcji Init typu data, gdzie zawarte będą deklaracje zmiennych. W przypadku gry z balonikami i założeniu, że jest tylko jeden etap napisalibyśmy:
data Init
{
   picture background = "background.iff";
   images sprites = "sprites.gximages";
   samples sounds = "sounds.gxsounds";
   music theme = "theme.mod";
}
Deklaracja zmiennych zaczyna się od jej typu (picture, images, samples bądź music w tym przypadku) następnie następuje nazwa zmiennej oraz przypisanie wartości (nazwa pliku z danymi). Teraz możemy odwoływać się swobodnie do tych zmiennych w kodzie naszej gry, przy czym najpierw należy załadować je jawnie do pamięci. Teraz piszemy funkcję Start():
function Start()
{
   load background, sprites, sounds, theme;
}
Funkcja load po prostu ładuje wszystkie dane do pamięci (dane będą mogły być ładowane wewnątrz programu gdy np. jest ich zbyt wiele by zmieściły się równocześnie w pamięci). Teraz piszemy główną funkcję programu:
function Main()
{
   addsprite hero, hero_x, hero_y, sprites.0, Hero;
   for (i = 0 to 2)
   {
      addsprite baddie[ i ], baddie_x[ i ], baddie_y[ i ], sprites.1, Baddie;
   }
   controller HeroUp, HeroDown, HeroLeft, HeroRight, HeroFire;
   animate hero, baddie[0], baddie[1], baddie[2];
   run;
}
Polecenie addsprite dodaje duszka do obrazu, atrybutami są: nazwa zmiennej, pozycja na planszy, grafika oraz procedura animująca. Proszę zauważyć, że grafika jest określona jako obrazek nr 0 w pliku sprites.
Polecenie controller określa funkcje odpowiedzialne za przyjmowanie sygnałów z kontrolera (joysticka).
Polecenie animate definiuje które duszki mają być animowane i w jakiej kolejności.
Polecenie run uruchamia mechanizm gry.
Teraz należałoby napisać odpowiednie funkcje jak Hero, Baddie, które animowałyby bohatera i przeciwników oraz HeroUp, HeroDown itd. które zajmowałyby się obsługą ruchu joysticka. Napiszę to jednakże na stronie internetowej.

Zatem tak wyglądałaby konstrukcja gier w języku GameX. Oczywiście jest to tylko jeden przykład, ale mam nadzieję, że dobrze pokazuje moją koncepcję.

[#44] Re: GameX - pomysł na zwiększenie produkcji gier

@carrion, post #39

Witam,

To sa na amidze jakies gotowe edytory do robienia map z klockow w takich platformowkach?

Sam nie używałem, ale jest PDTDesignerPrg na Aminecie.

Ogólne pytanie poei no być czy sa tego typu narzedzia do projektowania ekranów do gier.

Ja używałem na pececie Mappy.

Pozdrawiam

[#45] Re: GameX - pomysł na zwiększenie produkcji gier

@Klub Amigi RNS, post #1

Jak dla mnie jak masz chęci i zaparcie by projekt ukończyć, to rób bez względu na to co mówią, dla własnej przyjemności, a jak to naprawdę będzie to się okaże, poza Polską są tez inne kraje. Martwi mnie tylko trochę platforma - A1200, mógłbyś przynajmniej dodać obsługę OCS/ECS, na A500 i A600 są karty z 020+, więc jeśli 020 jest minimalnym wymogiem, to przynajmniej dopalone wersje tych komputerów mogłyby pociągnąć twój silnik( na A600 jest karta Jensa, na A500 ponoć też ma być)

[#46] Re: GameX - pomysł na zwiększenie produkcji gier

@rafgc, post #45

Pytanie czy robienie amigowego stuffu dla wlasnej przyjemnosci ma sens, skoro srodowisko tego nie wymaga czy wrecz nie potrzebuje... detektyw
[#47] Re: GameX - pomysł na zwiększenie produkcji gier

@selur, post #46

Wydaje mi się, że obecnie jest sens robić cokolwiek tylko dla własnej przyjemności. Przecie dolarów z tego i tak nie będzie. A skoro nie to czemu się przejmować negatywnymi opiniami?

[#48] Re: GameX - pomysł na zwiększenie produkcji gier

@strim, post #47

Ale z takiego czegos to nawet popularnosci nie bedzie.
To juz chyba lepiej zrobic cos z czego sie zaslynie w srodowisku a dla wlasnej przyjemnosci, to mozna zjesc tabliczke czekolady i efekt ten sam bedzie ;)

Zreszta ja bym zrobil sonde, kto w ogole jest czyms takim zainteresowany, wtedy wszystko sie wyjasni.
[#49] Re: GameX - pomysł na zwiększenie produkcji gier

@selur, post #48

A co gorsze,może 10% ludzi którzy zadeklarują chęć używania naprawde zacznie cos robic.Nie rozumiem tez po co tworzyć narzędzie tego typu dla programistów których nie ma.A jesli trafi sie juz jakis zapaleniec to przeciez zacznie robic gre od pisania własnego enginu.Bo to jest tak naprawde jedyne co koderzy chca robic,choc sami projektowac jego założeń i tooli juz absolutnie nie powinni bo zazwyczaj nie maja o tym zielonego pojecia.Bo przecież sami nie korzystają z takich zabawek.Lepiej juz sprawdził by sie jakis przyjazny gamemaker nie wymagający od twórcy grama kodu/skryptu.Ale zrobienie czegoś takiego to naprawdę gruba robota dla kilku weteranów dev.Nie chce zniechecac ale wszystkie wypowiedzi tu i na execu kolegi -Klub Amigi RNS/Minniat- sa nacechowane takim ładunkiem dziecinnej powagi i całkowicie pozbawionej podstaw pewnosci siebie ,ze nie mogłem sie powstrzymać od potrollowania.Jesli kogos uraziłem ,prosze mi wybaczyc a koledze programiscie życzę powodzenia.Zapal do pracy to dobry początek bardzo długiej drogi OK



Ostatnia modyfikacja: 09.10.2011 02:46:46
[#50] Re: GameX - pomysł na zwiększenie produkcji gier

@Klub Amigi RNS, post #43

Witam,

Kolejna porcja pytań. Tym razem skupię się na języku.

1. W twoim przykładzie widzę zmienną i i od razu nasuwa się pytanie, jakiego typu jest ta zmienna, w jaki sposób będzie przechowywana w pamięci ?

2. Jakie będą dostępne struktury danych ?

3. Czy będą dostępne normalne sprajty ?

4. Na jaki język, będzie tłumaczony kod ? Bo ja się pogubiłem, ma być tworzona kolejka funkcji które będą wykonywane ale przecież cuda mogą być w takiej funkcji, więc trzeba kompilować taką funkcję przynajmniej do jakiegoś kodu pośredniego ( co dodatkowo spowolni działanie ).

5. W twoich przykładach podajesz, rzeczy związane z grafiką. Nic nie ma o AI, o tym w jaki sposób poradzisz sobie z innymi rzeczami, jak wyświetlanie punktacji czy też fonty.

6. W jakiej funkcji będzie logika gry.

7. W jaki sposób będzie można dodać inne języki do gry.

Pozdrawiam

[#51] Re: GameX - pomysł na zwiększenie produkcji gier

@Klub Amigi RNS, post #43

Pytanie ? Czy owe gry skupią się na rozdzielczości 320 x 256 lub 640 x 256 ?? A czy Amiga jest w stanie w ogóle obsłużyć wyższe ? Np. CPU 030/50 MHz ? Oczywiście AGA lub ECS/OCS nie karty GFX...

Z uwagi na fakt że dzisiaj mało kto posiada oryginalny palowski monitor, nawet tryby "migające" nie migają na wielu modelach. Dla mnie największa porażka to ta rozdziałaka. Chyba łatwo sobie wyobrazić obraz 320x256 rozciągniety do 27 cali... Pixel aż piecze w oczy..



Ostatnia modyfikacja: 09.10.2011 10:40:29
[#52] Re: GameX - pomysł na zwiększenie produkcji gier

@asman, post #50

Kolejna porcja pytań. Tym razem skupię się na języku.

1. W twoim przykładzie widzę zmienną i i od razu nasuwa się pytanie, jakiego typu jest ta zmienna, w jaki sposób będzie przechowywana w pamięci ?


Na wstępie chcę zaznaczyć, że pracuję nad językiem od kilku zaledwie dni i przykład jest niepełny. Zmienna jest oczywiście typu całkowitego, będzie musiała być zadeklarowana wcześniej jako bajt, słowo lub długie słowo (ze znakiem lub bez znaku). Najpewniej deklaracja będzie polegała na tym samym jak deklaracja zmiennych zawierających dane z plików.

2. Jakie będą dostępne struktury danych ?


Będzie sporo predefiniowanych typów np. duszek no i, najpewniej, możliwość definiowania własnych. Na przykład duszek (sprite) będzie przekazywany do funkcji animującej i polecenia wewnątrz tej funkcji będą mogły odwoływać się do pól jego struktury podobnie jak ma to miejsce w języku C tj. poprzez znak kropki. Dzięki temu będzie można "wyłuskać" współrzędne duszka, jego grafikę itp. tylko na podstawie zmiennej typu sprite.

Prócz tego oczywiście strukturą danych jest np. images (zbiór obrazków), który miałby pola 0, 1, 2 itd. które odpowiadałyby poszczególnym obrazkom w tym pliku, music (muzyka) - zmienna tego typu byłaby argumentem funkcji playmusic.

3. Czy będą dostępne normalne sprajty ?


Duszki w tym przykładzie byłyby tak naprawdę bobami (czyli obiektami blittera), ale nie wykluczam obsługi prawdziwych sprzętowych duszków. Będą one wyróżnione innym typem zmiennej np. sprite i hwsprite (hardware sprite) i oczywiście podlegać ograniczeniom tego typu obiektów.

4. Na jaki język, będzie tłumaczony kod ? Bo ja się pogubiłem, ma być tworzona kolejka funkcji które będą wykonywane ale przecież cuda mogą być w takiej funkcji, więc trzeba kompilować taką funkcję przynajmniej do jakiegoś kodu pośredniego ( co dodatkowo spowolni działanie ).


Zatem tak, kod będzie kompilowany do postaci pośredniej, która będzie wtedy wykonywana przez interpreter (nie procesor), ale będzie to postać już bardzo prosta w interpretacji, niemalże jak polecenia procesora, każdy element w tablicy, którą utworzy kompilator będzie zawierać adres funkcji napisanej w asemblerze oraz argumenty i rodzaj tych argumentów. Wykonanie programu będzie polegało na wywoływaniu wszystkich funkcji zawartych w tej tablicy z odpowiednimi argumentami.

Będzie to bardzo optymalny kod, a poza tym będzie można korzystać jeszcze z przerwań dzięki czemu program będzie bardzo szybki.

5. W twoich przykładach podajesz, rzeczy związane z grafiką. Nic nie ma o AI, o tym w jaki sposób poradzisz sobie z innymi rzeczami, jak wyświetlanie punktacji czy też fonty.


Przykład, który podałem rzeczywiście jest dość prosty, ale nic nie stoi na przeszkodzie, żeby podawać propozycje, dzięki czemu język uzupełni się o brakujące elementy. Fonty oraz tekst - warto byłoby to wprowadzić, myślę sobie że font będzie typem danych podobny do pozostałych i dodane będą polecenia setfont (ustawia font na podany), text (wypisuje tekst na ekranie, sformatowany). Kwestia gdzie to będzie wykonywane - myślę sobie, że warto byłoby rozbudować koncepcję polecenia animate, która ustawia w kolejce procedury animujące duszki o takie rzeczy jak np. właśnie wyświetlanie punktacji.

Jeśli chodzi o AI to najlepiej gdybym zrobił biblioteczkę, która zawierałaby już pewne gotowe zachowania się komputera w różnego rodzaju grach, ale oczywiście będzie można definiować własne funkcje zawierające nawet skomplikowane warunki logiczne. Obecnie nie jest to aż tak ważne, ważniejsza jest dalsza specyfikacja tego języka.

Myślę sobie, że aby uprościć konstrukcje poleceń to np. dodawanie dwóch zmiennych lub stałej do zmiennej odbywałoby się poprzez polecenie add np. add points 50 dodawałoby 50 punktów do punktacji gracza. Podobnie wyglądałaby reszta tego typu poleceń.

6. W jakiej funkcji będzie logika gry.


Zatem logika gry będzie rozprowadzona na wiele funkcji. Tak jak napisałem w przykładzie prosta gra z duszkami polega na procedurach zmiany stanu kontrolera (joysticka) oraz procedurach animacji tychże duszków. Każda taka funkcja otrzymywałaby repertuar parametrów odpowiedni dla danej funkcji i na jej podstawie zmieniała stan obiektów. Każdą taką funkcję wywoływałoby pewne wydarzenie (np. co ramkę bądź gdy zmieniono stan joysticka). Na przykład gdy chcemy by ruch joystickiem powodował ruch bohatera o 4 piksele co ramkę piszemy to w procedurze animującej bohatera (która jest wykonywana co ramkę dopóki jej to nakażemy). Zatem fragment kodu tej funkcji zawierałby taki wpis:
mul controller.x 4
add hero.x controller.x
mul controller.y 4
add hero.y controller.y

Gdzie hero to struktura typu sprite, a x i y to odpowiednie współrzędne tego duszka, zaś controller to wewnętrzna struktura która zawierałaby w tym momencie stan danego kierunku joysticka (0, 1 bądź -1). W tym przykładzie pominąłem akurat możliwość optymalizacji mnożenia przez potęgę dwójki.

7. W jaki sposób będzie można dodać inne języki do gry.


Bardzo interesujące pytanie, ale w tym momencie nie przewiduję żadnych rozszerzeń, ani wtyczek do GameX, choć dynamiczne linkowanie z jakimś kodem z zewnątrz jest ciekawym pomysłem.

[#53] Re: GameX - pomysł na zwiększenie produkcji gier

@selur, post #46

Choćby dlatego, że każdy pomysł, nawet mało potrzebny jest mieszany z błotem za każdym razem schematyczną konstrukcją "nie rób, bo to bez sensu, nikt nie będzie korzystał, nie będziesz miał sławy", czego efektem jest zawsze to, że nie dzieje się nic, a skoro dana osoba i tak nie będzie raczej robiła niczego innego, bo nie każdego interesuje rozwój systemu i pisanie sterowników do kart sieciowych i stosów USB, to skieruje skupi swoje moce przerobowe na inne nie amigowe projekty, których nikt nie wypomni, że są bez sensu. Jak dla mnie jak nie ma robić nic, to niech robi to co chce, przy pisaniu takiego silnika może zdobyć cenne doświadczenie i nawet jeśli silnik nie zyskałby większej popularności, to zdobyte umiejętności mogłyby pozwolić na stworzenie czegoś lepszego i ambitniejszego. Tak jest od zawsze, weźmy np na mikrokontroler atmega, program,uje się go zazwyczaj w C lub Bascomie (rzadko w assemblerze) wejdź na youtube i poszukaj co ludzie sobie z tym robią, zaczyna się zawsze z jakimiś mało potrzebnymi projektami jak ten http://www.youtube.com/watch?v=OrNFuwXzw4Q (uwierz mi, że to zajmuje od cholery cennego czasu), zdobywając doświadczenie buduje się sprawniejsze wersje jak te http://www.youtube.com/watch?v=l4F8UbM-1t4 albo te http://www.youtube.com/watch?v=oLygWkHo9nw&feature=related.

A może zamiast ankiety się po prostu spytać, czy interesują go inne projekty niż GameX? Bo jeśli nie, to czy dalej warto mu mówić, by dał sobie siana i poszedł sobie gdzie indziej?



Ostatnia modyfikacja: 09.10.2011 13:13:57
[#54] Re: GameX - pomysł na zwiększenie produkcji gier

@Wojox, post #51

Początkowo myślałem o tym, by wersja GameX dla klasyka uruchamiała się w natywnym trybie Amigi czyli PAL dla max. prędkości działania, a wersja dla kart graficznych na ekranie z odpowiednim trybem wyświetlania.

Jeśli da radę, to zrobię też możliwość włączenia obrazu VGA na klasyku, jeśli ktoś nie posiada monitora PAL lub scandoublera.

Technicznie GameX miałby elastyczny sposób wyświetlania z pojedynczym lub podwójnym buforowaniem. Autor gry w tym języku nie musiałby martwić się o sposób realizacji wyświetlania. W przyszłości można wprowadzić też wyższe rozdziałki i skalowanie obrazu dla nowszych systemów, co nie sprawi dużego problemu, ale ponieważ teraz skupiłem się na klasyku pozostanę przy tradycyjnych rozdzielczościach Amigi.

[#55] Re: GameX - pomysł na zwiększenie produkcji gier

@rafgc, post #53

jakby minniat wyskoczyl z pomyslem zrobienia klona angry birdsa (albo dowolnej prostej do zrobienia ale grywalnej gry) na klasyka to bym przyklasnął ręce

Angry birds jak też i inne fajne gry opierają się o Box2d. Jeśli by minniat portnął to na amigę (i zoptymalizował) to by było 1000 razy bardziej pomocne dla developerow gier niż jakiś jego wydumany system z wydumanym jezykiem



Ostatnia modyfikacja: 09.10.2011 14:07:18
[#56] Re: GameX - pomysł na zwiększenie produkcji gier

@rzookol, post #55

Ja bym oddał królestwo i łokieć królewny za amigową wersję gierki w stylu Tower Defense lub Pandemic.



Ostatnia modyfikacja: 09.10.2011 14:28:49
[#57] Re: GameX - pomysł na zwiększenie produkcji gier

@rzookol, post #55

Nie przypominam sobie, żeby Minniat był założycielem tego wątku, ani żeby dotyczył on portowania gierek z telefonów/innych platform na Amigę. Temat "Co mógłby zrobić Minniat", powinien znaleźć się w osobnym wątku.

[#58] Re: GameX - pomysł na zwiększenie produkcji gier

@rafgc, post #57

Racja...caly ten watek jak i wypowiadanie sie w nim jest bez sensu.
[#59] Re: GameX - pomysł na zwiększenie produkcji gier

@Klub Amigi RNS, post #54

Czym GameX ma się różnić od AMOSa? Składnią języka, zgodnością z systemem i? W żadnym wypadku nie chce Cię zniechęcać tylko się zastanawiam.
A teraz parę uwag.
Tablica z adresami funkcji jako patent na interpreter tylko na pierwszy rzut oka wygląda tak różowo. Pierwszy problem który się pojawi to uzyskanie tych adresów ale to drobnostka, kolejny to parametry, czy stała ilość czy w zależności od polecenia. Jak stała to będzie się marnować dużo pamięci jak zmienna to trzeba skądś odczytać ile aby wiedzieć gdzie jest kolejne polecenie. Do tego komendy będące instrukcjami języka i wymagające skoków, trzeba wiedzieć gdzie jest rozkaz do którego skaczemy. No i na koniec jeszcze taki szczegół jak przekazywanie parametrów do funkcji i zapamiętywanie adresu powrotu. Czyli nie będzie to takie proste i szybkie jak się na początku wydaje.
Kolejna sprawa - język. W pierwszym przykładzie o ile dobrze pamiętam zmienne były deklarowane/definiowane przez var nazwaZmiennej, teraz już wprowadziłeś typ. Czyli język zmienił się już w tym momencie diametralnie i teraz jest silnie typowany. Deklaracja picture background jak rozumiem będzie tworzyć wskaźnik na strukturę typu picture, a co będzie tworzyć int x? Czy wskaźnik czy zmienną na stosie? Jeśli zmienną na stosie, a chcesz zwracać wartości przez parametry funkcji to jak będzie się taką funkcje deklarować aby wiedziała, że to jest parametr wyjściowy? Picture jest wskaźnikiem wiec można to na co wskazuje zmodyfikować, ale modyfikacja zmiennej int, która nie jest wskaźnikiem nie będzie widoczna poza funkcją. To zaledwie kilka pytań z tych, na które będziesz musiał sobie odpowiedzieć.
I jeszcze uwaga techniczna na koniec. Jeżeli będziesz pisał parser sam na palcach to faktycznie add x y jest prostrze, ale jeżeli tak go będziesz pisał to naprawdę już teraz Ci współczuję bo nawet z takimi uproszczeniami będzie to bardzo niewdzięcze. Dlatego sugeruję Ci użycie jakiś narzędzi do pisania skanera/parsera, np. Flex/Bison i wtedy x = x + y nie będzie sprawiać problemu.

[#60] Re: GameX - pomysł na zwiększenie produkcji gier

@smith, post #59

w pierwszej implementacji minniat zoptymalizuje kod wyswietlania dla agi i blittera, nie zaburzaj jego toku myslowego bredniami o parsowaniu, lexerach i innych niepotrzebnych rzeczach. Poza tym minniat wpierw napisze a potem dopiero będzie dopracowywał. Myślisz ze teraz, na poziomie akceleracji wyswietlania spritów blitterem potrzebny mu jest jakis silnie typowany język?

Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem