Flutter is een leuk framework

Flutter is een framwork dat kan worden gebruikt om cross platform apps te maken. Ik heb het recentelijk geleerd om mijn app "Voorlees-papegaai Jacky" te maken. 

Flutter kan ook gebruikt worden om desktop apps en websites te maken, maar tot nu toe heb ik het gebruikt om voor Android en iOS te ontwikkelen. Dit zijn mijn ervaringen.

Frameworks die ik al eerder heb gebruikt

Voordat ik Flutter koos voor mijn volgende project waren en de nodige twijfels. Ik ben al bekend met Cordova en Xamarin. Het is al een tijdje geleden sinds ik nog een mobiele app heb gemaakt. De opkomst van ReactNative heb ik compleet gemist. En nu zijn er zelfs nog meer moderne opties buiten ReactNative. 

Dus zou ik een framework gebruiken waarmee ik al bekend ben? Iets nieuws proberen? Ionic lijkt op Cordova. Ik heb goede dingen gehoord over ReactNative. En er is nu ook iets wat Flutter heet?

Ik koos voor Flutter. Het leek me een goed idee iets nieuws te leren, om te zien wat een nieuwer framework te bieden heeft ten opzichte van een bestaand framework.

De keuze was niet makkelijk, het kwam aan op een tie-breaker. Ik koos uiteindelijk voor Flutter omdat het dan gaat om een strongly typed taal, voor mij is dit een voordeel. (Dit is natuurlijk heel subjectief.)

Flutter hello world

De app die ik wil maken speelt een geluidseffect af op basis van wat je voorleest. Je kan deze app bijvoorbeeld gebruiken terwijl je voor je kinderen 's avonds voorleest. Je hebt er misschien al van gehoord.

Maar eerst heb ik een "hello world" app gemaak met slechts één knop en een tekstveld die een teller weergeeft.

Wanneer je een nieuw Flutter project start, dan heb je een main.dart file, en nog wat projectfiles zoals Gradle build scripts. Dart is de programmeertaal die wordt gebruikt om Flutter apps te maken, meer hierover later.

Er zijn drie elementen in main.dart:

• Een main functie. Dit geeft mij al een goede indruk. Het hebben van een simpele main functie terwijl je een mobiele app maakt. Waarom niet eigenlijk?
• Een "MyApp" class die een Stateless Widget voorstelt. Ieder GUI element is een widget in Flutter, dus de top-level app is dat ook.
• Een Stateful Widget genaamd “ReadingParrot” in mijn geval. Een stateful widget is altijd gekoppeld aan bijvoorbeed een _ReadingParrotState class. Het is een stateful widget omdat het zijn uitzicht en gedrag veranderd naargelang de waardes in zijn state.

Gebruikmakend van de getting started documentatie van Flutter, was het opzetten van de hello world app een vlot proces.

Het maken van de Voorlees-papegaai GUI

De GUI had ik reeds ontworpen, en nu zou ik die willen implementeren in Flutter

Een screenshot van een vroege versie van de voorlees-papegaai Jacky app.

Hier is nog een groot voordeel van Flutter als je het mij vraagt: de GUI en de back-end logica worden opgemaakt in dezelfde taal: Dart. Je kan alles in dezelfde file stoppen, als je dat wilt.

Je definieert een GUI in Dart, wat neerkomt op een geneste declaratie van variabelen. Variabelen zouden zijn van het type Row of Column voor layout-ing, Button, Text, Icon,… En wanneer je een button object instantieert, dan geef je Dart closures door aan de "on call" property om gedrag toe te voegen.

Variabelen nesten om een GUI te bouwen geeft een indruk dat het niet goed zou schalen. Daar een een mooie oplossing voor: zet code die de GUI opbouwt in hun eigen functies, duh. Maar even serieus, in de praktijk is er kans dat het nesten van meer en meer variabelen, naargelang dat de GUI complexer wordt, uit de hand zou kunnen lopen. Mijn tip hier is om aparte functies te maken wanneer mogelijk, refactoring wordt zelden nog gedaan achteraf. (Dit is van toepassing op eender welk software project als je het mij vraagt.)

Een kleine klacht die ik heb, om de bovenstaande opvattingen te balanceren: het zetten van marges lijkt niet erg intuïtief te zijn. Je zou regelmatig marges en padding toevoegen aan containers. De Container widget heeft een margin veld, maar hier geef je niet direct numerieke waardes in. Je moet een EdgeInsets object instantiëren. De naam EdgeInsets geeft niet echt aan "gebruik dit voor het zetten van marges en padding". Er zijn meerdere voorbeelden hiervan, maar alles kon opgelost worden met een snelle Google search.

