Vandaag heb ik de eerste beta versie van m'n iPhone app verzonden naar enkele testers. Een onafgewerkte app kan je (uiteraard) niet via de App Store verspreiden dus heb ik dit gedaan via de Ad Hoc distributie methode. Dit houdt in dat ik naar een tester een .app bestand stuur dat de applicatie zelf is en een .mobileprovisioning bestand dat aan één of meerdere toestellen toestemming geeft om de applicatie te installeren.

Ik had op voorhand al een vermoeden dat dit miserie ging worden en dit bleek deels terecht te zijn. Het was niet zo erg als ik had verwacht maar toch ben ik twee problemen tegengekomen.

iTunes artwork

Opdat het icoon van je app in iTunes zichtbaar zou zijn moet je in Xcode bij de resources van je app het logo in groot formaat (512 op 512 pixels) toevoegen. Dit bestand moet "iTunesArtwork" heten, zonder extensie dus. Niet moeilijk, maar dit staat niet vermeld in de handleiding.

Handtekening van het programma ongeldig

Voor ik de app opstuurde naar alle testers heb ik de Ad Hoc distributie met één persoon getest. Die kreeg deze foutmelding bij het synchroniseren: "Het programma rush hour is niet op de ipod touch geünstalleerd, omdat de handtekening van het programma niet geldig is". Dat was vreemd omdat ik wel alle stappen uit de handleiding van Apple's developer portaal had gevolgd en ad hoc distributie bij een eerdere alpha versie wel had gewerkt. Uiteindelijk bleek ik inderdaad niets mis gedaan te hebben maar was Xcode verward door het werken met allerlei verschillende provisioning profiles. De oplossing staat stap voor stap uitgelegd in deze blogpost.

Na deze twee problemen opgelost te hebben is de beta test dus begonnen en zal ik hopelijk binnenkort veel informatieve feedback krijgen :)

Dit is slechts een teaser, meer info over het spel zelf verschijnt binnenkort :)

Rush Hour is een werktitel.

Het is weeral lang geleden dat ik hier iets heb geschreven. Dat betekent echter niet dat ik heel de tijd stil heb gezeten!

In het eerste trimester van de 2e Bachelor ICT heb ik een redelijk groot project gemaakt: een computer versie van Monopoly. Als ik eens wat tijd heb zal ik hier een Windows en Mac versie van posten. Het Monoply spel werkt trouwens ook op Linux, dat allemaal dankzij Qt. Dit is een multiplatform framework dat we - het project werd gemaakt in een team van twee - in combinatie met CPP gebruikt hebben om het spel te realiseren.

Spijtige aan het project was de beperkte creatieve inbreng. Iedereen maakte een Monopoly spel en dat was het. Dat zit natuurlijk compleet ander bij m'n iPhone app! De laatste weken heb ik me vooral beziggehouden met het oplossen van bugs en usability verbeteringen. Het todo-lijstje wordt steeds korter en dus zal ik de nabije toekomst beginnen met een beta test periode. Hiervoor heb ik een bugtracking systeem opgezet met behulp van FlySpray. Je mag me trouwens altijd iets laten weten als je wil beta testen.

Enigste wat nog ontbreekt zijn mooie graphics, maar dat komt zeker nog in orde. Helaas houdt dat me voorlopig nog tegen om screenshots te posten...

De nederlandstalige iPhone website iphoneclub.nl organiseerde onlangs een usermeeting in Amsterdam. Zelf was ik daar niet aanwezig, maar via de website ontdekte ik dat er enkele developers interessante presentaties gegeven hebben.

Op deze pagina kan je alle presentaties bekijken. Hieronder vind je de naar mijn mening meest interessante, welke gaat over het proces van een iPhone app maken en het belang van een goed design. Ondanks dat de slides "gestolen" zijn van Apple zeker de moeite om eens te bekijken:

Aan m'n eigen iPhone app werk ik ondertussen rustig voort, zei het door de start van het academiejaar helaas een stuk trager. Ik ben blij dat ik deze week ondanks al het andere werk toch nog enkele belangrijke bugs heb kunnen verhelpen en dat ik de workflow van een onderdeel heb kunnen verbeteren (over dit "onderdeel" binnenkort meer).

