Spellenbeheer

Als admin wil ik spellen kunnen toevoegen, verwijderen of aanpassen aan de app

Voor het beheren van de spellen wordt het Headless CMS (Content Management System) Strapi gebruikt. Idealiter worden de spellen binnen de app bewerkt, maar om wille van de tijd is ervoor gekozen om een headless CMS te gebruiken.

Aan het begin van het project is er een document gedeeld met alle spellen. Als snel werd er geconcludeerd dat de benaming niet enorm consistent was. Er werden termen als Lintje, Lint & Lintjes door elkaar gebruikt. Op deze manier zou het niet mogelijk zijn om te filteren. Dit was een van de core functionaliteit van de applicatie.

Er moest een uniforme manier worden gemaakt om de spellen aan te passen. Er is ervoor gekozen om dit in een formulier te doen. Hierdoor wordt het maken van fouten een stuk lastiger. Door validatie en bepaalde input types zouden er niet snel verkeerde dingen ingevuld worden.

Om te beginnen is er een schets gemaakt van alle input velden met de daarbij behorende typen. Hierdoor ontstond er een goed overzicht van de mogelijkheden.

Na deze schets is er een design gemaakt, zodat er een duidelijk beeld ontstond van het eindresultaat. Dit design is ook voorgelegd aan de opdrachtgever en deze gingen er mee akkoord. Het design was overigens niet getest en enkel voorgelegd tijdens de wekelijkse meeting.

De resultaten van dit formulier zouden opgeslagen worden in een database. Het endpoint per spel zou er dan ongeveer als volgt uit zien:

	{
		id: '2',
		slug: 'pionnenroof',
		name: 'Pionnenroof',
		description: 'Er worden twee teams gemaakt. De spelers uit 1 team zijn de rovers, de spelers uit het andere team zijn de tikkers. Beide teams beginnen aan hun eigen kant van het veld. De tikkers hebben voor hen een rij met pionnen. Voor de rovers is het doel om zoveel mogelijk pionnen te roven. Zodra een rover een pion heeft gepakt mag deze getikt worden door een tikker. De rover moet proberen zonder getikt te worden de pion over de eigen achterlijn te krijgen. Ben je wel getikt? Dan moet de pion weer teruggelegd worden. Hoeveel pionnen kunnen de rovers pakken binnen 2 minuten?',
		category: category.tik,
		materials: [{
			name: materialName.pion,
			amount: 20,
			notes: 'of hoedjes',
		},
		{
			name: materialName.lint,
			notes: 'om eventueel teams duidelijk te verdelen',
		},
		{
			name: materialName.klok,
			notes: 'om de tijd bij de houden',
		},
		{
			name: materialName.fluit,
		}
		],
		minimumPlayers: 2,
		targetGroup: [1,2,3,4,5,6,7,8],
		rules: [ 'Rover met pion over de eigen lijn? Pion houden', 'Rover met pion getikt voordat eigen lijn bereikt is? Pion inleveren aan tikker', 'Tikker mag rover pas tikker als deze een pion gepakt heeft'],
		variation: [
			{
				description: 'Makkelijker voor de tikkers/moeilijker voor de rovers',
				actions: ['1 leerling tegelijk laten roven', 'Afstand tussen startlijn en tikker vergroten', '2 tikkers gebruiken']
			},
			{
				description: 'Moelijker voor de tikkers/makkelijker voor de rovers:',
				actions: ['Alle leerlingen tegelijk laten starten met roven', 'Speelveld kleiner maken']
			}
		]
	},

Het was eerst de bedoeling om dit design te implementeren in de app zelf. Na enkele dagen werd er geconcludeerd dat dit toch niet de beste keuze was voor dit project. Uiteindelijk is dit nog steeds de beste optie, maar om wille van de tijd was dit niet haalbaar.

Toen is er verder gekeken naar andere mogelijkheden. De meest logische mogelijkheid was een headless CMS. De keuze voor Strapi was al snel gemaakt. Dit content management system komt zo goed als out-of-the-box en is te personaliseren, omdat het een React applicatie is.

Daarnaast wordt er gebruik gemaakt van Content-Types. Een Content-Type is bijvoorbeeld een Spel, een Materiaal of een Categorie. Zo kunnen er verschillende materialen gemaakt worden, waardoor het consistent blijft.

Een spel kan bijvoorbeeld het materiaal Fluitje hebben. Als een ander spel ook dit materiaal gebruikt, is het mogelijk om hierop te filteren. Het gaat immers om dezelfde Content-Type: het materiaal fluitje.

Het CMS is alleen geoptimaliseerd voor desktop, maar dit is wat de opdrachtgevers wilden. Zij willen spellen aanpassen via desktop, aangezien het vaak om grote stukken tekst gaat. Het is dus geen probleem dat het CMS op mobiel niet helemaal goed werkt.

In eerste instantie voelde het erg dubbel, aangezien er al een API was en er zal dus door Strapi een tweede API komen. Toen is er besloten om het een week aan te kijken en daarna te beslissen welke van de twee opties er gebruikt zou worden.

Het duurde nog wel enige tijd voordat het CMS compleet ingericht was. Na twee sprints zag het CMS er als volgt uit:

Homescreen CMS

Spel aanmaken in CMS

Dit CMS is vervolgens getest bij de eindgebruikers (studenten ALO). Aan hen is de taak voorgelegd om zelf spellen toe te voegen en dit is zonder problemen gelukt. Hieruit blijkt dat dit een logische manier is voor hen.

Uiteindelijk is ervoor gekozen om de API van Strapi te patchen met de eigen API. Dit betekent dat de API van Strapi gebruikt (en herschreven) wordt in de eigen API. Hierdoor is er in de applicatie zelf maar 1 API nodig én valt de API te personaliseren. In Strapi is het lastig om de keys aan te passen en dit is wel mogelijk op het moment dat de API gepatcht wordt.

De reden dat er al een eigen API is, is omdat er ook met authenticatie gewerkt wordt.

Op dit moment is er een externe CMS (Strapi) waar het mogelijk is om spellen te beheren. Doordat er gewerkt wordt met Content-Types is de kans op fouten klein. Het CMS voelt logisch aan voor de opdrachtgever.