Plugins!

Wat is een goed framework zonder plugins? Zelfs Cordova heeft ze.

Plugins laten toe om bepaalde zaken platform onafhankelijk te gebruiken, je wil liefst geen code schrijven voor een specifiek platform.

Mijn voorlees-papegaai zou nodig hebben:

• Spraakherkenning: er is een plugin ✅.
• Audio playback: er is een plugin ✅.
• Internet connectiviteit checks: Er is een plugin ✅.

Een plugin installeren kan worden gedaan via het commando:  flutter pub add <plugin>. Of je  kan een statement toevoegen aan pubspec.yaml En dan het commando: flutter pub get uitvoeren.

Geen verder commentaar nodig hier, de plugins die ik nodig heb zijn beschikbaar en zijn makkelijk te installeren. 

GUI performance

Een Flutter ontwikkelaar heeft goede controle over wanneer er een GUI display update moet plaatsvinden.

Herinner je het stateful widget concept wat eerder was vermeld, wanneer er iets verandert in het bijhorende _state object, dan moet je setState() aanroepen om aan te geven dat een GUI update noodzakelijk is. Dat moet je inderdaad, want anders verandert er niks op het scherm. Dit geeft je complete controle wat dat betreft, dit is zeker een voordeel de manier waarop ik dit bekijk.

Nog een interessant concept dat ik heb moeten toepassen in mijn voorlees-papegaai app: het selectief updaten van de GUI, i.e. setState() aanroepen voor een subset van de GUI. Ik wil live het microfoon volume tonen in de GUI, maar ik wil niet steeds de gehele GUI opbouwen voor iedere volume update, waarvan er erg veel plaatsvinden. Zonder teveel in detail te gaan, dit is ondersteund in Flutter.

Flutter GUI profiling is netjes geïntegreerd in Android Studio. Ik kon bevestigen dat het selectief updaten, zoals in de vorige paragraaf is vermeld, werkt zoals verwacht.

Over Android Studio gesproken...

Flutter ontwikkeling in Android Studio

Het Flutter framework is goed geïntegreerd in Android Studio. Dit zijn enkele features:

• GUI profiling integratie, zoals eerder vermeld.
• Hints over Dart conventies, die meestal automatisch toegepast kunnen worden. Dit is een enorme hulp om goede gewoontes te kweken bij beginners.
• Een hot-reload/hot-restart knop. Dit is een geweldige feature van Flutter in het algemeen,  wijzigingen toepassen in Dart code duurt milliseconden om met een echt Android apparaat te synchroniseren.

Het is bijna saai, bijna. Maar hier heb ik verder ook geen commentaar op. Flutter ontwikkeling in Android Studio gaat mij goed af.

De Dart programmeertaal

Dart is single-threaded, asynchroon en strongly-typed. Het feit dat het single-threaded is houdt dingen simpel, terwijl het asynchrone aspect (het heeft async/await mechanismen) het makkelijk maakt om het renderen van de GUI niet te blokkeren met andere langdurige taken.

Hier zijn wat technische details over de programmeertaal:

• Het is een strongly typed taal, wat de ontwikkeling minder foutgevoelig maakt. Er is ook type deduction, je kan gewoon final x = calcX() intypen bijvoorbeeld.
  
• Het ondersteund runtime en static constanten, beide worden gecheckt tijdens compilatie.
• Dart gaat goed om met null safety. Je kan een type nullable declareren, en je moet een check doen vooraleer je het object mag gebruiken, anders krijg je een compiler error. Wanneer je een nullcheck doet dan wordt meestal die variabele automatisch "gepromoveerd" naar een niet-nullable type.

Het biedt echter geen nieuwe concepten aan vergeleken met bestaande programmeertalen. Dart is desondanks een degelijke taal. Maar ik vind het vreemd dat een framework wordt gebouwd op een minder bekende taal, die aan de oppervlakte conceptueel hetzelfde is als bestaande talen. Dat verhoogt zeker en vast de leercurve, je moet zowel een framework als een taal leren, want de Dart taal wordt nagenoeg nergens anders dan voor Flutter gebruikt. Maar aan het einde van de dag is een programmeertaal slechts een werkmiddel.