Vandaag ben ik aan het experimenteren geweest met een nieuw onderdeel voor m'n game. Eén van de problemen die ik moest oplossen was het halen van data (gewoon tekst) uit een webpagina om deze vervolgens te kunnen verwerken.

Het plan was om een speciaal hiervoor aangemaakte php webpagina op m'n server te draaien en de inhoud hiervan naar binnen te halen. Ik verwachte dat dit massaal veel werk zou zijn, maar het was twee regels code. Twee. Zalig : )

NSURL *url =[NSURL URLWithString: @"http://www.website.be/iphone.php"];
NSString *webcontent = [NSString stringWithContentsOfURL:url];

Deze twee regels code openen een wereld van mogelijkheden, waar ik hopelijk binnenkort meer over kan vertellen (wie weet welke onmogelijke problemen er nog optreden).

De laatste dagen heb ik me bezig gehouden met het ontwerpen van levels voor m'n iPhone game.

Level design is niet alleen leuk om te doen maar is ook essentieel voor een goede game. Meestal begin ik met een schets van een 'concept': een constructie van level elementen dat een leuk level zou moeten opleveren. Door dit uit te tekenen perfectioneer ik dit concept en breid ik het uit indien het te klein was om een volledig level rond te bouwen. Ik probeer steeds op zoek te gaan naar onverwachte constructies, complexe constructies of constructies die net eenvoudig en complex tegelijk zijn. Alle levels zijn uitspeelbaar, maar bij vele zal het niet alleen snelle reflexen maar ook goed denkwerk vereisen!

Op de foto hierboven zie je - niet onverwachts - enkele schetsen van levels, alsook enkele schetsen van de interface van de game. Momenteel bevat de game 26 levels en dat moeten er minstens het dubbele worden. Ik heb dus nog wat werk te doen!

Het is alweer even geleden dat ik nog over m'n iPhone app project geschreven heb, dus bij deze!

Daar het basisconcept al geruime tijd zo goed als af is heb ik me voornamelijk bezig gehouden met allerlei onderdelen die niet zo direct te maken hebben met de gameplay zelf. Zo heb ik bijvoorbeeld het about scherm grafisch mooier gemaakt en er statistieken aan toegevoegd. De statistieken geven onder andere aan hoe ver je in het spel bent gekomen en hoeveel keer je al een level verloren hebt.

Ik heb ook de Level Designer applicatie (zie deze blogpost) verbeterd zodat ik sneller levels kan maken en ik ook makkelijker met levels kan schuiven (dit laatste komt voornamelijk door beter geschreven code). Als ik bijvoorbeeld vind dat level 6 en level 7 beter verwisseld zouden worden dan gaat dat nu heel eenvoudig.

Nog een belangrijke toevoeging is dat m'n app nu verschillende talen ondersteund. Een Fransman zal de app dus in het Frans te zien krijgen en een Engelsman in het Engels. Hier ben ik heel blij om, ik verwachtte dat dit heel wat programmeer werk zou vereisen, maar dat was absoluut niet het geval. De iPhone SDK is toch echt een zeer knap stukje techniek!

Naast deze grote toevoegingen heb ik uiteraard ook nog een berg kleine verbeteringen en bug fixes toegevoegd. En easter eggs : )

Tot slot nog een link naar een interessante blogpost over Android Market vs iPhone App Store. De belangrijkste conclusie is dat de Android Market bijna niets voorsteld in vergelijking met de App Store. Hier was ik zelf wel wat van geschrokken: ik wist dat de iPhone veruit het meest gebruikte mobiele applicaties platform is maar dat het verschil zo groot was had ik niet gedacht. Toch geloof ik dat de Android Market in de toekomst wel succesvoller zal worden (enkele manieren waarop dat zou kunnen gebeuren kan je lezen in de blogpost). De schrijvers hebben trouwens nog een follow-up blogpost geschreven.

Ik ben de afgelopen dagen weer volop bezig geweest met m'n iPhone app. Ik begin het werken met de iPhone SDK stilaan goed in de vingers te krijgen. Zo hoef ik me niet meer te concentreren op hoe ik iets ga maken maar op wat ik ga maken.

