1.Mapa gry ma być wczytana z obrazka, Jednak aby bohater mógł wykrywać
kolizje do pamięci wczytam bitmapę 2 kolorową (biały -brak kolizji
,czarny -kolizja)
Nieco dziwny pomysł - warstwy grafiki i mechaniki gry powinieneś mieć rozdzielone, a system kolizji oparty na bitmapach dwukolorych to jakaś paranoja; To, co ma być rysowane nie może służyć do określania dostępnych stref do poruszania się po mapie - jakoś to abstrakcyjnie brzmi;
2.Bohater obrazek (Gify w zależności od poruszania się )-komponent TImage z odpowiednimi właściwościami
Czyli chcesz zrobić grę 2D? TImage? O nie! Żadnego VCL! Zapoznaj się z dostępnymi API do tworzenia gier w trybie graficznym, bo na komponentach buduje się aplikacje użytkowe, a nie sensowne gry;
3.Potwory Tworzone w losowych miejscach (użyte randomize) -wczytywane z obrazków
No tak, tylko te randomowe miejsca muszą być przemyślane; Obrazki to obrazki - trzeba sobie przygotować odpowiednią hierarchię klas dla różnych postaci, aby były malowane w grze w sposób sensowny, a nie kupą globalnych, nie powiązanych ze sobą procedur;
4.Gra
ma być stworzona bez żadnego dodatkowego silnika graficznego (wiem
silniki graficzne są po to by ich używać ich ale mam "spróbować" coś
takiego stworzyć aby pokazać możliwości środowiska jak Delphi 7)
Ty nie masz na myśli silników graficznych, tylko API z funkcjami do grafiki; Silnik zarządza grą - nim się nie maluje;
Jeśli chcesz to możesz się bawić z komponentami, ale to raczej strata czasu; Dużo lepszy efekt (i bardziej wydajny) uzyskasz wykorzystując gotowe funkcje API, a przy tym nauczysz się sporo nowych rzeczy; Na tym polecałbym się skupić, a formularze i komponenty zostaw dla aplikacji użytkowych;
I teraz pytanie do systemu walki [...]
Nic jeszcze nie masz, a już zastanawiasz się nad walkami; Najpierw zrób jakąś podstawę, np. samo uruchamianie aplikacji, ładowanie ustawień, obsługa menu itd., a później zabierz się za mapy, postacie i scenariusz; Możesz to sobie rozpisać czy rozrysować na kartkach, ale programować zacznij od podstaw;
Będę potrzebował obsługę wielu wątków, czy też nie.
Raczej na jednym wątku (głównym) się nie skończy; No chyba, że chcesz zrobić coś pokroju gier z Pegasusa, gdzie jeden "wątek" sterował całą grą i przerysowywał obraz (stąd przy większej liczbie ruchomych elementów można było zauważyć charakterystyczne lagi przy ich poruszaniu się); Sądzę, że wątków jeszcze nie poznałeś, więc masz się czego uczyć;
Jeśli założenia nie będą niemożliwe do zrobienia to zapytam o bardziej szczegółowe rzeczy :)
Jeśli zależy Ci na większym projekcie to przed Tobą jeszcze długa droga; Trzba opanować wszystkie techniki, które chciałbyś wykorzystać w tej grze, nauczyć się pisać efektywny kod, który w przypadku gier jest bardzo ważny; Zaplanować całą grę wraz z wyglądem samego programu i wszystkiego innego (postaci, map itd.) i rozpisać scenariusz gry, na podstawie którego będzie możliwe zaprogramowanie całęgo systemu gry;
W sieci można znaleźć mnóstwo materiałów o tym jak zacząć pisanie gier, są dostępne także dokumenty z kompletnym planem jakiejś starej gry - np. sam mam w PDF biblię gry "Prince Of Persia 2" z roku 1991, zawierającej 217 stron z rozplanowaniem kluczowych i mniej ważnych elementów; Mnóstwo opisów, rysunków grafik tytułowych, plansz, postaci (ich wygląd, klatki w animacji) itd.; Ciekawa lektura na początek :]