Projektval
Välja projekt: Allmänna kriterier
Att välja projekt är inte alltid helt lätt. Här kommer några krav och tips. Konkreta exempel visas senare.
-
Man kan välja ett spel, men det finns många andra typer av projekt!
-
Ni ska inte fortsätta med Tetris. Ni bör inte heller fastna alltför hårt i strukturen från Tetris, även om ni väljer att implementera ett spel.
Spel som Breakout och Snake är till exempel väldigt nära Tetris eftersom det mest handlar om rutor i ett rutnät, och där "räknas inte" koden som har samma grundstruktur som Tetris utan ni behöver lägga till betydligt mer nytt på egen hand. Fastna helst inte i ett rutnätsorienterat spel, för din egen skull! -
Projektet ska leda till ett demonstrerbart program. Skriver man någon form av "kodbibliotek" måste det alltså också finnas ett program som använder sig av kodbiblioteket, där det mesta av koden faktiskt används.
Projektet bör ha en liten kärna som är lätt att utöka i många steg. Det är ju inte lätt att uppskatta exakt vad man kommer att hinna med på den tid man har för design, kodning, finputsning och dokumentation. Kan projektet byggas upp steg för steg, kan ni "programmera till tiden tar slut" och sedan avsluta. Då kan ni balansera projektets omfattning mot dess kvalitet.
Detta återkommer i projektplanen, där projektet delas upp i ett antal milstolpar.
-
Projektet ska utan problem och utan mer insats än att klona Git-arkivet kunna köras och testas av handledare vid inlämning.
Kontakta examinatorn i förväg om din projektidé kräver att extra mjukvara körs, som t.ex. en databasserver eller webserver, eller att extra mjukvara installeras på datorn. Tala om vad som skulle behövas, så får vi se om projektidén kan genomföras eller lite.
Att kräva tillgång till öppet tillgängliga tjänster på nätet är OK, så länge det är tjänster som normalt är "uppe" och fungerar. Om ett speciellt konto behövs, måste du diskutera med examinatorn först.
-
Ni måste kunna visa upp hur ni uppnått målen i just denna kurs. Med andra ord, använd projektet till att lära er mer om just objektorientering, och visa upp i slutresultatet att ni kan utnyttja OO och Java på ett bra sätt. Ni behöver alltså ett projekt där ni aktivt använder (tillräckligt mycket av) klasser, ärvning, polymorfism, inkapsling av information, och så vidare.
Detta går bra i de flesta projekt, så oroa er inte alltför mycket – men ibland blir det för stark tyngdpunkt på annat. Sådana projekt ska undvikas, även om de är roliga och intressanta ur ett "allmänt" programmeringsperspektiv! Ett par exempel:
-
Android-projekt kräver mycket Android-specifik programmering som inte är direkt OO/Java-relaterad. Givet vår erfarenhet från tidigare år avråder vi starkt från detta.
-
Bildbehandlingsfunktioner kräver mycket matrismatematik men kan ge ont om tid till användning av polymorfism, designmönster, osv.
-
Om man inte tänker sig för kan vissa actionspel sluta med alltför mycket manipulering av skärmkoordinater och alltför lite objektorienterad programmering. Det beror till stor del på hur mycket man fokuserar på rörelser, utseende på skärmen, kollisionsdetektering, och så vidare. I de flesta spel kan man istället välja att fokusera mer på de olika typerna av entiteter som behövs i spelet (spelare, fiender, brickor, föremål, powerups, ...), hur man modellerar deras likheter och olikheter (ärvning i vissa fall men inte lämpligt i andra), och så vidare.
-
-
Undvik tidskrävande svårigheter som inte är kursrelaterade. Till exempel:
-
Snygg grafik tar mycket tid. Eftersom detta inte är en designkurs kan vi inte premiera detta i bedömningen. Gör hellre väldigt enkel grafik (om projektet är "grafiskt") och koncentrera er på programmering och OO. Om man vill snygga till det kan man göra det alldeles i slutet, om man ser att man faktiskt hann med de delar som avgör betyget!
-
Snygga animeringar kan ta tid. Låt hellre rörelser förbli en aning hackiga, om de nu skulle råka vara det, och spendera mer tid på OO.
-
Synkronisering över nätverk i realtid är svårt. Det kan vara roligt att implementera ett nätverksspel för flera spelare, men håll er i så fall till brädspel eller liknande. Att utveckla t.ex. ett plattformsspel där spelarnas förflyttningar och andra händelser synkroniseras i realtid över nätet är mycket svårare än man kan tro och kan stjäla veckor av arbetstid. Eftersom detta varken är en nätverkskurs eller en spelkurs är denna svårighet inget vi kan premiera i bedömningen!
-
-
Var väldigt försiktig med externa klassbibliotek och ramverk.
Vi som håller i kursen har tillsammans goda kunskaper om de centrala klassbiblioteken i Java. Om ni vill använda alternativa bibliotek och ramverk är det tyvärr på egen risk. Det kan hända (har hänt) att kursdeltagare får problem med ramverk som inte vill fungera som de borde. Vi kan hjälpa till så gott det går under schemalagd labbtid men vi har inte möjlighet att ta extra tid till detta.
Exempel på klassbibliotek som har lett till problem de senaste åren: Smack.
-
Vissa externa ramverk är verkligen ramverk, i betydelsen att det är ramverket som driver den resulterande applikationen framåt, medan den som använder ramverket ska fylla i hålen och plugga in kod i vissa delar. Smack fungerar uppenbarligen så i viss mån, liksom Androids GUI-system.
Detta är inte acceptabelt i ett projekt. Meningen med projektet är att ni ska driva allt framåt och skapa den grundläggande strukturen för projektet. Ni får använda hjälpfunktionalitet från andra platser, men den ska då vara just hjälpfunktionalitet (funktionalitet som ni anropar för specifika syften).
Välja projekt: Exempel
För de som inte vill hitta på ett eget och helt unikt projekt har vi följande förslag som inspiration, delvis "påhittade" och delvis från projekt som tidigare kursdeltagare har genomfört. De olika funktionerna hos programmen är bara exempel. Välj och vraka, och kombinera beroende på vad ni har tid för och är intresserade av – och ge gärna egna förslag till framtida kurser!
En CPU-emulator där man kan köra små program för en påhittad eller verklig CPU-arkitektur. Här kan man bygga på med fler instruktioner, med visualisering av vad som händer i CPUn i varje steg, med funktioner för att spara och ladda program, och så vidare.
Ett brädspel för två spelare, med nätverkskoppling mellan spelarna. Brädspel brukar inte ha realtidskrav och är därmed relativt enkla att synkronisera över nätet. Detta är en stor skillnad jämfört med actionspel där millisekunderna spelar roll och där det kan vara mycket svårt att få ett konsistent gemensamt tillstånd. Det går också bra att göra en enkel kärna som sedan utökas med att ladda och spara spelpositioner, med animerad flyttning av spelpjäser, med en enkel AI-spelare, och så vidare.
Ett kalenderprogram där användaren kan boka tider. Tänkbara finesser: Visa grafiskt i olika vyer. Kanske drag-and-drop i den grafiska vyn? Sökning. Utskrift av schema. Export till standardiserade kalenderformat.
Ett icke nätverksbaserat grafiskt "actionspel", till exempel ett plattformsspel... dock inte något som är alltför likt Tetris och använder ett liknande rutnät, t.ex. Breakout / Snake. Tänk på att animering, kollisionshantering och liknande kan vara krångligt, särskilt om man inte har hållt på med det förut.
-
Ett grafiskt ZIP-verktyg. Java har inbyggt stöd för ZIP-formatet i paketet
java.util.zip
. Lägg till filer, extrahera filer, testa arkiv, sortera fillistan i olika ordning... -
Ett system för att skapa, visa och skriva ut UML-diagram från existerande Java-klasser, med möjlighet att manipulera diagrammen på skärmen.
-
En Instant Messaging-klient för ett existerande öppet och känt protokoll, till exempel Jabber/XMPP. Implementera gärna allt själv och var försiktig med användning av olika existerande ramverk.
-
En ljuddesigner där man kan skapa ljud med FM-syntes, med grafisk redigering.
-
Ett budgetprogram där man kan hantera konton, transaktioner och en budget.
-
Ett schemaprogram där man kan hålla reda på sitt schema, hitta lediga salar, och så vidare. Det kan hända att man kan använda TimeEdit:s API, men vi har inte testat hur det fungerar eller hur krångligt det är. Annars kan man t.ex. själv exportera från TimeEdit i olika textformat för import till eget schema.
Välja projekt: Extra exempel, främst för TDDD78
Om du går TDDD78 har du mindre tid på dig att välja och utarbeta ett projekt. Då kan du välja att ta emot mer detaljerad inspiration från något av följande exempel. Notera att dessa beskrivningar ska ge just inspiration. De måste inte följas till punkt och pricka, och du behöver vidareutveckla de generella idéerna för att komma fram till ett lagom stort eget projekt!
Även du som går TDDE30 kan välja att inspireras av någon av dessa beskrivningar, men eftersom du har mer kalendertid att fundera på projektet hoppas vi att du verkligen tar tillfället att anpassa det till vad du själv vill göra!
Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2022-02-15