De Flutter FAQ verklaart waarom het voor Dart koos. De vermeldde criteria gaan blijkbaar niet over de populariteit van de taal, het gaat meer om de technische verdienste van de taal zelf.

Ik vind dat Dart wel wat lijkt op Kotlin op veel manieren. Dart komt bij mij over als een soort "Kotlin light". Als je ervaring met Kotlin hebt, dan zou dat wellicht enigszins van pas komen bij Dart.

Conclusie

Ik zou Flutter iedereen aanraden die op zoek is naar iets nieuws om te leren.

Vergeleken met de frameworks die ik al kende, biedt Flutter eenvoud door de ontwikkelaar de GUI en het gedrag te laten maken in dezelfde taal. Het biedt ook moderne features aan zoals hot-reload/hot-restart.

Dat gezegd hebbende, zowel een nieuw framework leren als een nieuwe programmeertaal tegelijk is intimiderend. Voor mij was het desondanks de moeite waard. Ik heb er een mooie app mee kunnen maken al zeg ik het zelf.

Het kan trouwens ook gebruikt worden voor website en desktop ontwikkeling. Dit framework leren biedt veel mogelijkheden.

Bedankt voor het lezen van mijn gedachten en indrukken over het Flutter framework. Ik hoop dat het voor jou van pas zal komen!

Aankondiging van "Voorlees-papegaai" mobiele app

Ik ben al een tijdje aan het werken aan een nieuwe app die het leuker maakt om verhaaltjes voor te lezen aan je kinderen.

Het idee is dat de app geluidseffecten afspeelt terwijl je leest. Geluidseffecten zoals een brullende tijger, of een fietsbel, of een politiesirene,...

Ik geloof dat hier veel potentieel is, Ik ga het in ieder geval zelf ook gebruiken. Ik lees regelmatig verhaaltjes voor aan mijn kinderen. En hoewel ze graag luisteren, zou het toch handig zijn nog een andere manier te hebben om het leuker te maken.

De app zal "Voorlees-papegaai" heten, "Reading Parrot" in het Engels. Mijn hoogste prioriteit momenteel is om een Nederlandse versie te maken zodat ik de app zelf kan gebruiken tijdens het voorlezen aan mijn kinderen. Bij het releasen van de app zou ik ook ondersteuning voor Engels hebben toegevoegd.

Over releasen gesproken, initieel zal het voor Android gereleased worden. Wellicht zal dit eind januari, begin februari gebeuren. Een release voor iOS zal er kort op volgen wanneer de kinderziektes opgelost zijn.

Heb je vragen of andere feedback? Aarzel niet om contact op te nemen: support@geeapp.com

En hier is ook een sneak peak hoe te app er uitziet. (Dit kan nog veranderen bij de daadwerkelijke release)

 

Een maker van game assets worden

Het complete traject van een complete, technisch ingestelde beginner.

Game making is moeilijk wanneer je zelf niet in staat bent om assets te maken.

Dingen zoals personages, effecten, zelfs knoppen. Het is bijna onmogelijk om games te maken zonder.

Mijn interesse voor programmeren werd gewekt door het spelen van games. Intussen vind ik het leuk om eender welk type software te maken. Maar game making is nog steeds iets wat ik als hobby heel graag doe.

Het academische pad wat ik koos is gericht op traditionele Computerwetenschap. Mijn specialisatie, Visual Computing, is geïnspireerd door de initiële aantrekkingskracht naar het programmeren. Kortom. dit is enerzijds rendering (zoals in games, of zoals ray-tracing, wat tegenwoordig ook in games is). Of over beeldverwerking (simpel gezegd: dingen in afbeeldingen detecteren).

Van alle aspecten van game making, is programmeren veruit het gemakkelijkste, en het leukste om te doen voor mij. Helaas, algemeen gesproken, is dat niet genoeg om een complete game te maken.

Voordat ik mijn universitaire opleiding begon (2014), heb ik mijn eerste mobile game "Danger Zones" "afgemaakt". Dit is geen afgewerkte game nu ik erop terugkijk, maar destijds dacht ik: "de gameplay is redelijk goed, de graphics zien er niet zo goed uit maar dat balanceert elkaar.". Als je deze manier van denken in jezelf herkent dan heb ik misschien slecht nieuws voor jou. Dit geldt misschien voor games als Minecraft. Maar het geldt niet als je game er zo uitziet:

