IT-Universitetet i København
 
  Tilbage Kursusoversigt
Kursusbeskrivelse
Kursusnavn (dansk):Programming for Game Designers 
Kursusnavn (engelsk):Programming for Game Designers 
Semester:Forår 2014 
Udbydes under:cand.it., spil (games) 
Omfang i ECTS:7,50 
Kursussprog:Engelsk 
Kursushjemmeside:https://learnit.itu.dk 
Min. antal deltagere:12 
Forventet antal deltagere:20 
Maks. antal deltagere:30 
Formelle forudsætninger:The course is an introduction to the basic concepts of computing and programming using a general purpose language such as Processing. It is intended for a general audience with no prior programming experience, and taught with an emphasis on graphics and user interaction.
As an introductory course, there are no prerequisites. Except a wild curiosity and the willingness to learn a challenging but rewarding skill! Please come up with three things you think computers are good at for our first meeting. 
Læringsmål:Successful participants will be able to
∙ Acquire basic competence in the chosen programming language
∙ Apply this language to simple tasks using good programming techniques
∙ Demonstrate an understanding of fundamental principles of program design
∙ Design and implement programs as well as read and understand existing programs
∙ Demonstrate an understanding of analysis, design and application of a range of basic algorithms
∙ Write and use custom-made programming functions
∙ Acquire skills in problem solving using given tools, steps and strategies, problem analysis, program development, testing and documentation 
Fagligt indhold:Programming for Designers 2014 Spring Creating Interactive Systems

Motivation
We program to create interactive systems. This is the only reason to do it. (There might be one or two other reasons, but for this course, I suggest to focus on interaction.)
Not limit yourself to use what somebody else has done, but to take control and create yourself what nobody has done before! I believe the most interesting things to create are interactive systems. That is, not use the computer as a tool to do what we have been doing already, e.g. painting pictures or cutting movies, but to interact with it in novel, provocant, and playful ways.
Being able to program is the only way to seriously create such systems, to have full control, to even know what to ask and look for in tools and engines. In short, to be able to use a computer to its full extend means to know something about programming. This is what the amazingly successful computer phenomenon is about; the digital revolution is an algorithmic revolution, and not about storing data, speed, 3D graphics or communication, but about interaction.
If you have not done any programming before, it will take a few weeks to get into this mode of thinking, understand how computers work, recognize and use the handfull of constructs, move to object-based programming, finally implement a basic multiplayer game. This course offers an interesting change of perspective, and you will see the world of digital media in a different way.

Semester Plan (Preliminary, and subject to change)
Week 1 Lecture: Motivation, paper structure, a short history of computing/programming
Week 2 Lecture: Code basics (syntax, commands, variables)
Week 3 Lecture: Math, conditions, loops
Week 4 Lecture: More loops, arrays, functions, common errors
Week 5 Lecture: Objects and object-based programming, time, motion 1, collision
Week 6 Lecture: Vertices, polygons, patterns
Week 7 Lecture: Curves, arcs, Bézier; how to read API documentation
Mid-semester break 1 week
Week 8 Hand-in before the
Presentations: Exercises 1–28
Week 9 Lecture: Form, color, recursion
Week 10 Lecture: Motion 2 and matrix operations
Week 11 Lecture: Interactivity
Week 12 Lecture: System events
Week 13 Work on exercises
Week 14 Final hand-in before the
Presentations: Exercises 29–35
Course feedback collected

Daniel (dace@itu.dk), 31.5.2013 
Læringsaktiviteter:14 ugers undervisning bestående af forelæsninger og øvelser

The Processing programming language is used to get a first overview of fundamental programming techniques. Teaching time will be divided between lectures, tutored sessions and presentations of students' solutions. All lectures will be complemented by practical programming assignments, some of which will be small and clearly focussed (at the start of the semester), while others will be more open to artistic or playful interpretation (towards the end of it); all will be done individually except the last one which is done in teams. Participants are asked to manage their own time; the exercises are divided into groups, usually including a mix of approaches, requirements and techniques. Participants will go through cycles of learning something and using it for cool stuff; then learning some more, and using that; the cycles get bigger and more challenging during the semester.
I recommended to get a (hard- or digital) copy of the well-known Processing book by Reas, Fry (2007). The course loosly follows it, and I find it well-written and reasonably easy to understand. There are several other Processing books available, e.g. by Greenberg (2007), Shiffman (2008), Noble (2009), and Bohnacker et al. (2012), which I find not as well-suited to our introductory course (but do what works for you).
Every week there is a lecture; the exercises are introduced and explained. After the lecture everybody can work on the exercises in the lab. At the end of each day participants are asked to present something they have done on that day. 

