Aplikacja w 48 godzin

Zakończył się tegoroczny Rails Rumble. Team Rubysfery ze wsparciem Piotrka Barczuka wziął w nim udział i nawet całkiem nieźle nam poszło.

Memoizr

Pomysłem, który postanowiliśmy zrealizować była gra Memory (chyba nie muszę nikomu pisać na czym ona polega). Główną atrakcją miało być za każdym razem nowy zestaw zdjęć, pobieranych z Flickra. Nie chcieliśmy robić kolejnego narzędzia do GTD, ani portalu społecznościowego dla hodowców mrówek. Ta gra choć też dostępna w wielu klonach, wydała nam się idealnym projektem do napisania w weekend przez trzy osoby.

Pracę zaczeliśmy w sobotę przed południem (na dzień dobry dostałem opieprz, że się spóźniłem). O pierwszej mieliśmy przygotowane środowisko produkcyjne i wyświetlaliśmy losowe obrazki z Flickra na stronie głównej. O trzeciej obrazki były zakryte i można było podać kategorię z jakiej miały być pobrane. Koło siódmej można już było zagrać w grę. Pojawiły się flickrowane napisy (te niebieskie z różową literką na końcu), a layout (nad którym pracował Czak) z grubsza przypominał to co jest teraz. Ponieważ plan minimum został wykonany, a każdy z nas ma trochę życia, ustaliliśmy, że spotkamy się jutro i udaliśmy się do domu.

Funkcją na której nam bardzo zależało był multiplayer, nie byliśmy jednak pewni czy uda nam się go zrobić drugiego dnia, czy lepiej się jednak skupić na dopieszczeniu tego co mamy. Ostatecznie postanowiliśmy spróbować pogodzić te rzeczy. Z pomocą przyszedł Omniauth, dzięki któremu w banalny sposób można zaimplementować logowanie z użyciem facebooka, twittera, open_id itp. Postanowiliśmy iść za ciosem i dodać nowatorskie logowanie przez facepalma.

Multiplayer zrobiliśmy w dość brutalny sposób. Gra przechowuje historię ruchów oraz id aktualnego gracza, i tylko jemu pozwala odkrywać karty. Wszyscy klienci odpytują serwer o aktualne ruchy i jeśli ich liczba się zmieniła to odsłaniają odpowiednie płytki i odblokowują odkrywanie nowych, jeśli jest akurat ich kolejka. Pierwsze, dość toporne gry udało się przeprowadzić koło 17. Mimo, że jeszcze wiele rzeczy nie działało, a ostylowana była tylko strona główna i tryb dla pojedynczego gracza, uznaliśmy, że do końca konkursu (u nas wypadał on o 2 w nocy) jesteśmy w stanie przygotować również multi.

Przed jedenastą udało się wyeliminować większość problemów i od tego czasu zajęliśmy się wygładzaniem naszej gry i jej intensywnym testowaniem. Ostatni bug poprawiliśmy dwadzieścia minut przed końcem czasu, zrobiliśmy deploya, otagowaliśmy odpowiednio repozytorium i odetchnęliśmy z ulgą.

