Pokibicuje za to innym uczestnikom i jak nie zapomnę to napiszę po zakończeniu głosowania na kogo swój głos oddałem – albo i nie napisze ;p

Kontynuując, chciałem w miarę oficjalnie przedstawić obiekty które znajdą się na diagramie UML (tzn. już się znajdują, ale na razie jest za biedny więc nie przedstawię go póki co).

• Surowiec (wyprodukowane i wydobyte)
• Zasoby naturalne
• Jednostka (lądowe i wodne)
• Budynek (podzielę prawdopodobnie na produkujące i wydobywające – tak więc budynek będzie Abstract)

I to by było na tyle jeśli chodzi o większą część logiki – która będzie wsparta dodatkowo przez skrypty. Dodatkowo będzie wykorzystana biblioteka GUI którą myślę, że już wybrałem ale póki co nie będę pisał która, ale wydaje się z bibliotek podanych w TYM wątku.

Pozostaje jeszcze opcja terenu, nad którym sobie powoli pracuje, ale przyznam szczerze, że męczy mnie ta pogoda więc wlecze to się jak ślimak, ale niemal na pewno wykorzystam mapy wysokości bo gra nie wymaga jakiś specjalnych formacji skalnych – a jeżeli już będę je chciał, to zapakuje się jako model, większym wyzwaniem za to będzie stworzenie naturalnie wyglądającego terenu – rzeki i takie tam, na szczęście podczas poszukiwań materiałów do pracy inż. (którą obroniłem jakiś czas temu ) natknąłem się na ciekawy artykuł z generowania formacji skalnych który postaram się ogarnąć.

Lecimy dalej, bez QuadTree i LOD się nie obejdzie, ale sam tego implementować nie będę, wykorzystam jedną z udostępnionych implementacji i myślę, że gra na tym lepiej wyjdzie.

Jak wymieniłem wcześniej, będę chciał wykorzystać jakiś język skryptowy aby przenieść zachowanie graczy komputerowych z kodu gry do poszczególnych skryptów – nie wiem jaki to będzie język, możliwe że lua która z tego co się orientuje jest dosyć popularna w tej dziedzinie i kiedyś natknąłem się nawet na bibliotekę do XNA wykorzystującą(interpretującą) Lua.

Pominąłem na liście takie rzeczy jak klasa reprezentująca gracza, ale to dosyć oczywiste, że takie coś będzie – skupiłem się na podstawach gry, które mają 4 (Cztery!) klasy co się wydaje podejrzanie mało, wliczając klasy pochodne co prawda będzie ich 10 – więc jeśli ktoś chciałby dorzucić swoje 3grosze to proszę, mi się tak naprawdę nie spieszy, nie traktuje tego jak wyścig czy coś, ale fundamenty mógłbym zacząć już stawiać bazując na tym co teraz mam, potem ciężko będzie o większe zmiany.

W każdym razie, Surowiec i produkt może być jedną klasą, Zasób prawdopodobnie zostanie potraktowany indywidualnie ze względu na konieczność umiejscowienia go gdzieś na mapie i nie widzę sensu dodatkowo rozpoznawać flagi czy to czasem nie surowiec/produkt. Wszystkie dane dotyczące gry będą trzymane w bazie, więc:

Tabela: Good

Pola:

1. GoodsID : ID będzie używane choćby po to aby wiedzieć jakich składników potrzebuje dany produkt.
2. Name: nazwa produktu/surowca. Prawdopodobnie użyje również jej do ładowania odpowiednich tekstur
3. Value: Wartość danego produktu – na potrzeby handlu, zastanawiam się jeszcze nad min i max przy której gracze komputerowi byliby skłonni sprzedawać swoje i kupować nasze.
4. BuildingID : ID budynku wydobywającego lub produkującego dane dobro
5. ProductionTime: Czas jaki zajmuje wydobycie/wyprodukowanie jednej jednostki danego dobra.
6. Typ: Product/Subproduct/Surowiec – tylko dla stworznei awygodniejszego interfejsu (pogrupowanie)
7. Typ2: Cywilne/Militarne – j.w
8. DayConsumptionPerCitizen: konsumpcja danego dobra na mieszkańca, podawana na dzień. pewnie coś w okolicach 0.0002   [jednostką towaru będzie 1tona]

Tabela: ProductComponets:

1. GoodsID: ID dobra dla którego jest potrzebny jest dany zasób
2. ComponentID : ID potrzebnego zasobu/produktu/subproduktu
3. Consumption: Ile zużywa danego dobra dla stworzenia nowego produktu.  (float)

