Generowanie sudokuNajwiększym (choć wcale nie tak dużym) wyzwaniem podczas robienia sudoku jest generowanie planszy. Musimy zadbać o to, żeby plansz było dużo, żeby były poprawne (i miały jedno, unikalne rozwiązanie) i żeby można było wybrać poziom trudności. Okazuje się, że rozwiązanie jest bardzo proste i powinno zadowolić każdego.
Jak więc wygląda to proste rozwiązanie? Weźmy dowolną planszę o odpowiednim poziomie trudności i przeróbmy ją tak, żeby wyglądała na unikalną. Gracze nie powinni zauważyć różnicy. Jeszcze tylko trochę terminologii -- grupami pionowymi (poziomymi) będę nazywał grupy trzech kolejnych kolumn (wierszy) na planszy. Mamy więc trzy grupy pionowe i trzy grupy poziome. Sposób w jaki należy przerabiać planszę:
Zatem planszę można przerobić na 609 499 054 080 sposobów. Sporo, prawda? Oczywiście nie wszystkie są unikalne (np. gdy plansza ma dwie puste kolumny), ale jest tego wystarczająco dużo. Łatwo zauważyć, że plansza będzie wciąż poprawna i poziom trudności zostanie zachowany. Teraz wystarczy dla każdego poziomu trudności przypożądkować kilka plansz 'startowych' i mamy kompletny system generowania sudoku. Pozostaje tylko jedno pytanie -- skąd wziąć plansze startowe i jak ocenić ich poziom trudności? W sieci można znaleźć różnego rodzaju strony, które rozwiązują sudoku, niektóre z nich podają też ocenę trudności. Pozwala to już na dość dobre zbudowanie bazy plansz 'startowych' i zapewnienie, że żadne z nich nie są izomorficzne ;)
Nie takie iPhone SDK straszne jak je malująWspomniałem ostatnio, że będę pisał więcej w związku z projektami nad którymi powoli pracuję. Na razie nie ma co pokazywać, więc postanowiłem napisać kilka słów o tym jak wygląda praca przy pisaniu czegoś na iPhone i ewentualnie dać jakieś drobne wskazówki.
To co może na samym początku przestraszyć to Objective-C. Na szczęście nie jest to problem, bo bardzo łatwo jest łączyć ten język z funkcjami pisanymi w C/C++. Przez to stanowi on tylko spoiwo między aplikacją (a przynajmniej w moim przypadku) a urządzeniem. W tej chwili większość kodu Objective-C w moim projekcie to szkielet aplikacji OpenGL ES dostarczany z xcode -- nie jest tego dużo i w żaden sposób nie przeszkadza w normalnej pracy. Jeżeli potrzebna jest jakaś funkcjonalność z systemu, w sieci można znaleźć gotowe kawałki kodu.
Do uruchomienia swojego kodu na iPhone przygotowywałem się już od jakiegoś czasu -- przeniosłem rendering z Direct3D do OpenGL ES 1.0 i zrobiłem spory refactoring. Gdy położyłem już swoje ręce na odpowiednim sprzęcie, uruchomienie na symulatorze zajęło jeden dzień. Po tym jak zapłaciłem za dostęp do programu developerskiego wystarczył jeden wieczór (spędzony na generowaniu certyfikatów), żeby uruchomić na sprzęcie. Spodziewałem się, że zajmie mi to więcej czasu, ale na szczęście poszło dość sprawnie -- w sumie nic dziwnego, bo na razie nie robiłem nic zaawansowanego.
Aktualnie projekt ściągnięty z repozytorium kompiluje się bez problemów pod xcode jak i w Visual Studio pod Windows. Zdecydowanie wolę pracę z tą drugą platformą i taka przenośność jest bardzo wygodna. Przydaje się implementacja OpenGL ES pod windows, żeby mieć pewność, że obejdzie się bez problemów.
Żeby nie było, że smęcę bez sensu i tylko korzystam z tego co znajdę gotowe w sieci, poniżej zamieszczam dwa kawałki kodu w dziwacznym języku, które mogą się komuś przydać. Nic odkrywczego, ale od czegoś trzeba zacząć ;)
// ukrycie górnej belki aplikacji, do użycia w widoku [[UIApplication sharedApplication] setStatusBarHidden:YES];
// pobranie nazwy katalogu, w którym znajdują się zasoby
const char* getResourcesPath()
{
NSString* path = [[NSBundle mainBundle] resourcePath];
return [path UTF8String];
}
Postanowienia noworoczneZ końcem każdego roku miałem postanowienie, że w kolejnym będzie lepiej. Jakoś nigdy nie miałem konkretnej listy celów, które chcę osiągnąć, więc ciężko oceniać czy rok był udany czy nie.
Żeby mieć się z czego za rok rozliczać, garść postanowień:
Nie jest tego za dużo, ale przynajmniej będzie można łatwo to zrealizować. Mam nadzieję, że taka deklaracja planów choć trochę mnie zmotywuje do ich realizacji ;)
Compo 3hW poprzedni weekend na warsztacie zostało zorganizowane trzygodzinne compo.
Jeszcze nigdy nie brałem udziału w tak krótkim pisaniu gry na czas, ale postanowiłem, że zobaczę co z tego wyjdzie. Ostatecznie zająłem 2 miejsce i jestem z tego zadowolony.
Gra (oczywiście niedokończona ;)), którą pisałem była klonem crimson landa i wypadła nienajgorzej. Całkiem ciekawe wydają mi się szczegóły techniczne, bo jadąc do domu na święta nie miałem dostępu do swojego kodu i pisałem kompletnie od zera:
Ciekawostką jest też to, że na procesorze C2D 1.8 GHz, użycie procesora według Menadżera zadań Windows nie przekracza 2%. Jak widać proste gry można spokojnie robić bez jakiejkowiek akceleracji ;)
Grę można zobaczyć tutaj.
Aktualizacja freedokuJest to pierwszy z wpisów o freedoku na moim blogu. Z czasem pojawi się tu ich więcej i choć głównie będą informować o aktualizacjach, pojawią się też takie, które będą opisywać rzeczy dziejące się pod maską.
Jeżeli ktoś znajdzie jakieś błędy, to proszę o napisanie w komentarzu lub na e-mail. Miłego grania.
Deferred shadingDeferred shading jest coraz popularniejszą techniką oświetlenia. Idea jest bardzo prosta i wydaje się łatwa w implementacji. Szukając informacji na jej temat zebrałem odnośniki do kilku artykułów i postanowiłem się nimi podzielić:
Jak widać jest tego sporo i możemy zobaczyć jak to robią inni zanim zabierzemy się do implementacji.
Casual Games HarmonyChariboeta-mmarshenNetrixRegeditSell More GamesTomasz DąbrowskiWojciech TomanWachuXion
revo 2005-2010, wszelkie prawa zastrzeżone, w użyciu trochę silk icons, a pod maską CodeIgniter (generation time: 0.0389s)
