1. Wstęp
Komponentowe podejście w programowaniu aplikacji/gier to założenia inny sposób przechowywania danych i metod niż w podejściu obiektowym. Podstawową różnicą w stosunku do typowego OOP jest inna koncepcja rozszerzenia funkcjonalności danego obiektu:
- w OOP dziedziczenie jest podstawą rozszerzenia funkcjonalności,
- w podejściu komponentowym „ważniejszym” modelem jest zastosowanie „kompozycji”.
W przypadku Javy uzyskam to poprzez zastosowanie interfejsów. Każdy komponent będzie posiadał pewne właściwości, które będą zdefiniowane przy pomocy interfejsu.
2. Definicje/Założenia
Trochę definicji i założeń aby nam przybliżyć to podejście komponentowe.
W programowaniu komponentowym możemy wyróżnić następujące elementy:
- Jednostka (Entity) – reprezentuje prosty obiekt gry lub programu, np. porcje danych. Połączenie ich stanowią się w świat gry lub dane programu.
W grach jednostką możemy określić: playera, bazę dowodzenia, pocisk, statek.
W programach przetwarzających dane jednostką możemy określić jedną porcję przetwarzanych danych (komunikat danych). - Komponent (Component) – jest to atrybut, zachowanie lub cecha danej jednostki. Np.: pozycja cechą jest pozycja X:Y, kolor, czas życia, zachowanie na akcje użytkownika. W przypadku przetwarzania danych czas otrzymania komunikatu, źródło komunikatu, typ komunikatu, itd.
- System – w przypadku programowania komponentowego system zawiera algorytmy i logikę, która zostaje wykonana na jednostkach świata. Dany podsystem wie o tych jednostkach które są niezbędne do wykonania danej logiki Zapewnia do dużą separację podsystemów programu. Dla przykładu w typowej grze możemy wyróżnić następujące systemy/podsystemy: render, logika AI, wyszukiwanie ścieżek, poruszanie się obiektów, reakcje na zdarzenia użytkownika.
Najważniejsze założenia:
- Każda jednostka ma swój unikalny ID, na ogół nie zawiera innych danych ani logiki.
- Komponent zawiera dane nie zawiera logiki.
- System zawiera algorytmy i logikę do pracy na komponentach.
3. Cel projektu
Celem tego będzie napisanie silnika prostych gier zbudowanych służącej do wytarzania/prototypowania. Ktoś powie kolejny silnik, edytor, itd. … to prawda jest ich setki, tysiące … ale:
- na co dzień zajmuję się programowaniem aplikacji backendowych oraz mobilnych (Java, PHP, itd.), które głównie przetwarzają dane rozproszone, wiec programowanie multimediów/gier to jest tak mała odskocznia
- swoje pierwsze demko napisałem w 1994 roku na C-64 w czystym asm, w 2004/2005 pierwszy silnik renderujący, tak więc pora się sprawdzić oraz jak to się mówi … Back to the Roots
Co zostanie użyte:
- język: Java/C++ graika: OpenGL, OpenGL 2.0 ES Shader language
- kompatybilność: Windows, Linux, Andoid, HTML5 na razie nie przewiduję bo eksport do GWT różnie mi działa.
- główny framework – libGdx oraz mojej komponenty używane w s3omm
- inne biblioteki wyjdą w praniu
- swing – do wykonania edytora pozwalającego na edycję parametrów komponentu oraz składania do kupy całości
- środowisko programistyczne: NetBeans, InteliJ
- oraz dużo kawy ……
4. Przydatne linki
- http://entity-systems.wikidot.com/
- http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
- http://gameprogrammingpatterns.com/
- http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
- http://www.richardlord.net/blog/why-use-an-entity-framework
- http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/
- http://www.gamedev.net/page/resources/_/technical/game-programming/understanding-component-entity-systems-r3013
- http://gamadu.com/artemis/tutorial.html
- http://www.ashframework.org/
Możliwość komentowania jest wyłączona.