Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Musicode

visheshk
February 24, 2014

 Musicode

The description of a music programming puzzle game under construction, with the aim of engaging computational thinking.

visheshk

February 24, 2014
Tweet

Other Decks in Education

Transcript

  1. Aim • To enable self-learning of computational thinking. • We’re

    making a puzzle game, which exercises computational thinking by requiring puzzle solving using programming paradigms embedded in the game elements.
  2. What is computational thinking? • “Computational thinking can be used

    to algorithmically solve complicated problems of scale, and is often used to realize large improvements in efficiency.”
  3. What is computational thinking? Computational Thinking is a problem-solving process

    that includes the following characteristics: • Analyzing and logically organizing data • Data modeling, data abstractions, and simulations • Formulating problems such that computers may assist • Identifying, testing, and implementing possible solutions • Automating solutions via algorithmic thinking • Generalizing and applying this process to other problems
  4. What is computational thinking? Essentially, computational thinking is about seeing

    the underlying patterns (of steps) after breaking down a task, and solving these patterns by giving simple sets of instructions – such that a computer, an unthinking machine that follows steps, can do to complete the task.
  5. Our inspirations 1. Logo aimed to involve kids in computational

    thinking [with a variety of aims – design and develop their own metaphors for concepts, etc.]
 But essentially, to allow them to draw, make turtle art, using simplified programming commands. 2. Scratch aimed to obviate the difficulty of debugging syntax errors, and having to know scripting to make programs – to describe stories, make animations, etc, easily.
  6. Our inspirations A. Over here, we imagined that our project

    should enable kids to make digital music without any of the difficulty of dealing with code, and engage in computational thinking at the same time.
  7. Our inspirations 3. RoboZZle – a robot-programming puzzle game, has

    a large repository of puzzles, which are solved by very nicely designed conditionals and elements of recursion – without having to write any code, and only dealing with the concepts of the same. http://www.robozzle.com
  8. Our inspirations B. RoboZZle was another significant inspiration guiding our

    project’s design. 
 We imagined that making puzzles that ask for making certain pieces of music – would be an engaging act for the output, and also host a wide area for thinking and finding increasingly optimized solutions (in terms of whatever elements we put in).
  9. Ideation We imagined different interface layouts for making music. At

    this step, we were aware that we wanted support for functional modularity: Because finding common patterns, and distributing them across functions is one of the most common, and useful exercises, especially as a manifestation of computational thinking. We foresaw the nature of puzzles that we want our interface to enable finding multiple solutions for – play all permutations of a set of musical notes (very tough), play certain notes on odd beats, and different on even beats, and so on…
  10. Ideation 1. Timeline – Select which note to play per

    beat, on a horizontal timeline. (+) Similarities with the way music notation is written. Maybe, if our interface was adequately similar to how music notation is written, that could be a learning outcome as well. (–) To obtain the modularity of functions in this metaphor, was turning out to be very difficult and synthetic/forced-seeming. If a certain piece of the timeline is separated into a function, it’s speed should be change-able, and it should be able to switch between other pieces of the timeline – a concept that didn’t sound very meaningful.
  11. Ideation 2. Building blocks/Straws – Join some straws or lego

    blocks and their construction corresponds to a set of notes in a particular manner. (+) being a tangible toy, this would probably have greater play and engagement. (–) tough to embed puzzles or challenges to discretely solve. Lesser scope, in our thoughts, for learning new concepts via puzzles/levels.
  12. Ideation 3. Disks – Inspired by DJs, gramophones, and a

    frequent circular metaphor for music loops etc., we imagined giving programmable disks to store the music – and act as modules representational of function blocks. (+) clear modularity in multiple disks – to allow for function programming and calling, (+) possible allowances for recursion, (+) Simple interactions for defining music to be played, and clear scope for making puzzles with the aim of music generation, (~) Currently exploring the possibility of functionality of arrays in this metaphor – which along with recursion would provide scope for a vast variety of clever and interesting puzzles.
  13. Prototype – shortcomings • Music/notes aren’t yet played. The note

    to be played is simply highlighted as blue when the spindle goes across it. • The user can’t yet add more disks, and remove disks. The code has support for multiple disks, but the UI so far doesn’t. • There is no puzzle interface, or monitoring of output created by the user, yet.
  14. Prototype – shortcomings • Function stacks are not implemented
 What

    this means, is that the operations of a function aren’t pushed to a stack in the current prototype. Hence disk 1, which was supposed to be analogous to void main(), does not resume playing if linking to disk 2 (i.e. calling function2() in between) finishes playing. Calling any disk, currently, resumes its playing, rather than run it from the start again (as would happen with calling a function), while the remaining operations be kept in a stack to execute later.
 > Due to this, the shown puzzle 1 – solution 2 doesn’t work on our prototype.