ProductComponents nie ma żadnego indexu, uznałem go za zbędny – żeby pobrać potrzebne surowce będzie trzeba pobrać wszystkie wiersze w których zgadza się GoodsID produktu z GoodsID ProductComponents.

Pozostaje jeszcze tabela dla  budynków i wojska, przede wszystkim będą tam koszty wybudowania/rekrutowania, potrzebne surowce i koszty jakie będzie trzeba ponieść każdego miesiąca. Żołnierz dodatkowo będzie miał informacje nt. siły ataku, zadawanych obrażeń, obrony, punków życia (ale to nie RPG, ranny żołnierz się na dużo nie zda), oraz informacje nt. levelowania (możliwe bonusy), progi doświadczenia.

Prace się trochę wloką, w sporej części przez mało przyjazny klimat – ja strasznie marudny i wybredny jestem, a te słońce mnie zabija no i sporo energii poświęcam na pracę

Przez weekend może posiedzę nad terenem który w końcu w grze musi być i coś skrobnę na ten temat, ale trzeba zrobić zakupy, pojechać nad morze skoro już mieszkam w Gdańsku od ponad miesiąca i koniec końców mogę nie mieć sił – więc skrobnę coś nt. UI a teren zostawię na później.

1. Visual Studio 2008 Proffesional, mimo, że posiadam wersje 2010 zdecydowałem się na wykorzystanie 2010 główne ze względu lepszej płynności działania (2GB Ramu to na 2010 jednak za mało)
2. SQLite.NET – wrapper na sqlite z którym miałem już do czynienia przy projektach aplikacji
3. Visual Paradigm for UML w wersji 7.2  Community Edition do stworzenia diagramów UML, ile ich będzie wyjdzie w praniu, ale nie mal na pewno diagram klas i diagram stanów.
4. SQLite Expert Personal Edition do stworzenia bazy danych, przy czym może się zmienić bo póki co sprawdzałem tylko wersje Proffesional, co oferuje Personal nie wiem (jakiś problem ze ściągnięciem jej jest)
5. TortoiseSVN który wiadomo do czego służy, alternatywą może być wtyczka AnkhSVN do Visuala
6. GoogleDocs na którym w chwili obecnej powstaje DesignDoc gry i jak energia dopisze niedługo przedstawię jego podstawową zawartość.

Jeśli chodzi o zarys ‘fabuły’ która nie będzie wybitnie rozbudowana – nie ten typ gry, zastanawiam się nad skorzystaniem z idei która przewinęła się przez Settlersy czy Anno polegająca na zakładaniu nowych osad/miast na niezasiedlonych terenach, albo odbudowa królestwa – co by wymagało pewnej ilości ruin pozostałych po ostatniej wojnie – albo połączenie obydwóch rzeczy. Wcielając gracza w rolę charyzmatycznego szlachcica/księcia/chłopa (wybór mógłby dawać pewne plusy i minusy w niektórych aspektach gry) który obejmie przywództwo nad uciekinierami z królestwa objętego wojną i zorganizuje budowę osady, żeby zebrać siły i stworzyć armie do odbicia utraconego zamku – myślę że to dobry początek dla kampanii

Jeśli chodzi o sam projekt to będzie to gra, strategiczno ekonomiczna – oczywiście w XNA 3.1. Od dawna chciałem się zabrać za coś takiego i mam nadzieje, że po zakończeniu konkursu znajdzie się parę osób które pomoże w jej rozwoju bo w planach jest kontynuowanie projektu w większym gronie.

Notki związane z konkursem będę publikował z tagiem „Konkurs-DajSiePoznac”

Non-members may check out a read-only working copy anonymously over HTTP.
svn checkout http://geniusofmyself.googlecode.com/svn/trunk/

Jeszcze kilka słów o konkursie, na chwile obecną bierze w nim udział 33 ‘rywali’ (plus ja) [i ciągle się zwiększa] – ich strony i projekty można znaleźć na stronie uczestników konkursu i polecam również śledzenie ich blogów i sam oczywiście będę ich szpiegował – dla leniwych (czyli m. in. mnie) Gutek stworzył odpowiednik DotNetBlogs dla uczestników konkursu – pod adresem DotNetBlogs.DajSiePoznac.

Rejestracja w konkursie otwarta jest do 15go sierpnia, więc zapraszam do rejestracji – będzie to niewątpliwie całkiem dobra reklama swojej osoby, nawet jeżeli nie wygra się niczego – a obserwatorów proszę o spojrzenie przychylnym okiem na moje wypociny bo to od was zależy kto wygra