Ik heb de laatste dagen gezorgd voor opslag van vooruitgang en level-tijden, een timer om level-tijden te bepalen en nog veel andere, kleine, toevoegingen. Technisch gezien is m'n app nu zeer ver gevorderd. Ik ga me de komende dagen nog bezig houden met het verbeteren van de workflow, grafische verbeteringen (geen standaard pop-up berichten bijvoorbeeld) en een systeem om opties in te stellen.

Daarna resten me nog twee dingen: het level design en graphics. Level design doe ik graag en gaat natuurlijk heel vlot met m'n Level Designer (zie vorige blogpost) maar het maken van graphics is een ander verhaal. Ik kan wel wat overweg met Photoshop, maar echte game graphics maken is toch nog iets te moeilijk. Een eerste manier om graphics te vinden is via iStock Photo. Dit is een website met een gigantisch aanbod van allerlei soorten afbeeldingen die je kan kopen voor een paar euro. Hier zal ik zeker wat bruikbaars kunnen vinden.

Voor elementen waarvoor ik geen afbeelding vindt op iStock Photo en voor bepaalde belangrijke elementen zal ik speciaal voor m'n app gemaakte graphics nodig hebben. Ik ken gelukkig wel een paar mensen die hiervoor kunnen zorgen dus normaal komt dit wel in orde : ).

Tot slot heb ik nog m'n app in één zin samengevat:

Een snel, dynamisch behendigheidsspel met veel aandacht voor level design

Dit kan echter nog volledig veranderen ; )

De laatste dagen heb ik goed kunnen doorwerken aan m'n iPhone app waardoor de "game engine" nu grotendeels af is. De game engine is zeg maar de onderliggende basis waarmee levels gebouwd kunnen worden (en correct kunnen werken). Een probleem waar ik vandaag op stuitte was het ontwerpen van levels. Een level dient namelijk volledig in programmeercode ingegeven te worden. Nadat ik op papier een schets gemaakt heb zou ik dus voor elk element een stukje code moeten schrijven. Dat is op zich al lastig, maar het wordt helemaal lastig om later nog iets aan te passen.

Een ideale oplossing zou zijn om een level grafisch te kunnen ontwerpen via een speciale applicatie. Dat is dan ook precies wat ik gemaakt heb! Met de applicatie kan ik grafisch een level ontwerpen en vervolgens met een druk op de knop de bijbehorende programmacode genereren. Dit werkt een stuk handiger én sneller :)

Verder heb ik nog heel veel zitten sleutelen aan de besturing. Het probleem was namelijk dat mijn app een zeer precieze besturing vereist en dit niet zo makkelijk te realiseren is met enkel een touchscreen. Met behulp van een beetje multi-touch heb ik uiteindelijk toch een goed systeem kunnen uitwerken. Eindelijk.

Vandaag heb ik gewerkt aan een iPhone app, meer bepaald aan een systeem om een object te laten besturen door de gebruiker. Een hele dag werken en drie verschillende systemen verder ben ik uiteindelijk heel tevreden van het resultaat.

Het object moet in vier richtingen kunnen bewegen: rechts, links, onder en boven. Dit klinkt eenvoudig maar is niet zo vanzelfsprekend om te realiseren met de iPhone hardware. De uitdaging was niet om dit geprogrammeerd te krijgen, dat is niet zo moeilijk, maar om een gebruiksvriendelijk systeem te maken. De vier pijltjes toetsen van veel game consoles zijn uiteraard niet aanwezig op de iPhone...

Het eerste systeem dat ik gemaakt heb was een systeem met vier knoppen op het scherm. Door op een knop te drukken, en deze in te blijven drukken, bewoog het object. Om van richting te veranderen moest de speler z'n vinger opheffen en de andere knop indrukken. Klinkt logisch, maar een test met een echt toestel wees al snel uit dat dit geen comfortabele manier van werken is. Beter zou zijn als de speler z'n vinger kon schuiven naar de andere knoppen; zoals dat ook gaat bij fysieke knoppen.