Ik hield mezelf compleet voor de gek destijds. Dit is geen complete game, dit is een grey-box prototype. Als in, het prototype waarin de graphics later worden geïntegreerd door een gekwalificeerde persoon. Dat realiseer ik mij nu.

Maar ik ben niet van plan deze game op te geven. Wat zou ik nu moeten doen?

• Ik kreeg al feedback van vrienden: "Je zou iemand moeten inhuren om de graphics te maken.". Het klinkt logisch maar is dit niet veel te duur? Het gaat immers over een hobby project.
• Misschien kan ik bestaande assets gebruiken? Er zijn veel websites waarop assets gratis te verkrijgen zijn, of voor een redelijke prijs. Dit probeerde ik, en het voelde als een puzzel afmaken, met stukken van een andere puzzel. Als ik dit op een effectieve manier wilde gebruiken, dan zou het hebben geholpen om dit vanaf de start in het achterhoofd te hebben.
• Zelf assets maken. Maar ik ben helemaal niet gekwalificeerd om dat te doen. Dit leren zou jaren kunnen duren. Het zou echter wel een waardevolle vaardigheid zijn. Iets waarvan ik altijd dacht dat het alleen voor getalenteerde creatieve mensen was weggelegd.

Ik had iemand "ingehuurd"

Over dit probleem heb ik lang nagedacht terwijl het leven verderging. Het eerste wat ik probeerde was een post maken op de Unity fora waarin ik hulp van een designer vraag. En ik had ook iemand gevonden! Dat was een goed gevoel, maar er waren wat rode vlaggen die ik in mijn blijdschap niet heb gezien.

Ik maakte een schatting voor het aantal uren, en op basis daarvan een prijs die ik bereid was te betalen. Ongeveer 200-300 euro. Geen idee of dit een redelijke prijs is of niet. De designer antwoordde: "Eigenlijk verwachtte ik meer" maar (op een of andere manier) gingen ze toch akkoord. Ik wilde graag dat deze persoon een document ondertekende om verder gedoe te vermijden. Dat is nooit gebeurd. Ik heb hun het document per email verstuurd en we hebben het er verder niet meer over gehad. Maar de designer ging wel aan de slag met dingen maken. Ik deed geen moeite meer om naar het document te vragen, ik wilde gewoon verdergaan met het afmaken van de game.

De eerste feedback sessie

Mijn eerste beschrijving van, wat ik nu zou noemen, de art direction was: "Objecten mogen niet bestaan in de echte wereld, dit is bedoeld om tot de fantasie van de speler te spreken." HEEL ambitieus voor een mobile game ik weet het. Ik geef toe dat het nogal vaag is. Een fout aan mijn kant.

We hielden een chat sessie via tekst over Skype. Ze vroegen mij om feedback te geven omdat ze wat dingen hadden gemaakt.

Toen werd ik een apenhoofd met twee machinegeweren getoond (het apenhoofd van Blender, een standaard asset van dat programma) als een idee voor de eerste boss battle. Mijn feedback was niet positief. Ik stelde mijn verwachtingen bij naar de verdere samenwerking.

De samenwerking werd beëindigd na een paar weken. Ik vroeg hun een status update, en het antwoord was dat er problemen zijn met hun laptop, of zoiets. Dit was niet de eerste keer dat ik deze uitleg kreeg. Ik wilde niet langer samenwerken met deze persoon. Dus ik zei dat ik niet steeds mijn project wilde vertragen vanwege technische storing aan hun kant. En zo doende werd de samenwerking beëindigd.

Op voorhand een art direction bepalen

Wat ik van die ervaring geleerd heb is: werken met mensen is duur en vereist glasheldere communicatie skills.

Als ik dat opnieuw zou proberen dan zou ik op zijn minst een duidelijke art direction nodig hebben. Je kan niet van iemand verwachten om het "gewoon te snappen". Zo werkt het helaas niet.

Later realiseerde ik mij dat ik het zelf ook niet echt begreep. Op dit moment was ik verschillende kleuren en vormen aan het uitproberen in mijn game, om te zien of ik het zelf er beter kon laten uitzien. Het verbeterde simpelweg niet, werken aan de game werd frustrerend.

Ik probeerde nu ook om bestaande assets te vinden die mij zouden helpen. Dat is hetzelfde principe, je weet niet waarnaar te zoeken zonder richting/begeleiding.

