cezarX

Pablo, na jedno wychodzi... Dopisanie partii kodu odpowiedzialnego za questy, modyfikacja/optymalizacja istniejących rzeczy... ..bez różnicy...

Widzę, że szykuje się spora przebudowa Almory od strony technicznej. Może lepiej byłoby zacząć POWOLI przepisywać ją na nowo... Dałoby to znacznie lepsze efekty niż dopisywanie nowych rzeczy (te tylko doraźnie) i ciągła ingerencja w, i tak już zagmatwany, kod... :)

...i jeszcze masę rzeczy, które wymagają bardzo dużo pracy... Litości!!!

to nawet lepiej, byłby bardziej obiektywny...

___________________________________________ ERROR in action number 1 of Step Event for object connection_menu_Step: In script sc_Data_PowerUpTake: Error in code at line 48: if ( _player == global.myid ) at position 33: Unknown variable myid

Jest możliwość szybkiego dostania się na to forum? Tzn. wprost ze strony?

Świetnie, choć Twoja doba Borek musi chyba trwać więcej niż 24h... B)

Zgadzam się, ale sprite ściany zawiera już wszystkie możliwości łączenia, więc łatwiej i ekonomiczniej jest zapisać rodzaj muru i stąd szybko ustalić jak ma wyglądać, aniżeli wczytać mapę (tzn. jaki obiekt gdzie ma być) i wtedy ustalać rodzaj owego muru.

Ale po co tracić te 2 sekundy :) Zwiększenie rozmiaru pliku będzie znikome. Licząc dla mapy 2500x2500 pikseli oraz kafla 25x25 pikseli (tu mogę się mylić co do wielkości) to mamy 100x100 kafli, czyli 10000 kafli. Jeżeli przyjąć wypełnienie mapy murem za 40% (może za dużo :)), to pozostaje jakieś 4000 kafli. Zapisanie rodzaju ściany zajmie nie więcej niż 1 bajt, co daje 4000 bajtów, czyli, w przybliżeniu, około 4KB. Przy dzisiejszych pojemnościach dysków twardych jest to wartość kompletnie niezauważalna (dla dysku 250GB - ok. 244 140 625KB - czyli jakieś 0,0000016384% pojemności). Przyjmując rozmiar mapy 200KB, to otrzymamy wzrost rozmiaru o jakieś 2%. Czy to tak dużo? :P Tylko raz? - Zapewne nie, chyba przy każdym ładowaniu mapy. Chyba łatwiej jest trzymać gotową do użycia mapę niż jeszcze ją przeliczać. :) Może właściwie to są tylko drobnostki... :thumbsup:

Zrobienie takiego efektu to żaden problem (w Delphi również), pozostaje tylko kwestia, kiedy go zastosować. Widać po przykładzie, że murki łączone są przy ich tworzeniu. Rzeczywiście, takie rozwiązanie też mogłoby być (choć można by się przyczepić do każdorazowego sprawdzania, którą grafikę wstawić, a co za tym idzie, do - zapewne niewielkiego - opóźnienia startu gry). GMem się już nie interesuję, wolę "czyste" programowanie, dlatego nie widziałem przykładu.

Zastanawiam się Borek, jak rozwiązujesz problem ustawiania rodzaju ścian (zakrętów, prostych, itp.). Na screenie widać tylko kostki niepołączone ze sobą, na filmach widać połączone ściany. Mam nadzieję, że problem łączenia będzie rozwiązywany (najpóźniej) przy zapisie mapy, a nie w czasie działania gry. Po co niepotrzebnie obciążać procesor...

Na ruterze można zazwyczaj robić przekierowanie połączenia dla danego portu na wskazany adres lokalny. Wiele razy tak robiłem i zawsze działało.

Po pierwsze: wierzyć. Po drugie: zapewne GS nas jeszcze mile zaskoczy... :)

literówka, już poprawiam... :)

Dużo w tym wszystkim jest racji, ale nie można tylko ciągle pisać: NIC WAM NIE WYCHODZI; NIE CHCE WAM SIĘ; NIE SKOŃCZYCIE TEGO; KOLEJNY PROJEKT DO KOSZA (i inne podobne teksty...) Trochę OPTYMIZMU, nie od razu Rzym zbudowano, używajcie optymistycznych i BUDUJĄCYCH wypowiedzi. Co do projektu(ów)... Pracujcie sobie spokojnie (nic na siłę!) i nie zmieniajcie co chwilę radykalnie koncepcji gry. Powodzenia!!! ZROBICIE TO!!! :D

Chodziło mi o "dziury" w kodzie (kwestia techniczna), które gracze mogliby wykorzystywać. Autor questa musi przewidzieć działania gracza, aby ten poszedł po wyznaczonej drodze, a nie skrócił ją sobie, kiedy w zamyśle autora miał nie skracać (coś jak przejść do następnej części zadania nie ukończywszy poprzedniej). B)