Bij het tweede systeem waren er dus weer vier knoppen maar kon de speler deze keer van richting veranderen door z'n vinger naar een andere knop te verschuiven. Dit werkte al een stuk prettiger!
Er was echter nog een groot probleem; de speler kon niet voelen waar de knoppen zitten, zoals dat wel kan bij andere game consoles. Wanneer de speler volledig geconcentreerd is op het spel is het wel zeer lastig om te moeten kijken waar een knop staat. Zo ga je reactievermogen natuurlijk vreselijk omlaag...

Uiteindelijk ben ik tot een gesture gebaseerd systeem gekomen. De speler kan z'n vinger eender waar plaatsen waarbij hij vervolgens door z'n vinger te bewegen de richting van het object kan aangeven. De speler hoeft dus niet te onthouden waar de knoppen staan en hij kan nooit fouten maken. Dankzij deze twee voordelen is dit een zeer prettig systeem. Een praktijktest wees zelfs uit dat m'n ouders er mee overweg kunnen, wat betekend dat iedereen het kan : ).
Nog een voordeel van dit systeem is trouwens dat er nu meer ruimte op het scherm vrij is, gezien er geen knoppen getoond moeten worden.

Om de iPhone SDK onder de knie te krijgen ben ik aan het lezen in "Beginning iPhone Developement - Exploring the iPhone SDK". Ondanks dat ik in de paasvakantie dit boek al voor een kwart gelezen heb ben ik deze vakantie terug in het begin van het boek begonnen; kwestie van de basis nog eens te herhalen.

Bij de eerste hoofdstukken horen allerlei saaie voorbeeldprogramma's waar ik niet zo veel zin in had, dus heb ik een kleine app geschreven om de basis nog eens te herhalen. Omdat ik niet zomaar een saaie app wou maken heb ik er meteen iets "speciaal" in gestoken; een app voor twee gebruikers waarbij de huidige gebruiker afhankelijk is van de oriëntatie van de iPhone.

Beeldt u een game voor twee spelers dat gespeeld wordt op één toestel. Een voorbeeld hiervan is Advance Wars op de Nintendo DS. Hierbij wordt het toestel om de beurt aan de andere speler doorgegeven. Omdat een speler meerdere zetten kan doen in een beurt moet hij in de game aangeven dat hij stopt met zijn beurt. Vervolgens geeft hij het toestel aan de andere speler. Als de andere speler tegenover de eerste speler zit moet hij het toestel omdraaien zodat hij aan zijn beurt kan beginnen.

Beeld je twee spelers in die samen een iPhone game, gelijkaardig aan bijvoorbeeld Advance Wars, spelen in. Als de eerste speler klaar is met zijn beurt geeft hij het toestel aan de andere speler. De andere speler hoeft het toestel niet om te draaien, de iPhone detecteert dat het toestel omgekeerd rechtop gehouden wordt, waardoor automatisch van beurt gewisseld wordt. Door de symmetrie van de iPhone (of iPod Touch) kan het spel gespeeld worden ongeacht of het toestel naar boven of naar onderen gehouden wordt. Met dit systeem worden dus de twee stappen van de Nintendo DS onnodig: de speler hoeft niet aan te geven dat hij wilt stoppen met zijn beurt (dit wordt automatisch bepaald doordat de iPhone van oriëntatie verandert) en het toestel hoeft niet omgedraaid te worden.

Maar goed, ik ging dus een iPhone app schrijven! Zoals je kan vermoeden heb ik bovenstaand concept uitgewerkt. Omdat ik niet de tijd of kennis heb om een vette game te schrijven heb ik een eenvoudige chat applicatie gemaakt.

In het tekstvak bovenaan kan de gebruiker zijn bericht ingeven, de discussie wordt getoond in het tekst kader eronder. Als er te veel tekst is om op het scherm weer te geven kan de gebruiker scrollen. Het is slechts een kleine applicatie, die ik op een uurtje in elkaar gestoken heb, maar het was een fijne oefening.