Het project werd een paar jaar stopgezet. Ik gaf het voorlopig op omdat ik concludeerde: voor het prototype dat ik maakte, is het te moeilijk om een art direction te kiezen.

Game assets leren maken van online cursussen

Op dit moment (2018) was ik fulltime werkzaam als junior software engineer. Mijn werk ethiek was aan het verbeteren. Ik had nu wat extra geld om uit te geven nu ik niet langer student was.

Het project spookte af en toe nog door mijn hoofd. Ik had bedacht, waarom probeer ik niet zelf te leren game assets te maken. Het heeft nu al jaren geduurd, het maakt niet uit of het nog enkele jaren langer duurt.

Tot mijn vreugde ontdekte ik dat Udemy veel van dit soort cursussen aanbiedt. En het was toen rond de nieuwjaarsperiode dus er waren flinke kortingen! Cursussen die duizenden waard zijn kon je tijdelijk verkrijgen voor tientallen! Wat een koopje! Later zag ik dat Udemy regelmatig van dit soort kortingen heeft. Dus koop nooit iets aan de volle prijs op die website is mijn advies.

Kleurtheorie

Desalniettemin kocht ik een aantal cursussen. Ik koos cursussen over 2/3D art en animatie, geluidsdesign, kleurtheorie, storytelling,...

De volgende maanden ging ik traag maar gestaag aan de slag met de cursussen. Tot mijn grote verbazing was kleurtheorie het meest nuttige voor mij. Mijn technisch brein had eindelijk een manier om kleuren uit te kiezen! Deze realisaties motiveren je om verder te gaan.

 

Kortom, kleurtheorie leert je dat bepaalde kleuren een bepaald gevoel uitlokken in mensen. Dat is misschien veel gezegd. Maar stel nu dat je een asset wil maken van een basale vijand. Welke kleur kies je? Rood waarschijnlijk, toch? Maar echt rood, rood of scharlaken eerder? Bordeaux misschien? Voor een technisch brein, voor dat van mij in ieder geval, zijn dit soort keuzes een grote uitdaging.

Om de gedachte af te maken: Bordeaux zou een goeie keus zijn voor een geraffineerde, serieuze vijand. Scharlaken zou beter zijn voor een fanatieke, bruut-achtige soort vijand.

Vector graphics

Mijn technisch brein is aangetrokken tot 2D vector graphics zo blijkt.

 

Ik vond het altijd een nare gedachte om tekeningen te gaan schetsen, of digitale tekeningen te maken. Ik was zeker dat dat nodig is om game assets te kunnen maken. Ik zou spiergeheugen moeten ontwikkelen door gedurende lange tijd te oefenen. En vervolgens zou ik een tekentablet moeten kopen, want hoe anders maak je digitale tekeningen, met een muis?

Voor vector graphics heb je niet noodzakelijk schetsen nodig (hoewel dat wel een valide manier is, begrijp me niet verkeerd). En je kan inderdaad gewoon een muis gebruiken. Want het is niet zozeer een activiteit van "tekenen". Maar een activiteit van simpele vormen te combineren via wiskundige set operaties, en van curves aanpassen door punten te verslepen.

Schaal invariantie is ook iets wat ik apprecieer van een technisch standpunt. Het werkt net zoals met fonts, zoals de tekst die je momenteel leest. Een vector tekening ziet er goed uit op ieder scherm ongeacht hoe ver je in- of uitzoomt. Dat is zo omdat vormen door parameters gedefinieerd worden en niet door pixels. Parameters zijn bijvoorbeeld: positie, radius, breedte, hoogte,... Ze beschrijven vormen. Dat is een heel andere techniek dan bij gewone afbeeldingen (.jpg, .png, .gif,...).

En, ook niet onbelangrijk, vector tekeningen hebben een goede werk/oplevering ratio. Dat betekent dat de inspanning om iets acceptabel te maken relatief laag is. De look and feel van vector graphics zijn acceptabel voor gebruikers. Vind je het gek? De lat ligt niet erg hoog, pixel art is ook acceptabel. Wie houdt er nu niet van een leuk spel met een retro look? Daarin ligt nog een realisatie. Game assets, als vorm van digitale kunst, hebben een lage drempel om acceptabel of redelijk bevonden te worden.

Achteraf gezien...