Konkurs – „Daj się poznać”

Może będzie to też jakaś motywacja do częstszego pisania, ale jak człowiek wraca o 18stej do domu to ciężko będzie. W każdym razie polecam

„Zdefiniowac vector wskaznikow na zwierzatka, wrzucic tam pare kotkow i pieskow. Dalej przechodzimy po wektorze wykonujac polimorficzny call i zwierzatka daja glos (wypas ). Najlepszy foreach z boost::bind, potem jakis ptr_fun, potem iteratory (czy beda const? ) a potem zwykly for (ostatecznie).”

Zadanie zostało zadane przez p. Przemysława, ja trochę to sobie przeredagowałem i zamiast tablicy, dorzuciłem Właścicieli, jeden z kotkiem, drugi z Pieskiem, trzeci bez zwierzaka – koniec końców wygląda to tak: http://ideone.com/PI1KD [tylko mała uwaga, rozwydrzyłem się C# i zapomniałem o destruktorze wirtualnym - co zresztą szybko zostało mi wypomniane ;-) ].

Przykład wykorzystuje właśnie wzorzec Strategii, pozwalając tworzyć nowe zwierzątka i nowych (obiektów) właścicieli bez ingerencji w kod Zwierzaka (klasy abstrakcyjnej) ani Właściciela [no chyba, że dodamy nową komendę.

Przez następne kilka stron, przewijały się pytania bardziej techniczno-kruczkowe, które chyba i tak nie przebiło walki z kulkami – na blogu pisałem o pytaniu na rozmowie kwalifikacyjnej ponoć w google – ale, oczywiście takie pytania są rozkładane w dwie minuty, ciekawsze zadanie dotyczyło 12stu kulek, w której jedna jest INNA, nie wiadomo czy cięższa czy lżejsza – mamy to ustalić sami w 3 ważeniach, to która jest INNA i czy jest cięższa czy lżejsza – przyznaje, że póki co pomysłu nie mam.

No i, pytanie do którego użyłem wzorca Dekorator – trochę na wyrost, ale  chodziło o przykład i ‘utrwalenie’. Nikt nie pisał, że źle, to może dobrze napisane – pytanie zadane przez p. Macieja

„Jak byś zaimplementował(a) zamalowany, a jak pusty romb z diagramu UML? ”

Przykład jest o TUTAJ, no i mam skromną nadzieje, że nie machnąłem się tutaj. Szczerze powiedziawszy, nie jestem zwolennikiem Dekoratora, ale jak to wzorce powinny robić dodanie w tym momencie nowej figury, albo nawet dodanie ‘dziurki’ do figury ogranicza się do stworzenia jednej klasy, bez modyfikowania już stworzonych i odpowiednim skonstruowaniu obiektu: WypelnionyRombZDziurka = new FiguraZDziurka(new WypelnionaFigura(new Romb(new Figura()))) – co prawda wygląda to dziwnie, ale efekt powinien wyglądać tak:
Rysuj Figure typu: Romb i ja wypelnij i zrób dziurkę”

//Edit:

Oczywiście, zapomniałem o definicji, z lenistwa posłużę się tłumaczeniem z Head First Design Patterns:

„Wzorzec Dekorator pozwala na dynamiczne przydzielanie danemu obiektowi nowych zachowań. Dekoratory dają elastyczność podobną do tej, jaką daje dziedziczenie, oferując jednak w zamian znacznie rozszerzoną funkcjonalność”.

//~EDIT

Jak ktoś chce się ‘sprawdzić’ to polecam mycppquiz (chyba podawałem kiedyś?), albo wątki odnośnie zagadek, które przewijają się przez różne fora, dla przykładu wątek „Zagadki językoznawcze” na forum warsztatu.

No i, jeżeli kogoś to jakimś cudem interesuje – piszę trochę mniej, bo po pierwsze widać jak mi to wychodzi, a po drugie męczę się z projektem edytora terenu (edytor cząsteczek był do niego wstępem) – jeszcze kilka podejść i może pokaże efekt końcowy (ten nawet działa, ale nie powiem, żebym był zadowolony).

Na początek zacznę od wzorca strategii, jest to zdecydowanie jeden z prostszych i upiększających kod wzorców, z jakiś powodów też został wybrany jako pierwszy przez autorów „Head First Design Patterns”. Dodatkowymi atutami przemawiającymi, żeby omówić akurat ten wzorzec, jest fakt, że w bardzo fajny sposób pokazuje, że interfejsy są przydatne, co dla początkujących programistów, aż tak oczywiste nie jest – wiem z doświadczenia [no i czasami przez różne fora, czy Q&A przewija się pytanie po co to jest, dla przykładu: Po co to wszystko - devPytania? - gdzie opisałem błąd który popełniłem przy projektowaniu systemu cząsteczkowego]

Więc, zacznijmy od celu, popełnionego błędu, a potem przejdziemy do ładniejszego rozwiązania i jego korzyści. (jeżeli ktoś przejrzał moją odpowiedź w ‘po co to wszystko’ to historyjkę teoretycznie może sobie odpuścić, bo tam już ją opisałem.

Cel:

Cząsteczki miały mieć różne sposoby obliczania ich wartości, tj. kolor, skala, kierunek, prędkość itp. Początkowo były to ‘static’ – czyli nic się nie zmieniało,’random – wartość była losowana, raz, na początku życia cząsteczki z podanego przedziału oraz ‘linear’ w którym wartość była zmieniana od wartości początkowej, do wartości końcowej względem czasu jaki minął od momentu jej ‘narodzin’.

Błędne rozwiązanie:

Początkowo, stwierdziłem, że wystarczy stworzyć enum z wartościami ‘static’, ‘linear’, ‘random’. Rozwiązanie to ułatwiało mi stworzenie edytora, w którym PropetyGrid dokładnie wiedział jakie są wartości tego enuma i wystarczyło je tylko wybrać. Problem jednak leżał w ogromnej zależności cząsteczki od całej reszty systemu. Na początek musiałem sprawdzić, czy cząsteczka jest ‘losowa’ w momencie jej narodzin, potem w trakcie aktualizacji musiałem sprawdzić jak przypisać nową wartość, czy jest liniowa, czy stała lub losowa (bo te się też nie zmieniały) i chyba jeszcze gdzieś musiałem sprawdzać typ obliczania jakiejś wartości, a że ich trochę było ilość ifów była całkiem spora. Dodatnie w tym wypadku nowej klasy, która miała obliczać nową wartość, zmuszało mnie do wprowadzenia zmian w kilku miejscach, co aż się prosi o błędy, nawet w tak małym ‘systemie’. Więc trzeba było to zmienić

Rozwiązanie z użyciem wzorca Strategii:

Czym w ogóle jest ten wzorzec? angielska wikipedia mówi coś takiego:

The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable.

===

Wzorzec strategii jest użyteczny w sytuacjach kiedy niezbędna jest możliwość zmiany algorytmu podczas działania aplikacji. Wzorzec strategii ma zapewnić środki do stworzenia rodziny algorytmów, ‘zakapsułkować’  każdy jako obiekt i stworzenie ich ‘zamiennymi’

Polska wiki też coś mówi, ale ta definicja jest o wiele bardziej zrozumiała (to pod spodem to moje tłumaczenie, ale ja w tym dobry nie jestem )

Teraz popatrzmy chwile na cel, jak widać każda cząsteczka ma zbiór wartości – każda z tych wartości jest obliczana przez jakiś ‘algorytm’ – no i wszystko pięknie pasuje.

  public interface IColorBehavior
    {
        void Calculate(float lifePercent);
    }

Dla przykładu, przedstawiłem interfejs dla algorytmu obliczającego wartość koloru, teraz wystarczy, że stworzy klasy które go implementują i w klasie emittera dam możliwość zmiany klasy która implementuje dany algorytm. (równie dobrze, można stworzyć IBehavior, bo każda wartość dostaje te same dane, ale ktoś złośliwie mógłby przypisać wtedy StaticScaleBehavior dla przykładu, dla czegoś co na logikę powinno za kolor odpowiadać)

Zalety:

Dodanie nowego algorytmu do obliczania danej wartości cząsteczki polega tylko na jego stworzeniu, żadnych zmian w  kodzie popełniać nie musimy. – myślę, że ta zaleta jest całkiem spora

Jest jeszcze jedna zaleta, takie podejście umożliwiło mi stworzenie ‘wtyczek’ z nowymi algorytmami, w prosty sposób – przy dodawaniu dll, z pomocą System.Reflections pobierałem wszystkie obiekty które implementują dany interfejs i dodawałem je do ‘repozytorium’ – ot, taki ‘zarządzany’ bajer

Warto zajrzeć:

http://sourcemaking.com/

Microsoft oczywiście wyposażył VS w całkiem sporą ilość snippetów, które mogą się przydać, ale jak komuś mało, można w całkiem szybki sposób stworzyć nowy snippet, przyspieszający pracę. Który poza wklejeniem kawałka kodu, może np. dodatkowo dołączać referencje.

Edit: J. „Gutek” Gutkowski podesłał Snippet Designer

Podsumowanie:

Wpisujemy interesujący nas snippet, dla przykładu for i wciskamy dwa razy TAB. VS wygeneruje nam taki kod:

Zmiana nazwy iteratora, który jest teraz zaznaczony na niebiesko, automatycznie zmieni elementy podświetlone na szaro. Po wciśnięciu TAB przeskakujemy do następnego elementu, tutaj zaznaczonego na pomarańczowo length. Kolejne wciśnięcie TAB przejdzie do następnego elementu, o ile ten występuje, w przeciwnym razie wracamy do pierwszego, czyli i. Jak już wklepaliśmy co chcieliśmy, pozostaje nam tylko kliknąć ENTER i zostać przeniesionym do wnętrza pętli.

Nie jest to co prawda nic nadzwyczajnego, ale pozwala oszczędzić czas i dłonie – sięganie po myszkę, albo skakanie ‘strzałkami’ do najwygodniejszych rzeczy nie należy

Nie będę nikogo oszukiwał, nie będzie tutaj wybitnie zaawansowanych rzeczy, ot takie krótkie podsumowanie tego co się pierwsze nawinęło ;->

Named & Optional Parametrs - co można tłumaczyć jako, opcjonalne(domyślne) parametry, oraz parametry nazwane. Osobiście trochę mi brakowało parametrów domyślnych, ale ‘named’ to jest faktycznie, ficzer, ale może być całkiem przydatny, szczególnie razem z parametrami domyślnymi.

        void Named(int A, int B)
        {
            Console.WriteLine("A: {0}, B: {1}", A, B);
        }

        void Optional(String str = "Default")
        {
            Console.WriteLine(str);
        }

        void NamedAndOptional(String A = "A!", String B = "B!", String C = "C!")
        {
            Console.WriteLine("A: {0}, B: {1}, C: {2}", A, B, C);
        }

// no i wywołanie, w odpowiednim miejscu oczywiście - sugeruje konstruktor klasy Main (czy jak tam sobie nazwicie)
             NamedArguments(B: 10, A: 5);
             OptionalArguments();
             NamedAndOptionalArguments(C: "Ce!");

Jak widać, wystarczyło podać argument który chcieliśmy wykorzystać, zamiast podawać A i B, z ich domyślnymi wartościami – coby dokopać się do C. Co zresztą, jest pokazane na MSDN w How To Use Named and Optional Arguments in Office Programming

Kolejnym ‘ficzerem’ jest Dynamic Type, które nie da się ukryć, muszę rozgryźć, ale ze świata docierają głosy, że świetnie nadaje się do System.Reflections. I bazując, na przykładzie podanym przez p. Macieja skrobnąłem coś innego, ale nie jakiegoś strasznie innowacyjnego w porównaniu do ‘podstawy’

       class DynamicExample
        {
            public void method()
            {
                Console.WriteLine(this.GetType().Name);
            }
        }

        public Main()
        {
            Object o = Activator.CreateInstance(typeof(DynamicExample));
            dynamic dynamicO = o;
            //o.method(); // z wiadomych przyczyn nie działa.
            dynamicO.method();

        }

Magia polega na tym, że to czy można wywołać method czy nie odbywa się w czasie działania programu „run-time” – słów kilka od MSDN znajduje się np. TUTAJ. Oczywiście, z wiadomych przyczyn pozbawia nas to InteliSense, ale jakoś się to przeżyje. W każdym razie, pozwala to upiększyć kod, oraz,

Walkthrough: Creating and Using Dynamic Objects

Expando Object pozwala dodawać i usuwać członków z instancji obiektu podczas działania programu. Pozwala również odwoływać się do nich, w taki sam sposób jak w przypadku Dynamic, zamiast sampleObject.GetAttribute(„sampleMember”)

           dynamic expando = new System.Dynamic.ExpandoObject();
            expando.A = 10;
            dynamic AnotherExpando = new System.Dynamic.ExpandoObject();
            Console.WriteLine(expando.A);
            //Console.WriteLine(AnotherExpando.A); //runtime exception
            expando.Increment = (Action)(() => { expando.A++; });
            Console.WriteLine(expando.A);
            expando.Increment();
            Console.WriteLine(expando.A);

Słów kilka, znajdziemy oczywiście na MSDN, tym razem o! TUTAJ, np. jak usunąć argument.

Na razie tyle, pobuszuje sobie jeszcze trochę i coś może dopiszę