Bardzo ciekawy pomysł, dzięki niemu gra będzie "nie do przejścia" przez jednego gracza. Jednak podejrzewam, że problemem będzie zapisanie w kodzie czegoś takiego, w dodatku w ten sposób, aby nie można było obejść żadnego elementu gry, muszą być przewidziane wszelkie ewentualności.

Gra nie może być liniowa, tzn. idziesz za miasto, powybijasz trochę stworków, zbierzesz pełny inwentarz, wracasz do depozytu (ewentualnie do sklepu), a potem.. znowu za miasto... Nie! Taka gra nie ma sensu na dłuższą metę (choć z kolegami gra się znacznie dłużej). Questy już bardzo mocno urozmaicają rozrywkę, jednak w powiązaniu ze zmianą dzień/noc można wykorzystać jeszcze lepiej czas gry. Np. masz zadanie dostępne dopiero wieczorem, czyli musisz czekać parę godzin (oczywiście w grze), więc w tym czasie wpadasz to tawerny, grasz partyjkę pokera, szachów :), kości, czy czegoś tam jeszcze, napijesz się z kumplami, przy okazji możesz zarobić trochę kasy albo odblokować "niechcący" jakieś nowe możliwości, dostać unikalne przedmioty czy nawet być świadkiem tudzież uczestnikiem jakiejś burdy... Możliwości jest bardzo wiele. Wtedy naprawdę chce się poświecić czas na grę, rywalizację, widzi się sens gry, jej interaktywność i wszystko to, co ma do zaoferowania. Ile razy cieszyliście się, gdy dostaliście/zrobiliście coś w grze, co nie było dostępne przez długi okres czasu (bo nie wiedzieliście o tym lub czekaliście bardzo długo...).

To jest logiczne, przecież wszystkie grafiki (a jest ich sporo) i tak muszą trafić do pamięci karty, ale z mojego doświadczenia wiem, że główne obliczenia i tak spadają na procesor (choć obserwacje mogą być czasami mylące). Gdyby GPU wykonywał obliczenia, gra chodziłaby jeszcze płynniej. Tu jest chyba główna wada GMa, duże wykorzystanie pamięci (RAM, pamięć graficzna), co jest problemem również dla programisty i przerzucanie większości zadań na CPU (np. efekty cząsteczkowe - wymagają bardzo dużej mocy obliczeniowej). Normalnie grając mam max FPS, tylko gdy jest więcej obiektów to mi zwalnia.

Grając w Almorę nie zauważyłem, aby karta graficzna pracowała na pełnych obrotach. Wydaje mi się, że gry GMskie wykorzystują tylko procesor (oczywiście wszystko przechodzi jakoś przez GPU). Grając na kompie i z serwerem na laptopie (w LANie), kiedy ustawiłem dużo wrogów w jednym miejscu, komp z grą nie wyrabiał (kilka procent zapełnienia paska FPS). Gdy jakiś program korzysta z karty graficznej, wiatrak na niej przyspiesza, a podczas gry w Almorę przyspieszał tylko wiatrak od procesora. Robiąc swoją grę w Delphi z DelphiXem, po wstawieniu ogromnej ilości obiektów graficznych wraz miałem maksymalną szybkość wyświetlania (ustawioną na 75 FPS). Moja karta to 7600GT, procesor P4 2,8. Wniosek: GM korzysta z przyspieszania programowego (CPU), a nie sprzętowego (GPU).

Nie przesadzaj M@ti002... kilka sztuk "światła" w widoku gry na pewno nie spowolni jej drastycznie ... a efekt wygląda całkiem nieźle :jezor: W DelphiXie postawisz ze 100 takich i nadal będzie max FPS, ale to oblicza karta. Nie wiem do końca jak jest w GMie (zdaje się, że procek oblicza wszystko)

Opracowałem sobie taki mały system nocy. Na noc nakładasz czarną warstwę z 50% przezroczystością, a na to dajesz punktowe oświetlenia (obraz z kanałem alpha np. z pędzla "Circle Fuzzy (19)" w GIMPie) z 30% przezroczystością. Wartości procentowe oczywiście do modyfikacji. np.

straciłbyś połowę (a może i więcej) z gry, w końcu kiedyś trzeba spać... :)

zalatuje mi Wiedźminem... ale pomysły są fajne

O ile wiem to GM jest robiony w Delphi, a w tym gdy wrzucasz coś do pamięci (obrazek), to od razu zajmowana jest większa część pamięci, aniżeli ma dany plik graficzny. Korzystam z UnDelphiX. Jak użyję pliku PNG, który ma jakieś 200-300 kB, to ubywa znacznie więcej pamięci. Myślałem właśnie o tym, że obrazy są przechowywane w pamięci jako bitmapy, albo też pamięć nie jest optymalnie wykorzystana (tak jak z klastrami na dysku, gdy pliki są mniejsze od klastra).