Als je zoals mij bent, en je hebt geen formele training in het maken van game assets, dan is het bekijken van online cursussen sterk aangeraden wat mij betreft. Of misschien zelfs gewone cursussen afhankelijk van de tijd en middelen die je hebt. Het helpt veel wanneer een professional je laat zien welke tools je moet gebruiken, en wat de redenering is bij verschillende stappen.

Ik heb ook overwogen om YouTube tutorials te bekijken, want die zijn gratis. Maar ik vreesde dat ik niet helemaal toegewijd zou zijn zonder financiële investering. Ik geloof persoonlijk ook, dat een gratis cursus niet aan dezelfde norm gehouden wordt als een betaalde cursus. Dus ik ben eerder aangetrokken naar een, redelijk geprijsde, cursus met een hoge rating. Dan naar een gratis cursus met een hoge rating.

Het project doen herrijzen

Ik heb wat online cursussen gevolgd, ben ik nu capabel om eindelijk het grey-box prototype in een volledige game te transformeren?

Dus wat wordt de art direction?

Intussen heb ik op wat ideeën gebroed. De weinige mensen die mijn game al gespeeld hebben weten dat het een 2D game is waar je tussen vlakken wisselt in de diepte (de Z-as) om verder te komen in het level. (Misschien kun je het beter gewoon proberen, dat maakt het wel duidelijk).

Ik redeneerde dat je deze mechanic wel kan bekijken als het wisselen tussen parallelle universums. Dus "futurisme" is hier een eerste component. Wanneer ik aan futurisme denk dan denk ik aan de ruimte. Dit is een algemeen bekend thema in gaming. Er zijn al veel bestaande assets in het thema ruimte. En wanneer ik zelf assets maak heb ik meer dan genoeg referentiemateriaal.

In al die jaren heb ik geen beter idee gehad. Dus het was beslist. De art direction van mijn game is: een 2D game met interdimensionale aspecten in de ruimte. Gemaakt in vector graphics (vanwege de eerder vermeldde affiniteit).

Dat is nog steeds niet genoeg wanneer je andere game designers wil benaderen. Maar het is goed genoeg om solo verder te gaan. En dat is ook het plan.

Concept art maken

Om mezelf volledig te overtuigen dat ik in staat ben het project te doen herrijzen. Besloot ik om concept art te maken van alle assets die ik nodig ga hebben. Dit doe ik door complete scenes te maken direct in de editor. Ik gebruik Inkscape trouwens. Wanneer deze concepten klaar zijn, betekent het dat ik alle nodige assets zelf heb kunnen maken. Wat nog meer, ik zou deze werken kunnen delen om alvast de game te promoten. De game promoten is ook iets wat ik de eerste keer niet goed heb gedaan.

Er zijn wat elementaire benodigdheden:

• Een main character
• Een doel object
• Een basale vijand.
• ...nog veel meer

Dit is geen developer log. Maar ik zal bovengenoemde assets laten zien om mijn voortgang te bewijzen.

De conclusie

Het kost misschien wat tijd om de nodige vaardigheid op te bouwen. Laat dit je niet demotiveren. Zelf game assets kunnen maken, en daarbij zelf ook het programmeren kunnen doen, is een gigantisch voordeel. Het is veel goedkoper, er is geen creatieve communicatie barrière, je kan volledig zelfstandig games maken,...

Met genoeg motivatie kan zelfs een schijnbaar hopeloos technisch brein uitzoeken hoe game assets te maken. Het heeft wat tijd gekost. Het meeste van die tijd was gespendeerd door mezelf tegen te houden, omdat ik de dingen mij moeilijker voorstelde dan dat ze zijn. Ik maak nog steeds geen assets op op hoog niveau, maar dat houdt mij niet tegen om een complete game te maken. En dat zou jou ook niet moeten tegenhouden. Een game afmaken is het overkoepelende doel.

Bedankt om mijn verhaal te lezen. Ik hoop dat het jou helpt.

Een nieuwe richting voor deze blog

Op een dag besloot ik om mezelf te Googelen. Iedereen doet dat toch wel eens? 

Het eerste wat ik vind is mijn LinkedIn pagina. Die heb ik in geen jaren geüpdatet. Zou mijn huidige werkgever nerveus worden als ik dat doe?

Nog een ding in de resultaten is een overlijdensbericht van iemand met dezelfde naam. Rust in vrede.

Ik kijk verder en wat zie ik hier? Een blog over de beroemde kunstenaar M. C. Escher. Gemaakt door iemand met dezelfde naam als ik. Wacht even, dit is iets was ik vroeger op de middelbare school als project heb gemaakt. Hoe nostalgisch!

