Programmering 101 - vart börjar man?

[krank]

...och det är ju inte så konsigt... och komma igång med enkel spelprogrammering i C# är inte så lätt (det finns säkert någon jätteenkel sandlåda som jag inte känner till).

Raylib finns till C# och det är ju i princip SDL fast enklare. Det är vad jag brukar köra med mina elever; det är inte många rader kod för att få till en enkel game loop.

Däremot är det ju absolut fortfarande ett par steg mindre än Pico-8, och jag avgudar de inbyggda verktygen för att göra grafik, ljud, musik och kartor. Helt genialt.

Jag har övervägt att köra Python som kursspråk istället, bland annat för att det skulle låta mig köra tic80, som ju inte riktigt är lika bra som Pico-8 men fortfarande lättare än mycket annat… Men ja, det är mycket svårt att hitta något som är sådär precis lagom guldlock-bra liksom. Alla lösningar bär med sig sina egna nackdelar.

 

[wilper]

Gränsfall för om det är till någon hjälp men...

För några år sen gick jag tillbaka till skolbänken och läste en kurs i programmering på distans på yrkeshögskola. Det kostade inte mer än någon tusenlapp för kurslitteratur och lite labmaterial. Sedan blev jag matad med uppgifter och fick dessutom en handledare att bolla med.

Var kursen fantastisk? Nä, inte alls.

Hade jag kommit lika långt utan kursen? Förmodligen inte. "Pressen" från labbar och inlämningar gjorde att det rullade på i god takt. Jag skulle mycket väl kunna tänka mig att göra samma sak igen.

Och det måste ju inte vara yrkeshögskola, det finns ju gott om vanliga högskolekurser att läsa på distans också.

 

[adrian_of_arcane_lore]

Ok, det är uppenbart att det ju faktiskt finns en del människor på det här forumet som sitter på kunskaperna och förståelsen som jag vill åt, så först vill jag bara säga tack för att ni är med i min tråd!, det gör mig glad att det inte är 0 svar och syrsor, och sen vill jag bara undra om det är ok att jag ställer en massa säkert jättedumma frågor?

Jag skall försöka förklara lite bättre vad det är jag vill åt, så kanske det också blir lite enklare att svara, för just nu är det lite spretigt.
Men bara för att vara lite tydlig med vad min utgångspunkt är:

Min yrkesmässiga och datatekniska erfarenhet är extremt begränsad och oerhört spretig. I mitt yrkesliv har jag fram tills för lite drygt 3 år sedan knappt ens sett en dator, då jag har jobbat som svetsare och industrimontör från det att jag var 20 år gammal (alltså, lite drygt halva tiden jag vart vid liv). Jag "kan datorer" på det sättet att jag byggt ihop mina egna gamingdatorer, vet hur man installerar en linuxdistro, förstår hur man installerar en crack på en torrent man laddat hem, och kan streama film från datorn till TVn via en media server osv. Men jag har exempelvis aldrig gjort en PowerPoint, tycker excell verkar överväldigande krångligt, har aldrig gjort ens det mest grundläggande på en egen hemsida (eller ens wordpress-mall) mm. Så förutom väldigt specifika och spretiga "gaming och piratkopiering" - relaterade saker kan jag ingenting. Jag har också extremt liten begränsad erfarenhet av att använda programvara som verktyg, exempelvis är program som Photoshop en total "The Matrix" - kod upplevelse för mig, det är som att försöka läsa Rosettastenen med ett svensk-finskt lexicon.

Det jag däremot vet om mig själv, och något jag blivit betydligt bättre på med åren, är generell färdighetsinlärning. Jag har blivit ännu bättre på det sedan jag själv började jobba som lärare (ja, jag jobbar som lärare och har fortfarande inte lärt mig PowerPoint, jag står och skriver och ritar på whiteboardtavlan när jag har lektion, planeringen har jag i huvudet eller i bulletpoints i en anteckningsbok, och jag dokumenterar genom att skriva för hand i en stor bok vad som sker dag för dag och elev för elev, vi är på den nivån här). Jag har rätt god koll på hur jag själv lär mig saker bäst, och jag har lyckats lära mig själv en hel massa saker bara genom att implementera det på mig själv.

Den främsta "skill" jag har lyckats skaffa mig med åren som gjort att jag har blivit bättre på att lära mig saker är att hantera att vissa saker kommer vara tråkiga och ointressanta, och att man behöver jobba på dem ändå för att det sedan kommer leda in i annan färdighet som kan appliceras på sätt som är roliga och stimulerande. Ni skall bara veta hur extremt tråkigt det är att rita mängder med kuber i perspektiv, sitta och måtta proportioner med linjal, teckna fula stilliben på trista objekt utan att lyfta pennan eller titta på pappret, öva på att dra linjer mellan punkter medans man försöker hålla handleden stilla och bara röra armbåge och axel, teckna 100 likadana ansikten osv, men det gör underverk för ens färdigheter som tecknare.
Det är belöningen, man gör det monotona, tråkiga och trista nu, så kan man göra det kul och spännande sen.