Deze app is niet echt nuttig, maar het concept van van gebruiker wisselen kan wel interessant zijn voor echte, uitgewerkte apps, in het bijzonder games. Het type spel waarvoor dit systeem zeer geschikt is, is een spel met een beurtensysteem waarbij de speler meerdere acties kan ondernemen tijdens zijn beurt. Dit laatste omdat anders de applicatie altijd weet dat na eender welke actie de beurt aan de andere speler moet zijn en het voordel van dit systeem dus minder groot is.

Het systeem heeft ook z'n nadelen: gebruikers zijn niet vertrouwd met dit concept (dit kan aangeleerd worden) en als de telefoon gaat kan men de telefoon omgekeerd opnemen (dit is lastig, maar kan grappig zijn).

Het ontwerpen van een user interface begint met een schets op papier. Wanneer men tot een goed ontwerp is gekomen wordt de schets uitgewerkt op de computer. Dat kan met een hoop programmeer code, maar vaak wordt er gebruik gemaakt van user interface design programma's: programma's die toelaten om op een grafische manier een user interface te bouwen.

In het geval van de iPhone gebeurt dit met Interface Builder. Met dit programma was ik zojuist wat aan het spelen om een teksteditor App te bouwen. Dat klinkt heel complex maar ik heb het heel beperkt gehouden, ik wou enkel het Text View interface element eens uitproberen.

Eerst maakte ik gebruik van een Text View die het volledige scherm in nam. Dit leidde echter tot een probleem bij het aanpassen van de tekst. Wanneer het toetsenbord te voorschijn kwam schoof dit namelijk over de Text View, waardoor deze nog maar voor de helft zichtbaar werd. Een eenvoudige oplossing (daarom niet in de praktijk de beste) is natuurlijk om de Text View gewoon wat minder hoog te maken. Hiervoor moest ik de hoogte van het toetsenbord kennen, en dus ben ik aan het "meten" geslagen. Uiteindelijk bekwam ik een hoogte van 216 pixels van het toetsenbord.

Sommige lezers, en de niet-nerds in het bijzonder, vragen zich wellicht af wat dit er nu toe doet. Het virtuele toetsenbord van de iPhone is één van de unieke eigenschappen (al dan niet positief) van de iPhone maar is ook een belangrijke eigenschap om rekening met te houden bij het ontwerp van een interface. Doordat plots nog maar (ongeveer) de helft van de eigenlijke interface getoond kan worden kunnen er problemen ontstaan of kunnen belangrijke interface elementen onzichtbaar worden.

Problemen zoals de Text View die nog maar voor de helft zichtbaar was zijn eenvoudig te vinden. Maar stel bijvoorbeeld dat de gebruiker input in een bepaald formaat moet geven, dan is het handig dat de interface een stukje tekst bevat dat de gebruiker hiervan op de hoogte stelt. Het zou dan echter zeer onhandig zijn mocht dit stukje tekst verdwijnen wanneer de gebruiker effectief begint met het ingeven van tekst. Conclusie: over een user interface moet goed nagedacht worden en het is belangrijk rekening te houden met de eigenschappen van het toestel.

Nu deze website on-line staat begin ik met een nieuw project: het maken van een iPhone App. Afgelopen paasvakantie heb ik er al even mee bezig geweest, maar door de beperkte tijd is het toen gebleven bij enkele nogal stompzinnige iPhone spelletjes, zoals "raad het getal". Het valt te raden hoe leuk dit spelletje was...

De weg naar een geslaagde App begint met het opdoen van kennis. Daarvoor heb ik een zeer goed boek gekocht: "Beginning iPhone Developement - Exploring the iPhone SDK". Dit boek ben ik begonnen met lezen in de paasvakantie en ga ik nu verder lezen.

Tegelijkertijd begin ik met het uitdenken van een App. Of beter: het verder perfectioniseren van het concept dat ik al enkele maanden in gedachten heb. Mezelf kennende is het echter ook best mogelijk dat ik uiteindelijk een heel ander concept ga gebruiken...

Een concept uitdenken en uitschetsen, levels ontwerpen, een passende grafische stijl erbij zoeken,... het ontwerpen is waar ik het liefst mee bezig ben. Naast het beter leren werken met de iPhone SDK zal ik hier dan ook heel wat tijd in steken. Dat is ook nodig want met enkel technische kennis kan je het vergeten om tot een succesvolle app te komen.