Blog posts schrijven is iets wat mij recentelijk begon te interesseren. Alleen zou het dat niet gaan over M. C. Escher. Maar over mijn eigen professionele inzichten in software engineering. En ook over mijn leuke hobby projecten, al zeg ik het zelf.

Dus ik heb besloten om deze blog te laten verrijzen. Maak je geen zorgen, de posts over M. C. Escher laat ik intact. Die zijn mij nu te dierbaar.

Inmiddels heb ik ook een persoonlijke GitHub page. Dit is in feite dezelfde blog maar dan in het Engels.

 

Escher in het paleis

Paleis is al veel gezegd, het is meer een museum waar men probeert de "Escher experience" te creëren. Dit wil zeggen dat het Paleis Lange Voorhout volledig is gewijd aan M.C. Escher

Het is geopend op 16 november 2002. Toen het paleis een museumfunctie kreeg, waren er de eerste periode verschillende tentoonstellingen. De Escher-collectie kwam pas in 2002.

De zogenaamde Escher Experience, een multimediareis door de wereld van Escher. De bezoeker kan hierdoor de ongrijpbare, vervreemdende wereld van Escher ervaren.

Uitspraken van Escher

M.C. Escher was een zeer en interessant persoon vanwege zijn unieke bijdrage een de wereld van kunst en wiskunde. Hieronder zijn een aantal uitspraken of "citaten" van hem. "Ik geloof dat het maken van prenten, zoals ik dat doe, bijna alleen een kwestie is van het zo verschrikkelijk graag goed willen doen." "Ik zou een tweede leven kunnen vullen met het werken aan mijn prenten." "Op momenten van groot enthousiasme schijnt het me toe dat er nooit op de wereld, door niemand, zo iets moois en belangrijks gemaakt is." “Ik speel een vermoeiend spel." “Ik word niet volwassen. In mij is het kleine kind van vroeger." “De dingen die ik wil uiten zijn zo prachtig en zuiver." “Ik wandel steeds in raadselen. Er komen telkens jongelui die zeggen: u maakt ook popart. Ik weet helemaal niet wat dat is, popart. Dit werk maak ik al dertig jaar."

De werken van Escher

Pas vanaf zijn veertigste maakte Escher "Escheriaanse" prenten. Hieronder volgt een opdeling van de onderwerpen die typisch zijn voor Escher. 

Regelmatige vlakvulling 

Met regelmatige vlakvulling bedoelt men een prent die volledig gevuld is met gelijkvormige figuurtjes die elkaar nergens overlappen.

Voorbeeld

Dag en nacht

Twee dimensies, of drie dimensies? 

Een voorbeeld hiervan is de prent Tekenen. Enerzijds lijkt het alsof Escher een afbeelding heeft gemaakt van een eerste driedimensionale hand, die een tweede, tweedimensionale hand tekent, anderzijds lijkt het alsof de eerste hand juist tweedimensionaal is, en getekend wordt door de tweede hand, die driedimensionaal is. Een ander voorbeeld is Prentententoonstelling, waarop een man naar een prent kijkt waarop hij zelf afgebeeld is.

Voorbeeld

Handen

Onmogelijke ruimtelijke objecten 

Dit onderwerp spreekt voor zich. Hierbij tekende Escher een Ruimtelijk figuur dat volgens wiskundige eigenschappen onmogelijk was

Voorbeeld

Villa

Perspectief

Escher had een voorkeur voor eigenaardige gezichtspunten. Deze prenten kun je vanuit 2 perspectieven interpreteren.

Voorbeeld

Vaas 

Oneindigheidsbenaderingen 

Deze prenten zijn allemaal regelmatige vlakvullingen, maar aan de randen worden de afgebeelde figuurtjes steeds kleiner, zodat er uiteindelijk schijnbaar oneindig veel figuurtjes afgebeeld zijn. 

Voorbeeld

Cirkellimiet

Simultane werelden 

Een voorbeeld hiervan is de prent Drie werelden; de drie werelden zijn: de bomen die weerspiegeld worden in de vijver, de bladeren die op de vijver drijven, en de vis die erin zwemt.

Voorbeeld

Drie werelden

Isometrische illusies

Het is soms niet duidelijk of iets juist dichtbij of ver weg is, zoals in het werk Hol en bol.

Voorbeeld

Hol en bol