Så, helt enkelt, det gör inget om det är tråkigt, jag löser det roliga på egen hand. Det viktiga är att det är nyttigt och att det är grundläggande, att det verkligen är där man börjar när man skall lära sig färdigheten programmering.

När jag själv började som svetslärare på gymnasiet så lärde jag mig en grej som tog mig lite på sängen, nämligen hur svårt det är att lära någon annan något om man själv är väldigt bra på det. Jag har varit svetsare i nära två decennier på en väldigt hög nivå, och har därutöver en avancerad vidareutbildning i ryggen som man inte ens får gå om man inte kan visa upp stabila förkunskaper etc, men jag märkte väldigt snabbt att när jag försökte lära mina första elever om svetsning så förstod de absolut ingenting och jag blev helt paff.

Jag behövde sänka nivån så otroligt mycket att jag på förhand inte ens hade kunnat föreställa mig det. Förklara koncept som vad metall är för någonting, förklara att för att saker skall smälta så behöver de bli varma, beskriva vad elektricitet är, förklara att svetsning används för att saker skall sitta ihop, och då behöver man ju svetsa där sakerna möts, annars är de ju fortfarande lösa osv. Saker som jag själv kanske aldrig ens behövt lära mig, eller som jag liksom glömt bort att jag ens någon gång lärt mig.

Så, det jag vill ha sagt med det:

Förutsätt att jag knappt ens startar en dator, vad är då de första säg 10 stegen för att lära sig programmera och vart hittar man resurser för att komma igång?

Det gör absolut inget att det är tråkigt, repetetivt och ointressant, den roliga användningen kommer jag hitta ändå.

 

[krank]

Jag känner att det här är en sån där sak som jag borde svara på och borde kunna och vilja svara på, men det är två dagar kvar till påsklov och mitt huvud är inte riktigt där idag. Om jag tycker något inte täckts i "vilka är de 10 första stegen"-ämnet när jag lugnat nr mig lite (säg, till helgen) så återkommer jag med… möjligen ett par olika 10-första-steg.

sen vill jag bara undra om det är ok att jag ställer en massa säkert jättedumma frågor?

Det finns inga dumma frågor, och vi svarar jättegärna på dem.

Så länge du är beredd på att vi kommer med diametralt motsatta svar som inte hänger ihop med varandra. För det är så det brukar funka oavsett vad man frågar om =)

 

[Troberg]

En liten varning om Godot: Jag började titta lite på den (men sedan blev jag distraherad av något roligare projekt), och den är ganska olik andra programmeringsspråk. Det kan vara bättre att börja med något mer "typiskt" som förstaspråk, för att undvika att dra på sig dåliga vanor som blir svåra att göra sig av med.

Mitt standardtips på första program att skriva är en liten todo-lista i Windows. Det är ganska enkelt, men kräver ändå ett enkelt gränssnitt, filoperation, interaktion. För mig tar det en timme eller två, men för en nybörjare tar det kanske några dagar. Det är också ett projekt man kan bygga ut i evighet. Börja med en lista med grejer man kan bocka av. Kanske lägga på en beskrivning? Deadline? Varning när deadline närmar sig? Storleksskattning på uppgifterna? Olika sorteringsordningar? Snabbknappar? Status (ej påbörjad, pågående, pausad, klar)? Kanske dela upp dem i kategorier? Varför inte visa kategorierna i ett hierarkiskt träd? Kanske dags att använda en databas för lagringen? Kanske bygga en web-frontend? Anteckningar på varje todo-item? Spela ett glatt ljud när du bockar av en sak?

I princip, lägg till vad du kommer på, och du kommer att lära dig på varje sak.

En annan fördel är att det är ett program som du iofs kommer att kunna ha viss nytta av, men det är ändå klart från början att det inte kommer att vara ditt "Magnum Opus", så du vågar riskera att göra fel.

Var inte rädd för att fråga ChatGPT om du kör fast, den kan ge dig en bra primer för att komma igång med ett nytt område. Jag har programmerat i 40 år, och använder den ändå när jag ska göra något nytt (senast att programmatiskt mata ut en USB-enhet). Dock: kopiera inte bara in koden. Läs den, förstå den, och skriv din egen variant, enligt din egen kodstandard. Se ChatGPT som en kollega man frågar om råd, inte som facit.

