MrJack pisze:twoj post byl wyjatkowo konstruktywny i pomocny, co chciales nim osiagnac?
Chcia³em ci nim zwróciæ uwagê na to, i¿ zanim zaczniesz my¶leæ nad detalami typu jak gracz ma wybraæ pomiêdzy walk± a badaniem obszaru, to jednak powiniene¶ po¶wiêciæ znacznie wiêcej czasu nad etapami nazywanymi w in¿ynierii programowania jako analiza i projektowanie, z naciskiem na to pierwsze. Interfejs u¿ytkownika jest du¿o pó¼niej.
Twój pierwszy post sugerowa³ mi, i¿ jeste¶ cz³owiekiem, który na przemy¶lenia nad tym tematem nie my¶la³ wiêcej ni¿ jeden dzieñ. Gdyby¶ po¶wiêci³ trochê wiêcej czasu na to, to dostrzeg³by¶ z³o¿ono¶æ problemu.
Ja równie¿ piszê co¶ takiego w MVS2005 i mam te czynno¶ci za sob±, wiêc rozwinê dla przyk³adu twój punkt 3. Tury podzieli³em na fazy, przed i po którymi sprawdzane i ew. wykonywane s± czynno¶ci dzia³aj±cych czarów czy kart zdarzeñ.
1. Przed wykonaniem ruchu musisz sprawdziæ czy gracz nie pomija kolejki.
2. Nastêpnie sprawdzasz ograniczenia i typ ruchu gracza - czyli to czy rzuca ko¶ci±, czy w inny sposób wykonuje ruch (ropucha, zamieæ, kraina wewnêtrza) - jesli uwzglêdniasz dodatki to jest jeszcze gorzej.
3. Sprawdzasz wp³yw innych graczy na ruch (przyk³adowo czar ''Zmylenie kierunku").
4. Okre¶lasz dostêpno¶æ pól (np. czar "Bariera").
5. W zale¿no¶ci od typu ruchu wykonujesz odpowiednio:
- rzut kostk± z uwzglêdnieniem modyfikatorów (Rumak, itp) lub
- wykonujesz teleportacjê do okre¶lonego (np. Gospoda->¦wi±tynia) lub wybranego przez gracza miejsca (ró¿nego rodzaju Anio³y itp) lub
- jeszcze inne przypadki.
6. Okre¶lasz mo¿liwe docelowe pola (nie wystarczy proste dodawanie z zawijaniem modulo - w grê wchodz± przechodzenie pomiêdzy krainami itp.)
7. Wykonujesz ruch - przesuwasz pionek przez kolejne pola sprawdzaj±c ich uwarunkowania (np. Stra¿nik przy przechodzeniu pomiêdzy Krainami Zewnêtrzn± a ¦rodkow±).
8. Po wykonaniu przesuniêcia sprawdzasz uwarunkowania pola docelowego.
9. W zale¿no¶ci od tych uwarunkowañ dajesz graczowi do wyboru badanie obszaru lub wybór innych graczy do ataku.
10. Przy ataku na gracza sprawdzasz mo¿liwo¶ci jego zaatakowania (zdolno¶ci graczy, czary, uwarunkowania itp).
11. Sprawdzasz mo¿liwo¶ci ucieczki i wymykania siê.
12. Itp. itd...
To tylko szkic, który pamiêtam (notatki mam w innym miejscu teraz), i dotyczy tylko
niektórych aspektów ruchu. Je¶li robiæ dodatki, to problem komplikuje siê znacznie bardziej (szczególnie dla tych nieoficjalnych).
Wracaj±c do meritum - przed programowaniem tak du¿ej gry
konieczne jest zrobienie analizy i jako takiego projektu - w przeciwnym razie skazany jeste¶ na pora¿kê lub w najlepszym razie s³aby i okrojony funkcjonalnie program.
To w³a¶nie mia³ na celu mój "wyjatkowo konstruktywny i pomocny" post - u¶wiadomienie ci tego. Nie porywaj siê z motyk± na s³oñce.
[quote="MrJack"]twoj post byl wyjatkowo konstruktywny i pomocny, co chciales nim osiagnac?[/quote]Chcia³em ci nim zwróciæ uwagê na to, i¿ zanim zaczniesz my¶leæ nad detalami typu jak gracz ma wybraæ pomiêdzy walk± a badaniem obszaru, to jednak powiniene¶ po¶wiêciæ znacznie wiêcej czasu nad etapami nazywanymi w in¿ynierii programowania jako analiza i projektowanie, z naciskiem na to pierwsze. Interfejs u¿ytkownika jest du¿o pó¼niej.
Twój pierwszy post sugerowa³ mi, i¿ jeste¶ cz³owiekiem, który na przemy¶lenia nad tym tematem nie my¶la³ wiêcej ni¿ jeden dzieñ. Gdyby¶ po¶wiêci³ trochê wiêcej czasu na to, to dostrzeg³by¶ z³o¿ono¶æ problemu.
Ja równie¿ piszê co¶ takiego w MVS2005 i mam te czynno¶ci za sob±, wiêc rozwinê dla przyk³adu twój punkt 3. Tury podzieli³em na fazy, przed i po którymi sprawdzane i ew. wykonywane s± czynno¶ci dzia³aj±cych czarów czy kart zdarzeñ.
1. Przed wykonaniem ruchu musisz sprawdziæ czy gracz nie pomija kolejki.
2. Nastêpnie sprawdzasz ograniczenia i typ ruchu gracza - czyli to czy rzuca ko¶ci±, czy w inny sposób wykonuje ruch (ropucha, zamieæ, kraina wewnêtrza) - jesli uwzglêdniasz dodatki to jest jeszcze gorzej.
3. Sprawdzasz wp³yw innych graczy na ruch (przyk³adowo czar ''Zmylenie kierunku").
4. Okre¶lasz dostêpno¶æ pól (np. czar "Bariera").
5. W zale¿no¶ci od typu ruchu wykonujesz odpowiednio:
- rzut kostk± z uwzglêdnieniem modyfikatorów (Rumak, itp) lub
- wykonujesz teleportacjê do okre¶lonego (np. Gospoda->¦wi±tynia) lub wybranego przez gracza miejsca (ró¿nego rodzaju Anio³y itp) lub
- jeszcze inne przypadki.
6. Okre¶lasz mo¿liwe docelowe pola (nie wystarczy proste dodawanie z zawijaniem modulo - w grê wchodz± przechodzenie pomiêdzy krainami itp.)
7. Wykonujesz ruch - przesuwasz pionek przez kolejne pola sprawdzaj±c ich uwarunkowania (np. Stra¿nik przy przechodzeniu pomiêdzy Krainami Zewnêtrzn± a ¦rodkow±).
8. Po wykonaniu przesuniêcia sprawdzasz uwarunkowania pola docelowego.
9. W zale¿no¶ci od tych uwarunkowañ dajesz graczowi do wyboru badanie obszaru lub wybór innych graczy do ataku.
10. Przy ataku na gracza sprawdzasz mo¿liwo¶ci jego zaatakowania (zdolno¶ci graczy, czary, uwarunkowania itp).
11. Sprawdzasz mo¿liwo¶ci ucieczki i wymykania siê.
12. Itp. itd...
To tylko szkic, który pamiêtam (notatki mam w innym miejscu teraz), i dotyczy tylko [u]niektórych[/u] aspektów ruchu. Je¶li robiæ dodatki, to problem komplikuje siê znacznie bardziej (szczególnie dla tych nieoficjalnych).
Wracaj±c do meritum - przed programowaniem tak du¿ej gry [u]konieczne[/u] jest zrobienie analizy i jako takiego projektu - w przeciwnym razie skazany jeste¶ na pora¿kê lub w najlepszym razie s³aby i okrojony funkcjonalnie program.
To w³a¶nie mia³ na celu mój "wyjatkowo konstruktywny i pomocny" post - u¶wiadomienie ci tego. Nie porywaj siê z motyk± na s³oñce.