Retrospekcja

  • 48 godzin dla kilkuosobowego zespołu to naprawdę dużo czasu – można zrobić dużo więcej niż proste hello world.
  • Z drugiej strony jeśli chce się dostarczyć coś dobrze działającego, to należy się skupić na najważniejszej funkcjonalności. Zadawanie sobie pytania „co jest esencją aplikacji?” bardzo pomaga.
  • Layout to podstawa. Aplikacja musi przede wszystkim dobrze wyglądać. Warto się skupić na dopieszczaniu istniejących funkcjonalności zamiast na dodawaniu nowych.
  • Warto wiedzieć co się chce zrobić. Nie byliśmy pewni czy robić multiplayer, dlatego w sobotę rozeszliśmy się stosunkowo wcześnie. Moglibyśmy zacząć nad nim pracę już w sobotę wieczorem i zostałoby nam więcej czasu na szlifowanie w niedzielę.
  • Nawet w małych projektach warto dbać o kod. Kilka razy zignorowałem zasadę DRY, myśląc że tak będzie szybciej. Nie było.
  • Jeśli tkwisz w ciągnącym się projekcie, warto się czasem oderwać i zrobić coś mniejszego. W jeden weekend można się naprawdę sporo nauczyć i odetchnąć od tego co mas się na co dzień.
  • Do multiplayera pewnie dobrze byłoby użyć socketów, ale należało o tym pomyśleć wcześniej. Jeśli zasoby są bardzo ograniczone, to nie ma czasu eksperymentować ze słabo poznanymi technologiami.
  • System ticketów się zawsze przydaje. My użyliśmy papierowych kartek, system elektroniczny dla takich projektów byłby nadmiarowy i mniej zabawny (zrobione zadania nabijaliśmy na szpikulec). Karteczki pomagały nam ogarnąć, jakie rzeczy są jeszcze do zrobienia i przypominały o rzeczach, które łatwo przeoczyć.

Konkurs

Z 300 zarejestrowanych ekip 192 udało się dostarczyć jakąś aplikację, a 24 najwyżej ocenione przez sędziów przeszły do finału. O ile oceny wystawione przez sędziów były bardzo dobre, faza głosowania zamieniła się w fotkę.pl dla aplikacji. Czyli wygrywa ten, kto znajdzie najwięcej osób dających tobie najwyższe, a pozostałym najniższe oceny. Dlatego mniej interesowało nas konkretne miejsce (uplasowaliśmy się na 19), a bardziej, to że dostaliśmy się do finału. Sporo pozytywnych komentarzy sprawia, że i tak jesteśmy zadowoleni z osiągniętego wyniku. Tutaj można zagrać w Memoizr’a.

Bawiliśmy się świetnie, a ja już nie mogę się doczekać kolejnej edycji.



Komentarze

  1. Seban 27.10.2010

    Comment Arrow

    Czy mieliście czas na pisanie testów czy je odpuściliście?


  2. tjeden 27.10.2010

    Comment Arrow

    Powinniśmy powiedzieć, że nie mieliśmy czasu nie pisać testów. 🙂

    Napisaliśmy kilka speców do samego modelu gry (różne warianty tworzenia gry, odkrywanie pól i zapisywanie, które są odkryte) i jeden spec na odkryty bug.

    Z testami integracyjnymi pewnie byśmy nie zdążyli. Z jednej strony funkcjonalności jest na tyle mało, że byliśmy w stanie wszystko przeklikać sami (i tak musieliśmy to robić żeby testować grywalność). Z drugiej strony duża część kodu, to javascript, a mimo capybary, nadal testowanie javascriptu może powodowować wiele problemów.


  3. kazjote 12.11.2010

    Comment Arrow

    Jak dla mnie gierka jest wypasiona 🙂


  4. apohllo 15.01.2011

    Comment Arrow

    Mulitplayer nie działa 🙁 wywala się przy logowaniu przez FB. Dałoby się to naprawić?


  5. tjeden 15.01.2011

    Comment Arrow

    Zapomniałem zmienić adresy w konfiguracji przy przenosinach na Heroku. Jutro pewnie da radę, teraz idę spać. 🙂 Dzięki za uwagę.


  6. tjeden 12.02.2011

    Comment Arrow

    Teraz działa.


  7. fidel 8.02.2011

    Comment Arrow

    Nie no, szacun Panowie!




Trackbacks


O autorze

Aleksander Dąbrowski

Od 2008 zawodowo programuje w Ruby i Railsach. Jest maniakiem prostych i eleganckich rozwiązań, nie boi się usuwania brzydkiego kodu. Uwielbia dzielić się wiedzą, a w wolnych chwilach naprawia samochody.