En sak som jag har märkt, dock, är att människor har olika svårt för att tänka i två tider samtidigt. Och med det menar jag att programmering har ett NU, när du skriver programkod, och ett SEDAN, när programkoden utförs av datorn. För olika elever har detta varit olika svårt. För en del närmast omöjligt och för en del helt självklart att se kopplingen mellan vad de gör NU och vad som kommer att hända SEDAN.

Och nästan ingen tänker i tre tider samtidigt, dvs när skiten ska underhållas om tio år, eller skrivas om helt om 30 år.

För många år sedan så tvingade jag utvecklarna i ett projekt att "skriva dokumentation som om de skulle skriva om systemet och hade fått total minnesförlust". Det var inte populärt. 25 år senare, så kom en av dem och sade "Tack för att du tvingade oss att dokumentera, jag kommer inte ihåg ett skit av det här!".

Programmering är så mycket mer än att bara få till något som funkar nu. Det ska vara kod som går att underhålla, den ska vara robust (tex undvik tredjepartskomponenter som kan sänka den om de ändrar något). Den ska vara trevlig att läsa. Den ska vara enhetlig. Man behöver ha en plan innan man börjar knacka kod.

 

[entomophobiac]

Förutsätt att jag knappt ens startar en dator, vad är då de första säg 10 stegen för att lära sig programmera och vart hittar man resurser för att komma igång?

En följdfråga på det är: vill du lära dig göra spel eller lära dig programmera?

Dessa två är relaterade, men de är inte samma sak. I synnerhet inte idag, när du kan hoppa över många av de grundläggande stegen för att nå "göra spel" fortare.

 

[adrian_of_arcane_lore]

En följdfråga på det är: vill du lära dig göra spel eller lära dig programmera?

Dessa två är relaterade, men de är inte samma sak. I synnerhet inte idag, när du kan hoppa över många av de grundläggande stegen för att nå "göra spel" fortare.

Såhär, för att vara tydlig:

Jag vill lära mig programmera för att kunna göra spel, bland annat, men på ett sätt som om jag skulle känna för det i framtiden att jag vill utöka mina kunskaper för att göra annat.

Exempelvis, jag har redan suttit och följt lite youtube-tutorials och läst på om Godot, jag fattar principen och tankesättet. Man jobbar med träd av noder som gör olika saker, varje nodträd är en egen scen som man fyller med funktioner (sprites/modeller, kollisionsytor, timers, animationer och whatnot), sedan plockar man in scenerna i större scener och så interagerar allt med varandra och så blir det ett spel.

Jag har satt ihop lite saker utifrån instruktioner, ändrat lite grejer och experimenterat fram och tillbaka och fått resultat som skiljer sig från förlagan. Från den punkten så är det, om man har en uppfattning om hur inlärning funkar generellt, inte så jättesvårt att veta hur man går vidare för att lära sig mer. Jag kan observera vad jag kan, och förstå vägen framåt, samt hyfsat på egen hand föreställa mig vad jag behöver lära mig mer om. Just i detta är det ju att lära mig mer om vad de olika noderna gör och kan göra, lära mig mer om synergierna mellan dem, studera exempel på hur andra har löst saker (exempelvis "hur man skapar en spelar sprite i 2D och ger den ett system för att röra sig runt i spelet, samt hur man bygger ut det systemet"), och sedan remixa och experimentera osv. Sedan ta det därifrån.

Där jag stöter på patrull är ju när man skall gå in i script och göra, tja, någonting alls.
Jag har skrivit en del i scripten (alltså, följt det dom säger i tutorialen att jag skall skriva) och det som de säger skall hända har hänt, jag har ingen aning om varför, och när något blivit fel har jag inte ens en uppfattning om vad det överhuvudtaget skulle kunna vara. När det kommer till programmeringsbiten av spelskapandet är det som att alla instruktioner som finns att följa släcker lampan och någon ropar i mörkret "ta ett steg framåt, sedan ett litet steg till vänster, sedan ett 43 cm långt kliv i 16 graders vinkel framåt åt din höger, sedan 14 halvsteg bakåt och sedan är du framme", för att sedan förvänta sig att man hittar tillbaka eller ens förstått vart man gått. Instruktionerna betyder inget, för jag kan inte relatera informationen till någonting jag känner till, det påminner inte om någonting annat jag har gjort, jag har ingen tidigare erfarenhet att applicera där jag liksom kan lista ut vad det jag gör innebär, det finns ingenstans där det går att tänka "ah, detta är ju ändå ungefär som den här andra saken".

