Denna veckan har jag fortsatt att jobba på vattnet. Mellan förra bloggposten och denna så har vi i gruppen fått ett fungerande vattenflöde, men vattenflödet skapades på spelarens position och hade ingen kollision. Det första jag gjorde var att skapa kollision mellan trädgårdsmästaren och hålen
på ovansidan. På bilden till höger kan man se hur hålen på ovansidan ser ut, ett av hålen är tomt och ett är fyllt med vatten som trädgårdsmästaren har fyllt på. Detta är det slutgiltiga resultatet. För att komma till detta resultatet så skapade jag kollision mellan trädgårdsmästaren och ett tomt hål, då byttes bilden till ett vattenfullt hål. Jag fixade också så att om vattnet kolliderade med ett tomt hål på undersidan så byttes spriten på ovansidan till ett vattenfyllt hål. Detta ifall spelaren skulle ha två hål som var länkade via tunnlar på undersidan.
Spelaren har ingen kollision med hålen på ovansidan, dem är bara där för att demonstrera att det är vatten i tunnlarna i underjorden. Däremot ska vattnet i tunnlarna ha kollision med spelaren. Detta var ett av de stora problemen jag hade den här veckan. För att gå igenom hur kollisionen med vattnet fungerade så måste jag först gå igenom hur vattnet fungerar. I kort så skapas en pixel på trädgårdsmästarens position när trädgårdsmästaren och hålet kolliderar. Denna pixel skapar sedan flera pixlar runt sig själv, då får vi en effekt av att de blåa pixlarna flyter i tunnlarna. Om ni vill läsa mer om hur vattnet fungerar så kan ni läsa om det här https://bergjens.wordpress.com/2015/02/26/update-3-on-project-mole-munch/.
När man ska skapa kollision mellan spelaren och vattnet så uppstår ett problem. Eftersom att vattnet inte är ett objekt utan bara är pixlar så går det inte att kolla på vattnets kollisionsbox. Istället kan vi använda oss av en teknik då vi kollar färgen på en bild. Det första som behövdes göra för att kunna använda denna tekniken var att skapa en bild av vattnets sprite. Detta var lätt att göra genom SFML’s funktioner. När detta var gjort så kunde vi använda den bilden för att kolla positioner och RGB värden. För att veta vattnets position så kollade vi vart på bilden som RGB värdet var det samma som vattnet. Till exempel om vattnets RGB var 128, 128, 255, så kunde vi kollade var på bilden som en pixel har det exakta RGB värdet. Sedan kollade vi positionen på spelaren och jämförde med positionen på bilden av vattnet. Om det var exakt samma position så fick vi resultatet sant och då kallades kollision. Just nu händer inget när de kolliderar, men vi ska lägga till en animation som spelar upp när mullvaden dör.
Såhär ser vattnet ut när man gräver i tunnlarna.
Game Design - Axel Vesterlund 
Kul, men vad jag förstår, klurig mekanik! Som grafiker kan jag inte till hundra procent relatera till problemet, men jag förstår ändå hindret i och med avsaknaden av kollisionsbox för vattnet. Av det jag såg på playtestingen och alphapresentationen verkade ert spel redan väldigt intressant. Tillägget av vatten och hur det ändrar dynamiken kommer bli kul att testa!
Du går igenom bakgrunden till problemet lagom detaljerat, tillräckligt för att man skall förstå fortsättningen men inte mer än nödvändigt. Du har strukturerat styckena i posten väl och håller dig till en röd tråd genom hela texten. Man kan även utan större förståelse för programmering ta till sig av informationen då du förklarat allt väldigt tydligt och undvikt programmeringsspecifika termer, vilket inte alltid är lätt. Det är väldigt intressant för en okunnig att få en inblick i hur programmeringen går till. Som läsare uppskattar jag också att du länkat till en mer detaljerad beskrivning av själva vattensimulationen för den som vill sätta sig in djupare.
Jag som grafiker kanske inte har väldigt mycket att hämta från denna information, men jag är övertygat om att en programmeringsintresserad kan ha stor nytta av hur du har gått till väga för att lösa problemet.
Väl skrivet!
GillaGilla