Obligatoriske aktivititer:Assessment is based on course work assignment and examination. 35 practical programming exercises accompany the lectures of the course, i.e. 27 small ones and eight big ones (marked with a •). All big exercises must be successfully done to pass the course and are assessed summatively. However, the small exercises are the road to the big ones, and it might be hard to get on with the big ones without having done the small ones. The big exercises are worth 10–40 points. A total of 15 extra points can be gained as a bonus for execptionally well thought-out artistic or playful solutions plus 15 extra points for the bonus exercise 25.
As this is a skill-based technical course, the main criterium for assessing your work is demonstrated understanding of programming concepts (this is e.g. done by skillfully writing code, but also by presenting your solutions and explaining them); further relevant criteria which are clearly connected to that are active participation and constructive criticism in discussions, asking interesting and relevant questions, doing the assigned exercises and handing-in the material that is asked for on time, managing your time to arrive at good results, being able to talk about your work, support peer learning, and being receptive to new ideas and willing to learn.
Some general remarks about the exercises:
1. All exercises must be done individually, except exercise 35 which is to be done in two-person teams.
2. It is possible to use other people's code but you have to state where you have used it and demonstrate your understanding of the principles and function of the code through comments which you have made yourself. If you don't understand the code you can't use it.
3. All exercises can be done at any time before the final hand-in date. However, it is advised to do the exercises in the assigned time slots as the lectures and the exercises are connected and build on each other. Having the exercises ready for the presentations during the semester will enable you to participate fully in the discussions in the lectures, to ask specific questions in the lab sessions, and to get feedback about your work.
4. Put your programs on an USB stick for the presentations; everybody will only have a short time to present his/her work. Be able to point out and explain the key aspects and problems of your solutions. Answer questions about your work.
5. Structure your code well. Follow the guidelines below. 'Programs must be written for people to read, and only incidentally for machines to execute.' (Abelson, Sussman 1985:xv qtd. in Dourish 2001:214)
6. Exercises 1–28 are due before the first class after the mid-semester break, the rest of the exercises at the end of the semester (i.e. on the last day of class). Participants receive written feedback about their performance. Verbal feedback will be given throughout the semester at presentations.
7. Collect your works on CD for submission. Each CD must be clearly labelled with the name and student ID number of the submitting student; CDs without name will not be accepted.
8. On the CD put each exercise in its own folder clearly and appropriately named (e.g. exercise01 to exercise35); CDs without a proper directory structure will not be accepted.
9. Students may keep and submit journal entries outlining their work in addition to the CD if they so desire. This is optional.
10. If I am unsure about your understanding or I perceive a huge discrepancy between your performances in class and hand-in (as I may have not seen you participating actively in the lectures, lab sessions and presentations) I might want to talk to you for a few minutes and have you explain your work to me.
If you are unsure what is asked for in the exercises, please ask. The exercises are normally slightly modified from the examples in the book, so do not copy the solutions from the book. Do not repeat the exact same code in several exercises; usually this is not asked for. Demonstrate and focus on the aspects the exercises require, these might be slightly different from what you already know how to do, and what is explained in the lecture. Try to make a statement, do something that means something, be different – a chequered green elephant with two trunks which can play Scottish folk tunes is likely to get more attention (and a better grade) than the 37th little grey donkey (if the elephant can indeed play music, and not just look weird). 
Eksamensform og -beskrivelse:X. experimental examination form (7-scale; external exam), 7-trins-skala, Ekstern censur

Exercises Week 2–3
1. Write three comments in Processing. All following programs must have meaningful (non-trivial) comments that explain the big picture of what is going on.
2. Write these same comments as a multi-line program header. All following programs must have a header.
3. Write a program which will produce a 640x480 pixel display window with a black background.
4. Use print() and println() to write some text to the console [Reas, Fry 2007:21]. Make the difference clear.

5. Create an original composition by carefully positioning one grey line and one white ellipse on a black background.
6. Modify the code to change the fill, stroke, and background values.
7. Create a visual knot using only Bézier curves [Reas, Fry 2007:35]. See Roy Lichtenstein's screenprint Brush Stroke (1965, Figure 1) for inspiration.


Figure 1. Brush Strokes

8. Create a composition that scales proportionally with different window sizes. Put different values into size() to test [Reas, Fry 2007:41].

9. Use one variable to set the position and size for three ellipses (if it is unclear what a 'variable' is, look it up in the book).
10. Use multiplication to create a series of lines with increasing space between each [Reas, Fry 2007:50], e.g. with a for loop.

11. Create a composition with a series of lines and ellipses. Use an if structure to select which lines of code to run and which to skip. Use if in a sensible way, e.g. inside a loop.
12. Add an else to the code to change which lines of code are run [Reas, Fry 2007:59]. Use if and else in a sensible way, e.g. inside a loop.

13. Draw a regular pattern with five lines (not lines of code, btw). Rewrite the code using a for structure [Reas, Fry 2007:68].
14. Generate a basic grid using adjacent points (i.e. do not use the line command).
15. Experiment with altering spacing between the points which comprise the lines in the grid (also, do not use the line command).
16. Use the random() function to create some interesting grids (a grid is not any arbritrary pattern).
17. Draw a dense pattern by embedding two for structures.

Exercises Week 4–5
18. Create a grid of squares (each colored randomly) using a for loop. (Hint: You will need two for loops!) Recode the same pattern using a while loop instead of for [Shiffman 2008:97].