Och det går säkert att göra spel helt utan att lära sig att programmera eller skriva kod, men jag vill ju lära mig programmera och skriva kod. Dels för att göra spel men också bara för dess egen skull, för det är en intressant kunskap och färdighet och jag är intresserad av kunskaper och färdigheter i sig.

Det är som att vilja lära sig gå på lina, det gör man ju inte "för att" någonting utan bara för att utmaningen i sig är stimulerande och färdigheten är kul att ha.

 

[Frederik J. Jensen]

Take a look at Codepad (https://helloworldsweden.github.io/Codepad-Space_Cleaner/). It's an online editor/compiler/game engine using Lua scripts against a Defold game engine underneath. It very quickly gives you a taste of what it means to create a game and tweak it to your own taste.

 

[zo0ok]

Jag tänker så här: när man använder en dator så säger man till datorn att göra en sak (formattera hårddisken, radera en fil, öppna en webläsare), så väntar man på datorn, och så är det du igen. När du PROGRAMMERAR en dator så sätter du upp en mängd instruktioner, på ett strukturerat sätt, så att datorn kan göra nya saker, eller gör saker automatiserat - på det sätt du berättat för den.

------ 1 ----
Eftersom du har installerat Linux...

Om du skriver
$ date

Så berättar den för dig vilket datum det är, och vilken tid det är.

Om du skriver
$ while true; do; date; sleep 1; done

så berättar den datum/tid för dig varje sekund.

Du har alltså i detalj beskrivit för datorn EXAKT VAD och EXAKT HUR den ska göra något.
Du har gjort ett PROGRAM för datorn.

--- 2 ---
För den som är datavetare på ett universitet så är "dataprogram" en teoretisk vetenskap.
Det handlar om abstrakta begrepp, matematik, algoritmer, datastrukturer, osv.
Att kunna sånt gör dig till en bättre programmerare. Men alla programmerare behöver inte kunna allt.
(du kan nog relatera som svetsare - ju mer olika saker du kan desto bättre kan du göra ett visst jobb - men en mindre erfaren svetsare kanske också kan lösa det, på ett enklare/annat/sämre sätt)

Den som arbetar som programmerare skapar/skriver/programmerar olika saker: affärssystem, mobilapplikationer, webbsidor, spel, styrprogram till diskmaskiner, osv. Alla programmerare har nytta för en del abstrakta saker man lär sig om man studerar datavetenskap, men inte för allt.

Du kan alltså "lära dig programmera" från två håll: lära dig teoretisk grundkunskap, eller genom att lösa konkreta problem och skriva faktiska program. I praktiken bör du göra båda samtidigt - fast inte exakt samtidigt.

--- 3 ---
När det gäller programspråk så finns det dussintals om inte hundratals.
I huvudsak fungerar alla på samma sätt och kan göra samma sak.
Fast vissa är mycket mer eller mindre lämpliga till vissa uppgifter.
(på samma sätt alla klister/lim göra samma sak - men är lämpliga till helt olika uppgifter)
Det finns liksom inget språk som är "bäst".
Däremot finns det en stor mängd språk som du antagligen inte bör titta på alls om du ska göra precis vad just det språket är bäst till.

Om du vill lära dig programmering från det teoretiska/vetenskapliga hållet så kan du titta på språk som C, Haskell, Lisp.

Om du vill lära dig göra något specifikt (skriva ett spel) så bör du välja ett språk och en "miljö" som är så enkel/tillgänglig att du inte kör fast och ger upp. Då skulle jag rekommendera att du försöker med MiniScript och MiniMicro. Även om MiniScript är helt oanvändbart till något annat, så är inget förlorat om du lär dig MiniScript först. Men om du vill skriva applikationer som körs i en webbläsare så är det helt andra språk som gäller.

--- 4 ---
Programmering är roligt!

Om du programmerar en dag så kör du fast flera gånger, och sedan löser du ditt problem flera gånger, och varje gång får du en endorfinkick.
Det är oerhört belönande - nästan beroendeframkallande.
Men det är inte roligt att sitta en hel vecka och inte komma fram alls.
Och det är inte roligt att vara understimulerad.

Men, att lära sig programmering är roligt och ska vara roligt.
Även om man blir förbannad och frustrerad - men det behövs för att man ska känna sig glad och "belönad" när det funkar.

--- 5 ---
Ett fungerande dataprogram är som insidan av en Rolex-klocka.
Alla detaljer är omhändertagna och inget är lämnat åt slumpen.
Datorn och dess operativsystem har hundratals bollar i luften, plockar ner precis varje boll med full precision varje gång.

Om du skriver ett word-dokument så kan du inte skriva utanför marginalerna. Även om du stavat fel, och även om dokumentet du skriver mest innehåller rappakalja och strunt, så är det ändå ett 100% giltigt word-dokument - det ser Word till.
Programmering är tvärt om. Varje tecken i varje rad kod, är avgörande för att programmet ska fungera korrekt, eller ens gå att köra alls.

Det dunkelt sagda är det dunktelt tänkta - programmering är helt skoningslöst mot dunkelt tänkta saker - och dunkelt skriven kod.
Det finns liksom inget "den här meningen är lite otydligt, men det framgår nog av sammanhanget". Datorn gör EXAKT det du skriver.

--- 6 ---
De mekanismer som (nästan) alla programspråk har, och som du behöver känna till, oavsett, är

konstanter, variabler, parametrar : värden på saker
villkor : om något villkor är uppfyllt så gör något, annars gör något annat
repetition : gör (ungefär) samma sak flera gånger
datatyper : en STRÄNG kan innehålla ett namn, ett NUMMER kan innehålla ett belopp, osv
metoder, funktioner : detta är en liten namngiven programsnutt som kan återanvändas, precis som ett kommando (ls, rm) i Linux
objekt, listor, strukturer : när man börjar jobba med riktiga problem så måste man kunna organisera, gruppera och klumpa ihop data

...jag har säkert glömt något viktigt...

Detta är saker nästan alla programmerare, alla problem, alla programspråk, behöver ha koll på.
Och det fungerar ungefär på samma sätt i alla språk (det finns såklart exotiska undantag).

Detta är bra saker att öva på hackerrank.com med Python.

--- 7 ---
Komma igång.

Om du har en Linux-dator kan du sätta igång direkt.
Du kan skriva
$ python (eller python3)
och experimentera.

Men det bästa är nog att hitta någon "skyddad verkstad" som du kan experimentera i.
En sådan skyddad verkstad har tydliga begränsningar och det är både bra och dåligt.
I ditt fall är det mest bra.
Flera sådana har nämnts i tråden ovan - inte minst för spelprogrammering.
Jag nämner hackerrank.com igen, men det finns många alternativ.

En annan "skyddad verkstad" är att installera Xcode på en Mac och börja skriva appar för iPhone/iPad.
Apple ger (vad jag vet) ut gratis-böcker som är bra.

Vad som INTE är en skyddad verkstad är web-programmering. Det är ganska stökigt - enkelt rent programmeringsmässigt, men mängder av olika saker att ha koll på.

---- 8 ----
"Programmerare" är väl ungefär som "snickare".
En snickare kan bygga en bokhylla eller ett bord, men inte ett hus.
Det kräver mer kunskaper. Det hindrare inte att en person kan bygga ett hus själv, men då är man inte bara snickare.
Samma sak med programmerare.

---- 9 ----
Som någon nämnde ovan, du kommer få olika svar beroende på vem du frågar.
Programmerare är väldigt sällan överens och blir ofta oense eller ovänner för att de tycker olika.

Vad som är rätt och fel kan "bero på".
Det som är "rätt" när du skriver ett spel kanske är "fel" när du skriver en websida.
Många vill komma med lösningar innan de förstått problemet.

Vad som inte "beror på"...
Bra kod fungerar och bra kod är relativt enkel att ändra.
Kod som inte fungerar felfritt eller inte är relativt enkel att ändra... är dålig kod.
Det är inte en fråga om tycke och smak.

---- 10 ----
Skriv kod. Läs andras kod. Ändra kod. Öva. Repetera.
Trots ChatGPT och avancerade hjälpmedel, så är programmering som att spela piano.
Det kräver övning, övning, övning, övning.

Allt som är "lagom" svårt är bra övning.
Som styrketräning - för lätta eller för tunga vikter är inte bra.


----------------
Det blev i varje fall 10 råd.

 

[entomophobiac]

Jag vill lära mig programmera för att kunna göra spel, bland annat, men på ett sätt som om jag skulle känna för det i framtiden att jag vill utöka mina kunskaper för att göra annat.

Jag brukar beskriva spelutveckling som en kombination av ett antal pusselbitar (följande är del av det vitsigt döpta "Fundation"-materialet). Tål att nämnas att detta är med utgångspunkt från "gameplay" och därför inte inkluderar lågnivåsaker, som rendering eller plattformsinstruktioner. Det inkluderar heller inte alla osynliga men svinviktiga saker du måste göra för att släppa ett spel, såsom översättning till olika språk eller stöd för olika input.

Se det som en överblick av problem som behöver lösas för att göra spel, "high level".

3Cs (Controls, Camera, Character): hur kontroller hanteras, vad spelaren gör, vilken feedback som genereras, etc. 3Cs är egentligen en Ubisoftterm från början, men idag är det också vanligt som yrkesspecialisering även på andra ställen.

Data: hantering, konvertering, och manipulation av data. Alla dina 3D-modeller, bilder och ljudfiler, men också MoveSpeed, props, info, text, och så vidare. Ett bra sätt att externalisera data är viktigt.

Collision: allt från enkla geometriska algoritmer (e.g., Intersection Tests) till stora komplexa licensierade fysikmotorer. Det här är en sån sak som jag egentligen tycker alla som gör spel bör kunna något om. Mycket för att vissa av de här algoritmerna är galet enkla men otroligt användbara även i sammanhang som inte har med faktisk fysik att göra.

Spawning: att skapa objekt på ett förutsägbart sätt. Går ju in i minneshantering också, men i en modern spelmotor är det sällan du behöver skriva resurshantering själv.

Behavior: har alltid kallat detta AI förr, men det vilar en förbannelse över den förkortningen idag som medför att alla tror det innebär ChatGPT. Men det handlar egentligen om sex beståndsdelar som kan kombineras för att ge typ alla digitala spels olika "fiender": Knowledge, Steering, Decision-making, Awareness, Perception, och Locomotion.

Interface: mycket mer av en arkitekturgrej än de flesta är villiga att erkänna. Allt från menyer till effekter egentligen.

Polish: att det som händer känns bra. Disneys tolv animationsprinciper egentligen, med tweening, squash/stretch, och så vidare. Finns massor med riktigt kraftfulla tekniker (som easing functions) att använda sig av för att ge det där lilla extra till all spelinteraktion.

 

[Troberg]

Jag tänker så här: när man använder en dator så säger man till datorn att göra en sak (formattera hårddisken, radera en fil, öppna en webläsare), så väntar man på datorn, och så är det du igen. När du PROGRAMMERAR en dator så sätter du upp en mängd instruktioner, på ett strukturerat sätt, så att datorn kan göra nya saker, eller gör saker automatiserat - på det sätt du berättat för den.
(snip)

Mycket bra inlägg, jag kortade det lite av utrymmesskäl.

Ett par tillägg:

* Jag brukar beskriva ett program som ett matlagningsrecept. Ta det här, gör det här med det, blanda med det här, värm så länge på den här värmen, osv.

* Man behöver ha lite pitbull-mentalitet. Man kommer att hamna i situationer där man bara vill defenstrera datorn, och det enda man kan göra är att bita tag i problemet och ruska det tills det ger upp.

När det gäller programspråk så finns det dussintals om inte hundratals.

Definitivt närmare tusentals än hundratals. Jag har använt över 30 (och hatar ungefär hälften av dem...). Alla programmerare med några år på nacken har åtminstone gjort ett enkel scriptspråk själv...

 

[adrian_of_arcane_lore]

Då skulle jag rekommendera att du försöker med MiniScript och MiniMicro. Även om MiniScript är helt oanvändbart till något annat, så är inget förlorat om du lär dig MiniScript först.

Då tittar jag på det och börjar i den änden, jag tänker att tar man sig igenom grejerna här så borde det vara en vettig start eller?

Om du programmerar en dag så kör du fast flera gånger, och sedan löser du ditt problem flera gånger, och varje gång får du en endorfinkick.

Ja, jag tror det jag behöver helt enkelt är någonstans att gå igenom grunderna, och sedan hitta just problem att lösa (gärna där det finns ett facit tillgängligt så om jag verkligen inte fattar vad som händer så kan jag reverse-engineera svaret och sedan försöka igen själv istället för att famla i mörker och försöka googla utan att ha en aning om vad jag ens skall skriva i google).

Detta är saker nästan alla programmerare, alla problem, alla programspråk, behöver ha koll på.

Perfekt! Då vet jag i vart fall mer än innan vad jag behöver lära mig saker om.
Jag har försökt gjort en del kodövningar redan, men då har det dykt upp "skriv in <den här> variabeln", "skriv <den här> funktionen" utan att på ett bra sätt förklara vad en variabel eller funktion är, vad de används till, hur man känner igen dem, varför man använder dem vid just de tillfällena, när den ena är mer lämplig än den andra, när de påverkar varandra och på vilket sätt osv osv. Ctrl+V Ctrl+C av rader med kod kan vem som helst göra, men det lär man sig ju ingenting på.

Men det bästa är nog att hitta någon "skyddad verkstad" som du kan experimentera i.
En sådan skyddad verkstad har tydliga begränsningar och det är både bra och dåligt.
I ditt fall är det mest bra.
Flera sådana har nämnts i tråden ovan - inte minst för spelprogrammering.
Jag nämner hackerrank.com igen, men det finns många alternativ.

Ja precis, det är ju exakt det jag är ute efter, för det är vad jag tror att jag behöver!
Just nu antar jag ju bara att man lär sig programmering på ungefär samma sätt som man lär sig den mesta andra färdighetsinlärningen. Att man lär sig genom grundläggande repetition av enklare övningar med någon sorts instruktion eller handledning, sedan går man in på mer avancerade övningar där man både applicerar tillskansade kunskaper samtidigt som man tar till sin nya. Sedan, när man gjort det, börjar man skapa egna enklare projekt som både tar avstamp från vad man kan och kommer med nya utmaningar, så löser man dessa nya utmaningar och jobbar sig steg för steg upp mot djupare och mer komplex färdighet osv.

Det är ju så jag lär mina elever att gå från totalt "aldrig någonsin ens sett ett verktyg" till yrkesmässigt kompetenta svetsare, det är så jag har lärt mig allt jag på någon nivå kan (eller har kunnat), från att cykla till att spela fotboll eller boxas eller teckna eller vad det nu kan vara. Jag inbillar mig iaf att man lär sig programmera på ungefär samma sätt.

Så jag behöver nog en skyddad verkstad där det både finns utmaningar och instruktioner, eller i vart fall en bra verkstad att vara i, någonstans där man kan hitta utmaningar att göra, och någonstans där man kan få bra instruktioner, så kan jag bygga ihop lärandet rätt ok sen.

Hackerrank är ju säkert jättebra, men jag förstod verkligen ingenting av hemsidan när jag gick in där. Det stod massor om att söka jobb, och om priser, och om certifieringar, men jag tror inte jag fattade innebörden ens av en bråkdel av det som stod på sidan. Har du något specifikt tips på vad man faktiskt skall göra på Hackerrank om man är nybörjare?

Jag skall kolla in flera av de tips jag redan fått i tråden, och är supertacksam för all hjälp. Tack för ett mycket bra inlägg!
En del av tipsen känns dock spontant som att lära sig simma genom att hoppa in i mitten av poolen eller lära sig boxas genom att direkt börja med sparring. Det går säkert att göra, och är förmodligen oerhört bra att komma igång med, men är man på nivån "absolut precis nybörjare som behöver lära sig de mest grundläggande grunderna från början" så gör det liksom ingen skillnad, man sjunker eller blir knockad ändå.

Grunden i att lära sig simma eller boxas handlar liksom inte om hur man skall röra armarna och benen för att åstadkomma vissa saker (inte drunkna, inte få smäll), utan grunden är att man måste göra det och vad syftet är, sedan när man lärt sig de grundläggande principerna om hur det hela går till och vad poängen med det är, kan man börja testa olika rörelser bara för att se hur de fungerar, sedan kan man gradvis applicera detta på en mer och mer realistisk situation, och sen kan man testa den grunda pooländen eller röra sig runt i ringen och slå på mitsar osv.

Ja ni fattar, jag står liksom utanför badhuset och vet inte ens vart man hittar ingången, vi är långt ifrån "testa själv" här.

 

[zo0ok]

Då tittar jag på det och börjar i den änden, jag tänker att tar man sig igenom grejerna här så borde det vara en vettig start eller?

Testa och se hur det fungerar för dig.
Det matchade ju tämligen väl min punkt 6.

Syftet med dessa övningar är att kunna instruera datorn (Mini Micro) vad den ska göra.
Så att du kan beskriva/programmera ett spel.

När du senare ska försöka skriva ett spel så behöver man exempelvis:

Branching: har spelaren tryckt på joystickknappen - i så fall gör något. Börjar tiden ta slut - i så fall spela något hotfullt ljud. Har spelaren dött - gå tillbaka till menyn och avsluta eller börja ett nytt spel.

Looping: det kanske finns 5 motståndare i spelet. Då vill man inte skriva samma kod 5 gånger, utan kunna göra samma sak för varje motståndare. Sådana här spel är ofta gjorda så att det händer lite varje "frame". Så då har man en evighetsloop som gör allt som händer under en frame, och sedan gör man samma sak i nästa frame och nästa frame.

Datatyper: String kan hålla spelarens namn, eller meddelanden (vill du spela igen?), osv. Nummer håller ofta positionen för något (spelare, motståndare) på skärmen som två koordinater x och y.En lista kan till exempel vara alla motståndare. Eller en hi-score-lista. Eller en lista på vapen man kan köpa.

Operators: fundamentala byggstenar i kod. Ungefär samma i alla språk. Enkla saker som att kunna göra plus eller minus. I program är det också logiska saker som AND och OR. Det kan betyda att spelet tar slut om "tiden är slut ELLER livspoängen är slut".

Functions: man måste liksom dela upp sitt program i olika delar. Funktioner är en bit kod som gör något. Kan vara updateHighScore, shootAtEnemy, makeMove, den typen av saker. När du väl kommer till att skriva spel/grafik/ljud kommer det finnas funktioner för att rita grafik och bilder, för att spela upp ljud, för att kolla joystickens läge. Så du behöver inte fundera på HUR man ritar en cirkel, bara bestämma var du ska rita den och vilken färg den ska ha.

Classes and Objects: en motståndare kanske har ett antal egenskaper. Typ:Orch, HP:10, AC:6, THAC0:18, Damage 1d6. Dessa "paketerar" man då under ett objekt. Så varje motståndare blir ett eget objekt. Så är det fem orcher på spelplanen så är det 5 objekt (typiskt i en lista). Dessa objekt kanske alla tillhör en klass (kanske Enemy).

Håll detta i åtanke när du gör övningarna.
Du behöver förstå allt. Kör inte fast. Om du inte vet vad cosine är, eller vad de menar med Map, eller du tycker isa eller address-of verkar vara konstiga operatorer, skit i det.

 

[zo0ok]

och det enda man kan göra är att bita tag i problemet och ruska det tills det ger upp.

Och ibland är det bästa att göra något helt annat, så plötsligt löser man problemet i huvudet när man minsta anar det.
Att sitta och grubbla framför skärmen är inte alltid så produktivt.

Definitivt närmare tusentals än hundratals. Jag har använt över 30 (och hatar ungefär hälften av dem...). Alla programmerare med några år på nacken har åtminstone gjort ett enkel scriptspråk själv...

Ja, med dussintals menade jag väl i första hand språk som är relevanta inom näringsliv eller universiteten idag. Det finns ju säkert 100 utdöda BASIC-dialekter!

Tror inte jag skrivit något skriptspråk. Men jag har implementerat andra dumma saker själv.

 

[Stämma]

Jag är en klåpare till programmerare, så ska kanske inte försöka ge råd egentligen, men när jag tog mej in i fältet började jag med Harvards CS50, som jag kan rekommendera. Det är väl egentligen nån sorts kurs, men jag lyssnade bara på föreläsningarna och gjorde övningarna utan att registrera mej eller så, och det räckte nog så väl.
Det är en pedagogisk genomgång av datalogiska grundämnen och lägger en skapligt solid grund för att sen utveckla kunskaperna vidare själv.

 

[Troberg]

Och ibland är det bästa att göra något helt annat, så plötsligt löser man problemet i huvudet när man minsta anar det.
Att sitta och grubbla framför skärmen är inte alltid så produktivt.

Japp. Det är därför jag tycker bättre om programmering som hobby. Då kan man gå och låta ett problem mogna. Jag behöver inte lösa det nu, jag kan lägga det åt sidan en månad och lösa det när jag kommer på något smart.

Ja, med dussintals menade jag väl i första hand språk som är relevanta inom näringsliv eller universiteten idag. Det finns ju säkert 100 utdöda BASIC-dialekter!

Och antagligen 100 som används aktivt också...

 

[adrian_of_arcane_lore]

Det är en pedagogisk genomgång av datalogiska grundämnen och lägger en skapligt solid grund för att sen utveckla kunskaperna vidare själv.

Låter superintressant, skall spana in det!

 

[Lemur]

Här är mina 5 korvören.

Strunta i allt du hör om att språk X är kasst och att man ska köra språk Y. Godot och GDscript är toppen, bara kör. Kan man ett språk (vilket det än må vara) kan man enkelt ta med sig den kunskapen till nästa. Språken är mer lika än olika.

Jag vill också tipsa om en underskattad gratis spelmotor som jag tycker är kul att pilla med, som har inbyggd pixel-editor och som kör i din browser:

microStudio - Game Engine

microStudio is a free, open source game engine, easy to learn and packed with features. It offers 4 programming languages and includes a sprite editor and a map editor.

microstudio.dev

 

[entomophobiac]

Strunta i allt du hör om att språk X är kasst och att man ska köra språk Y. Godot och GDscript är toppen, bara kör. Kan man ett språk (vilket det än må vara) kan man enkelt ta med sig den kunskapen till nästa. Språken är mer lika än olika.

Detsamma gäller spelmotorer. Den bästa motorn är den där du får saker gjorda. Om det är GameMaker eller Unreal eller en motor du skrev själv genom att offra femton år av ditt liv är närmast helt oväsentligt.

 

[Frederik J. Jensen]

But of course you will not be a true programmer before you have your own pet language and tools and know how to trash talk their nearest competitors…