Tuesday, 23rd April 2019 (4:00PM)
PyWeek is a simple idea: write a game, using the Python programming language, from scratch, on a given theme, within a week. Take part as either an individual or a member of a team entry. At the end of the week play, feedback and score each others' entries. After which, an individual and team are crowned respective champions for their category of entry.
I have taken part in three different iterations of PyWeek. Each one has been extraordinarily good fun.
My first PyWeek was as an individual entry. The theme was "two worlds", so I imagined a paper based battle between the worlds of blue biros and red biros (it felt like a good idea at the time...). I wanted to push the limits of my Mu code editor for beginner programmers and PyGameZero (a gaming framework for beginner programmers integrated into Mu, developed by my buddy [and organiser of PyWeek] Dan Pope). The end result was a side-scrolling chase game called PaperChase. This video shows me testing the game with my (then) thirteen year old son... you'll quickly get the idea:
My next entry was as part of a team. I'd been helping author and journalist Andrew Smith to take his first steps into coding. Making a game seemed like a fun vehicle for further learning. The theme was "flow" and so we devised a simple Frogger clone where you avoided traffic flow whilst being chased by lumbering zombies. I did the code and Andrew did the sound and music. The end result (Trafficflowmageddon) is, I feel, quite cute... as zombie relate games go...
And so we come to the most recent PyWeek.
Once again, Andrew and I teamed up. We chatted before hand about the sort of game we might want to make. Since we both have a love of the written word we decided to go with a text-based (rather than graphical) game -- the theory being it would play to our "strengths" with the written word.
In the end, this was (by far and away) my favourite PyWeek so far. Here's why...
Graphical games show, text based games describe. Graphical games have an added cost of "asset" development (the graphical stuff shown on the screen) whereas text based games only need typed characters. Graphical games tend to focus on hand/eye skill to progress gameplay, whereas textual games necessarily put narrative, meaning and intent at the centre of their process.
Obviously, these are broad generalisations. But what I want to get to is the idea of a player engaging with a game imaginatively, emotionally and intellectually via the medium of words. If done properly, the depth of engagement is potentially greater. I'm not saying one can't be engaged in such a way with graphical games, rather that textual games are perhaps a medium which more easily lend themselves to this end. It's similar to the difference between a book and a film.
I want to be clear, I'm not saying one is better than the other, these are very different ways to tell a story or play a game, but I can't help but feel a "reader" has to do more (and the reward is therefore greater) than a "viewer".
I also think that text-based games are, in a sense, more egalitarian and accessible. Again, to continue the book/film similarity, while no mean feat, writing a book is within the realms of a single author armed with just a pen and paper, whereas making a film requires a cast of collaborators and specialists, equipment, facilities, locations and deep pockets. For similar reasons, the generation and manipulation of textual game content is far simpler and affordable than for graphical games.
So what sort of games are textual?
Easy! Adventure games! If you're interested in finding out more about this style of text-based game you should watch GET LAMP, a fascinating documentary about the genre. Alternatively, if you want to try playing an example of such a game, I've embedded one of my favourites below (just click on it and type some commands). It's based on Douglas Adams' "Hitchhiker's Guide to the Galaxy" (the game itself was co-authored by Adams).
Here's where it gets interesting.
Such games don't have to be single player, solo efforts. While this is a fun way to play, things get far more interesting if you can play with others. This is not a new idea and I remember playing such games (commonly called MUD "Multi-User Dungeons") via surreptitious use of my school's single 1200 baud modem when the teacher wasn't looking. These were often Tolkien-esque fantasy themed virtual worlds where players could wander about exploring, socialising and cooperating to achieve some in-game outcome (usually a quest of some sort). Later, when I was at university in the mid-1990s, I began using a type of multi-user textual world called a MOO (Multi-user Object Oriented). The wonderful thing about MOO based textual worlds is that they are programmable by users (I first got to grips with object-orientation via learning to program MOO). In a sense the MOO is both the game and a platform for creating textual games collaboratively. It was this sense of a creative textual virtual world that Andrew and I wanted to recreate.
Et voilà, "TextSmith" was born.
The theme for this most recent PyWeek was announced as "six". This fitted our idea for an interactive textual platform. It could contain six different literary worlds which players collaboratively create, inhabit and explore together. The six literary worlds we "seeded" in our game were:
Programming the game was a lot of fun. I managed to build everything mostly from scratch (except for the web based front-end which uses the Quart web microframework). Sadly, most of it was unfinished, broken and clunkily implemented. The important thing is that it has potential. Below is a screenshot of an early version of the game:
Happily, despite the unfinished and rather shonky nature of the end result, we placed 4th in the team category..! Our highest result..! The feedback from fellow PyWeekers was encouraging too and, as a result, I've decided to continue to develop TextSmith. In the immediate term this will involve plugging in the almost-finished scripting language I created and knock off some of the hard edges. More importantly, once this aspect of the "platform" settles down, I'm looking forward to creating and exploring interactive literary worlds.
Finally, programming, creating and playing with TextSmith has been a very rich seam of reflection in terms of both technical and playful contexts. I've had lots of fun thinking about the architecture and implementation of such a platform while also doing a philosophical deep-dive into what on earth is going on when "players" connect to, create within and interact with such a platform.
Who knows where this may lead..?
Wednesday, 13th February 2019 (4:00PM)
I have a new tuba!
My new tuba isn't a replacement for my current instrument (which I got when I was sixteen years old). Rather, the instruments complement each other. What's the difference? If my current tuba is a professional "all rounder", my new instrument is a sort of "heavy duty" tuba for big orchestral pieces (most of my current playing is orchestral).
The tuba works by amplifying the buzzing sound I make with my lips into a mouthpiece. I change notes by tensing or relaxing my lips (so the buzzing sound gets higher or lower) which gives me a limited series of notes that are overtones to the "fundamental" (lowest) note produced by blowing down the length of the tube of the instrument. I use valves to add tubing to the length of the instrument to fill in the notes between the overtones so I can play all the notes I need (i.e. a chromatic scale).
What's interesting is how the two instruments are different.
My original instrument is pitched in Eb (E flat) -- which means the instrument's fundamental note is the Eb more than an octave below the bass clef (i.e. very low). My new instrument is pitched in C, so its fundamental note is even lower, thus making it an instrument more suited to lower sounding music.
The valves on each instrument are different. I have "piston" valves on my original instrument. These are spring loaded and when pressed fully down add additional lengths of tubing to the instrument. The photograph below is of the inside of the valve so you can see the holes in the piston used to connect the different pipes, depending on the valve's position (up or down).
My new instrument uses "rotary" valves. These, as the diagram below shows, rotate to connect additional lengths of tubing (the passage of air is indicated by the hatched area). A sort of lever is used to actuate each valve. They're generally much quieter and more reliable than piston valves (less moving parts to make clanking sounds) although they can be slower to "engage".
The picture below shows the rotary valves on my new tuba. Notice the levers I press with my fingers to engage the valves.
While both tubas look "tuba shaped" my original tuba points to the right (as the player is looking at the instrument) whereas my new instrument points to the left. This simply means I have to hold them differently and there's not really any change in sound. You can see this difference in the picture below (the new tuba is on the right):
The final major difference is in the number of valves each instrument has. My original instrument has four "compensating" valves which allow me to get a full chromatic scale. The new instrument has five "non-compensating" valves: the first four work like my original instrument and allow me to play a full chromatic scale, but the fifth valve is used to help tune the very lowest notes.
Why does the new tuba need a special extra "tuning" valve and what on earth am I talking about when I say "compensating"..? This, dear reader, is where maths, acoustics, logic and music come together in a spectacular fashion.
My new tuba is approximately 524.9 cm in length without any valves engaged. This produces the note, "C". The first valve adds enough pipe to lower the pitch by a tone, giving me a "Bb" (B flat) which requires the total length of tube to be 589.2 cm. Simple arithmetic tells us the total length of the tube added by using the first valve is therefore 64.3 cm (the "open" length of the instrument with the added tube should give the correct length to play a tone lower). The second valve drops the pitch by a semitone to the note "B" which requires a total length of 556.1 cm. Similarly, the third valve lowers the pitch by one and a half tones, giving me an "A" which requires the total length of tube to be 624.2 cm. Again, the simple arithmetic tells me that the length of tube added by the second valve is 31.2 cm while the length added by the third valve is 99.3 cm.
Here's where it gets interesting. If I want to play the note "G" I need to make the length of the instrument 700.6 cm. Given the note "G" is two and a half tones below "C" I could take the tone provided by the first valve and one and a half tones of the third valve and use them together. It means the resulting length of additional pipe is 64.3 cm (the first valve) + 99.3 cm (the third valve) giving me a total of 163.6 cm. However, the open length of the instrument (524.9 cm) with the additional lengths of pipe (163.6) brings the total length to 688.5 cm, which isn't the 700.6 cm needed to play the note in tune!
The solution is to use my fourth valve, which adds 175.7 cm to the length of the instrument, thus making it in tune. However, when I need to use my fourth valve in combination with my other three valves I still encounter the same sort of "wrong length of pipe" problem I describe above. I must use combinations of valves in order to get all the notes I need in the chromatic scale. So what can I do?
This is where the fifth valve on my new tuba comes into play. It has a special tuning slide I can adjust "in real time" as I play, thus allowing me to tune the fifth valve as and when I need it. It can also be tuned in such a way that it "compensates" (remember that word) for the missing lengths of tubing when I use the other valves together.
Which leaves us with the problem of keeping my current tuba (with only four valves) in tune. Thankfully, this instrument has "compensating" valves which work in a rather ingenious manner. The schematic representation of my current tuba is shown below. The mouthpiece is on the left with the bell on the right and between are the four valves and associated tubing (not to scale). None of the valves are engaged so the column of air blown through the instrument goes directly through without any "detours" (as shown by the pipe filled in with blue).
When I press the first and third valves down the expected two extra lengths of tubing are added, as shown by the two loops of pipe filled with blue:
Here's where it gets really clever. When the fourth valve is pressed down, not only is the expected additional length of tube added to the length of the instrument, but this tube is also diverted back through the other three valves which have additional "compensating" tubes to bring the instrument in tune:
This is, essentially, a logical
AND expressed as pipe-work. If
the first and fourth valves are pressed then add some new "compensating" length
of pipe. Clever huh..?
The disadvantage of this system is the air does two "circuits" around the instrument (once through the first three valves, and then again if the fourth valve is pressed so the compensating pipes can come into effect). This makes the instrument harder to blow (since there are more bends to blow through). My new instrument feels like there is less to push against when I'm playing.
Finally, given all the technical tuba-related geekery described above I want to end on an artistic note...
These instruments are beautiful to look at and playing them is a joy. It's hard to explain to folks who have never performed music what an amazing privilege it is. I get to play beautifully designed and precision engineered instruments as part of an orchestra, band or smaller ensemble. By playing with my fellow musicians to an audience I'm taking part in a unique social activity. No matter the mood or difficulty of the piece I'm playing, I love the sense of non-verbal communication I have with my fellow musicians and collectively with the audience. I love that I am a part of something creative, challenging, expressive, collaborative and most definitely greater than the sum of its parts. That the audience appreciate these efforts is a lovely positive side effect.
To me, this is always "joyful noise". :-)
Saturday, 5th January 2019 (3:30PM)
Lots of people want to learn how to program computers.
The success of code "boot camps" and devices aimed at the education sector (Raspberry Pi and the BBC's micro:bit spring to mind) is evidence of this desire for folks to learn "coding".
At a time when technology is finding its way into every aspect of our lives many folks appear to want to be more than just passive consumers of technology. They feel a desire to become creators of technology. They want to take control of their digital world. They want the skills to make their technology reflect their own needs.
Recently I've been experimenting with how I could use my background and expertise in music education in a way that helps folks address this desire for learning to program. The first experiment took place over the autumn and involved a group of complete beginners preparing for a "code grade".
CodeGrades are a programming version of time-proven techniques like music grades, belts in martial arts or lifeguard certification. Learners level up by applying the knowledge and skills needed for each grade to their own fun, interesting and challenging coding projects. Learners present their projects to professional software developers who assess the projects against the criteria for the grade being taken and provide a set of marks and written feedback so the learner can see where they're doing well, what needs to improve and what their next steps may be.
The autumnal experiment proved this concept worked. The initial group of learners were able to learn enough to create a "grade 1" level project in the Python programming language in about ten weeks. Furthermore, after completing their grading the vast majority asked when they can take their next grade. This outcome was far better than I had ever imagined.
Like music grades, code grades are eight cumulative steps for learning how to write code. The first grade (as taken by our "test subjects") is easy enough for most people to take as a first step into programming. The eighth grade is of equivalent standard to the skills and knowledge needed to be an effective junior professional software developer. The middle grades bridge the way so the skill gaps between each of the grades is achievable. They're like stepping stones into coding, or perhaps a modern day "Gradus ad Parnassum". ;-)
Perhaps the most important aspect of CodeGrades is how it is different to other educational offerings.
Code boot-camps will charge you north of £10k for a three month course and a guaranteed "job" as a junior developer. This is, frankly, a terrible idea. Not only are people throwing huge sums of money over a cliff edge before they make the jump themselves, but learning to code requires a long term investment of time. You cannot learn how to write effective code in just three months. What the boot-camps have realised is that you can learn enough information in just three months to appear as if you can code. It has been my unhappy experience to interview graduates of such schemes and have them answer my questions about the niceties of some aspect of coding with text-book answers; yet most have been unable to apply such "text book answers" in any useful or even credible way. Those who did create something made what can only be described as "spaghetti code". This is the equivalent of claiming that it's possible to train musicians to a professional level in just three months. Can you imagine how an orchestra would sound with musicians trained in this way? Would you want to hire such musicians to play for your wedding party?
Other educational efforts are mostly aimed at beginner developers. As a result, all their educational resources are at the beginner end of the scale and there is hardly any guidance for how to move onto more challenging programming. Put another way, it's like getting a piano with lots of beginner level music to learn, but nothing which will stretch you after you've got the basics in place. There is simply no continuity nor access to the fun "advanced" stuff.
The syllabus for CodeGrades is written by professional software developers. The grades reflect current best practice found in the software industry. They offer a framework for sustained and structured long term learning to write code. All the resources associated with CodeGrades are free, learners only pay to take the grading. CodeGrades will be priced in a way equivalent to music and ballet grades or martial arts belts.
CodeGrades help you learn to code with the confidence you need to make the stuff you want.
The upshot is that it's the start of the year, and I've decided that the outcomes from the experiment in the autumn have been so positive that I want to invest some of my own time into developing the concept further.
So, here's to an interesting 2019... I hope to work with friends (old and new) in making something that helps people learn and grow while also providing employment for developers who feel they're at a stage in their career where they want to acquire and practice the skills needed to be effective and inspiring mentors.
Happy new year.