19. Write a function to draw a shape to the screen multiple times, each at a different position (if it is unclear what is meant by 'function,' take a look in the books). Call the function several times for this. Use one parameter to control the position.
20. Extend the function by creating more parameters to control additional aspects of its form (i.e. beyond its position).
21. Write a function to use with a for structure to create a pattern evoking a liquid shiny substance [Reas, Fry 2007:196].

22. Make a shape move with numbers returned from sin() and cos() [Reas, Fry 2007:299].

23. Move two shapes continuously, but constrain their positions to the display window (do not use any sine function; the forms should not just repeat the same simple motion over and over).

• 24. Implement a four-letter word generator (similar to Norman White's machine (1974), Figure 2). If you need more than 6 lines of code (not counting {}) for a basic working program, something can be improved. 4 lines would be good for a minimal program with full points. If your program has more than 250 lines of code something is seriously wrong. (10 points)


Figure 2. Four-Letter Word Generator

25. Snow-in a letter, load background picture of a letter at startup, snow flakes move downward and stop falling down when they land on something that is not e.g. black i.e. not the background (use classes and objects). (Bonus exercise 15 points)

• 26. Make an old school text scroller. Usually, this involves a black 'space' background, one line of text in a cool font coming in from the right, possibly some stars and whatever you like flying in e.g. sine waves (use classes and objects). (15 points)

Exercises Week 6–7
• 27. Interpret a well-known (graphical) artwork with computational methods. Lots of possibilities to try something interesting, e.g. interpret a static artwork to include animation or interaction; take an artwork as starting point and develop and automatically produce a class of pictures based on it. Do not use (e.g. load and display) an actual image of the artwork and e.g. filter it, but play with the parts, color, pattern or content of the artwork. Include a short info on the artist and artwork (and a picture of it) in the hand-in. (15 points)

• 28. Implement a simple shooting gallery-style game in which different animal shapes come in from the side(s) onto the screen and can be shot using the mouse pointer. It should not be easy to hit all the animals. If hit, something should happen to indicate the hit. Use classes and objects. (20 points)

Exercises Week 8–9
• 29. Make a rainbow. This exercise should involve different start and end colors for the rainbow, these colors are changed by the user during run-time (and there are several possibilities for that), and two different color transitions between the start and end colors (i.e. two different ways to incrementally and gradually change from one color to the other, e.g. with two for loops). Do not draw ellipses in random colors on the screen. (25 points)

30. Use translate() to reposition a shape.
31. Use multiple translations to reposition a series of shapes.
32. Use pushMatrix() and popMatrix() to rearrange the composition [Reas, Fry 2007:135]. Use in a sensible way.

• 33. Animate the Solar system in 2D using matrix operations (translation, rotation, scale) to rotate planets around the sun. Use classes and objects. (20 points)

• 34. Read and comment this piece of code. Write a short text: Describe what happens in the algorithm; what is the name of the algorithm? What are its advantages and disadvantages? Suggest a better algorithm. Describe how it works. Why is it better? (20 points)

[code omitted due to technical issues]

Exercise Week 10–11
• 35. Implement a version of Space Invaders (1978, Figure 3) for two (or more) simultanious players. This results in a playable, interesting and finished game (including e.g. starting the game, winning/losing, score, restart). Use a projectile gun (not a laser) as player weapon. Use classes and objects for players, invaders and shots. Work in two-person teams. (40 points)


Figure 3. Space Invaders

Coding Rules of Thumb
Demonstrated understanding of programming concepts often shows in programs that
∙ have headers
∙ have non-trivial comments that describe the big picture and the key aspects of what is going on
∙ are formatted properly (indentions, blank lines, brackets)
∙ cite sources, name references
∙ use more than one file (e.g. when using classes)
∙ use variables instead of magic numbers
∙ name variables and functions to explain their use (iStuffThat, bGetState)
∙ do use only as many variables as needed
∙ use only a minimal number of global variables
∙ use functions
∙ use classes and objects
∙ never repeat their code
∙ use constructs in a clever way (loops etc.)
∙ choose from a large range of constructs (for, while, do, if, else if, if &&/||, case, arrays, etc.)
∙ use the appropriate tools (i.e. functions, structures) for the job
∙ do not do any slow stuff inside of loops, e.g. load images from disk in draw()
∙ are elegant and short
∙ are careful with boundaries (arrays, screen, etc.)
∙ function with different screen sizes
∙ can draw on the books but change the examples significantly
∙ fulfill the exercises to the letter and interpret them in a novel/original way
∙ are fast
∙ are not depending on the computer speed (framerate) but use the elapsed (real) time; this applies to all programs which use movement or animation
∙ are interactive
∙ are unusual, fun to use and produce nice output  

Litteratur udover forskningsartikler:
 
Afholdelse (tid og sted)
Kurset afholdes på følgende tid og sted:
UgedagTidspunktForelæsning/ØvelserStedLokale
Onsdag 12.00-13.50 Forelæsning ITU 2A54
Onsdag 14.00-15.50 Øvelser ITU 2A54

Eksamen afholdes på følgende tid og sted:
EksamensdatoTidspunktEksamenstypeStedLokale
2014-05-21 Before 14:00 PM Skriftlige arbejder ITU To be uploaded in learnIT