Typing your manuscript

Here are a few tips to remember when typing up your manuscript:

 

  1. Use single spaces only, even at the end of a sentence. If you are an old-school typist, as I am, you were probably taught to use two spaces after a full-stop, but this is inadvisable on a computer. Some eBook converters will complain if they find two spaces together, and there is always the risk that one space will be put on the next line, forcing that line out of alignment with the rest.
  2. Avoid using blank lines in your document. It is best to put a visual marker instead. If you really want blank lines in a finished printed manuscript, you can adjust them once the page sizes are known, but in eBooks you can never guarantee where the page breaks will fall, and it is very easy to miss a blank line at the top or bottom of a page. For this reason, ebook converters will complain if you upload a document with blank lines.
  3. Indent the first line of each paragraph using the automatic settings in your word processing software. The usual style these days is to have no blank lines between paragraphs in fiction, and so the way to signal a new paragraph visually is to indent the first line a little. However, using the tab key or space bar to do this is a bad idea, as it makes it fiddly to adjust at a later date.
  4. Use section breaks or page breaks at the end of the chapter, to push the next chapter to the top of a new page. Section breaks also give you the option to choose whether you want next page or odd page starts, and allow you to change the header and footer between sections.
  5. Make use of the style system. Marking your headings using styles is not only a handy short-cut to keeping your formatting consistent, but it is the key to generating a Table of Contents for the front of the book, and if your book is non-fiction, then the navigation pane will help you check that your content is organised appropriately. 
  6. Avoid using the space bar to align content on the page. Instead, use the left-align, right-align and centre buttons. For anything more complicated, you can always set and use the tabs, or use a table and hide the borders.

If you follow these simple rules when typing up your manuscript, the final formatting should be smooth and easy.

More information on using the style system and section breaks.

 

Writing tools 2 – Aeon Timeline

Further to my post on Scrivener, a tool growing in popularity with many writers, another tool that’s well worth a look at is Aeon Timeline.

 

Whether your novel spans decades or takes place over a few days, the chances are that you have a sequence of events to organise – how long does that journey take? what day of week did they meet up? was there really enough time between those events for that to take place? It can be a real headache trying to keep track of what happens when and where, and if you are trying to balance different story arcs the headaches are multiplied.

 

Aeon simple view

Aeon simple view with Inspector open

Aeon Timeline is very simple to use, while providing many tools that are useful for organising your planning.  The timeline across the top shows the date, the events are listed in order on the timeline and at the bottom a bar shows how the current view relates to the overall timeline. Colour coding can be used for different events, and they can be events for a single moment in time or longer events, recorded to within the degree of accuracy you need, whether this is to within the year, the month or even the second.

 

Clicking on any event on the timeline gives access to the details of that event – here you can record which story arc it belongs to, the time and duration of the event and any other details you need. You can also provide a link to an external file – in fact the mac versions of Scrivener and Aeon Timeline will link with each other, so you can generate a scrivener file from your timeline and keep the two synced. The windows update for this feature is currently in development, and will be made available as a free update when released.

 

Aeon timeline arc view

Aeon timeline arc view

Having linked each event to a story arc, it’s very simple to switch to arc view. Here each arc is separated out to aid planning. You can zoom into and out of the timeline easily to obtain an overview or to see details, either by using the zoom buttons or the CTRL key and scroll wheel, and scroll backwards and forwards along the timeline by dragging the handle at the bottom.

 

Aeon entity/arc view

Aeon entity/arc view

Another useful feature is entity view. This enables you to create entities – people or places for example – and link them with the events on the timeline. You can also create birth and death events for people, and once you have created a birth event, each event that you link with an entity will keep you informed as to their age – a very useful feature that also helps you avoid linking them to events outside their lifespan.

 

Each entity may be linked as an observer or a participant, enabling you to keep track of whose point of view the section is to be written in. Again, colour coding plays a large part in planning out your timeline.

 

It’s very easy to combine simple view, arc view and entity view in any combination, to see different parts of your project in detail and check the timeline is feasible. The reminder of day of the week and time of year is also useful – having given a season for one event, you can clearly see what point in the year other events happen.

 

To create a new event, you either click on the button to create your arc, entity or event, or double click in the right place on the timeline. Either way brings up a dialogue box for you to enter and adjust details. Events may be dragged along the timeline either singly or in groups. A simple filter system enables you to see all the events affecting a specific entity, or with a specific tag, arc or label.

 

Timeline creation options

Timeline creation options

Options for creating a timeline include floating timeline, zero hour and geological. This should cover any project you could possibly conceive of!

 

I’ve been using Aeon Timeline for a while now, and find it very straightforward and useful. When they produce a Windows version that will sync with Scrivener, there’ll be no stopping me, but in the meantime the two programs even run separately provide me with every assistance I can think of.

 

Aeon Timeline is available as a free trial. It is, of course, useful for more than just fiction writing, and videos, forums and support are all available from the website. There are other features available, such as import/export and printing, but I feel I have covered the main features that, to me, make this an essential part of my writing toolkit.

 

Writing tools 1 – Scrivener

The beautiful thing about writing is that it can be done almost anywhere, almost any time, and needs very little specialist equipment. A cheap notebook and pen and a bit of space to work is all that is necessary, but many projects demand a little more in the way of organisation.

 

Most people will use either Microsoft Word or Open Office as their main word processor, and either has the tools needed to create the main document for your piece of writing.

 

However, if you are creating a large project, for example a full novel or non-fiction piece of work, you might find that you struggle to keep all the different parts of your project organised. That’s when a program like Scrivener comes in.

 

Scrivener main window

Scrivener main window

Scrivener provides an easy way to organise chunks of writing, by labelling each chunk, tagging with key words and statuses and providing an overview that is easy to rearrange.

 

With this program, you work in smaller files, which are usually scenes or chapters, and you can label them and rearrange them as you wish to form a larger project. There is also the facility to store other files that are not part of the main document, whether these be character notes or general research. You can even include PDFs or images within your Scrivener project folder. This makes it far easier to work on different areas of a large project.

 

Scrivener corkboard view

Scrivener corkboard view

Having labelled these files/scenes, it is also easy to rearrange them. Those index cards that you filled out for each file are available on the corkboard, where you can easily see the overall structure and change it around as much as you wish. Colour coding helps to see, for example, how different points of view are arranged, and you can also see the status of each part easily.

 

Scrivener outliner view

Scrivener outliner view

Another way of looking at the structure of your project is through the outliner window. This gives similar information to corkboard view, but in a different format.

 

Although Scrivener offers many features, probably more than most writers will use, a comprehensive tutorial offers a guide into what the software can do, and I found it quick and easy to get to the point where I could use it for my own work. Now I just dip back into the tutorial whenever I need to find out how to do something new, like filtering the projects by label or keyword, or adding and editing footnotes/endnotes.

 

Scrivener even saves your work automatically, so no more accidentally losing large chunks because you forgot to hit save! You can take snapshots of any section before working on it, so that you can compare versions later on, or roll back changes if after hours of work you decide that the first version was better.

 

At any point in your project, you can generate a view that merges all the files into one long file for easier reading, and when you are ready to move on you can compile the project into a text file suitable for formatting in a word processing program.

 

Scrivener comes in both Mac and PC versions, and is available as for a free 30 day trial should you wish to play with it before parting with your money. I find it so easy to organise my work with it that  now I couldn’t imagine tackling a long project without it.

 

The new computing curriculum and web science

There have been many arguments over the new computing curriculum. The more I look at it, the more concerned I am that it appears narrowly focused on programming, whereas computing can involve so much more.

 

One case in point is the course I’m currently studying at FutureLearn, the Open University’s contribution to the MOOCs (massively open online courses) currently sweeping the web. This particular course, sponsored by Southampton University, is called Web Science: how the web is changing the world. It looks at the effects the world wide web is having on society, and how we have influenced the web.

 

The topics it covers are ones that are important to understand, and that I spent time in the classroom trying to get across – that technology is new, but pervasive, and affects our lives in more ways than we can imagine. In fact, the same topic is covered in a book I’m currently reading in order to review: Digitized: The Science of Computers and how it shapes our World.

 

If children are truly to understand the importance of coding, and to be able to express themselves effectively using digital media, then they also need to understand the deeper concepts of computing, for example how it can help us to build a better world, and to better understand our own minds.

 

I haven’t done much resource creating for the past few months as I left my teaching post in July and have been focusing on other aspects of my business, but after a break away from classroom technology and learning for a bit I’m now getting restless and starting to look for ways that I can help schools make the move forward from office-based computer skills to real computer skills. If anyone has any suggestions – or anyone in the Canterbury, UK area (or online) would like practical help – then please do get in touch. I will be resuming my quest to produce teaching materials in January, but not being in a classroom regularly makes it a little harder to keep up with the practical side of things.

 

Incidentally, there’s another MOOC coming up that ICT teachers really should be seeking out: Teaching Computing part 1 (part 2 to follow) from the University of East Anglia, which aims to prepare teachers to teach the new computing curriculum in both primary and secondary sectors. The course lasts for 4 weeks and is expected to take up around 4 hours per week, but of course anyone seeking to teach computing should be prepared to devote time to it – my biggest fear is that computing will go the way of ICT, with too many non-specialists stumbling through and not giving the subject the rigour that it deserves.

 

How do I beta?

Please note that this is how I personally work – it isn’t a rigid way that the job must be done. I suspect there are as many different ways of working as there are beta readers. Also, this service is bordering on an alpha read or critique, rather than just a beta read.

 

When an author contacts me I’ll book them in and let them know when I expect to get to their project. Sometimes I can take one on immediately, while at other times I’ve run a waiting list of up to six months. When I receive the file, either in  Word or PDF version, I start an Evernote file for the work, giving title, author and page count (with word count if known). I add any synopsis or other information I’ve been given, plus any specific things I’ve been asked to look out for. I put the date I received the file and any deadline or estimate for finishing. I also confirm to the author that I’ve successfully opened the file and saved my own copy to work on. It helps if I also have some information on the writer’s experience and their intentions for the manuscript (generally, seeking an author or self-publishing).

 

As I read, I make notes in the project file – like a running commentary, on something I don’t understand, something that makes me laugh, something that’s inconsistent… I’ll also add general comments in the Evernote file under heading such as Setting, Plot, Characters, POV.

 

At the end of a session I’ll note in the Evernote file where I’ve stopped, and I’ll also summarize what’s happened in this session, so it’s easier to pick back up after a day or so away. This is also a good way of assessing the plot – is it easy to say what happened in each chapter? Did too much happen to explain quickly? Did things just drift along with nothing really happening at all? Is it clear at this point what the main character wants and what’s standing in their way?

 

I try to read at least 50 pages from a project in a session. Any fewer and it takes too long to get through, and it also becomes bitty in my mind and hard to keep straight. Any longer and I lose concentration – although if a book is close to the end of the development cycle and there is less to comment on I can become more involved and get further in the session. I might switch projects and continue if I still have time available, but I have to be aware of other work that has to be done as well, and in order to keep the beta fee as low as I can, I have to prioritise the higher-paying work.

 

When I’ve finished a project, I’ll wait until the next day to compose a report for the author. This allows my thoughts to gel. Sometimes I’ll go back and re-read the opening, adding a couple more comments – things that were unclear to start with sometimes come clearer on a second read, or things that seemed unimportant are noticed more – or important things are missing.

 

I’ll then write back to the author, attaching the project file with the comments, and include a general report as well. Sometimes the author has further questions for me, and I’m happy to carry on the conversation with them, and clarify anything. However, it’s entirely up to them what notice they take of my feedback. I also focus on finding and explaining problems, rather than how to fix them.

Beta reading is not like normal reading

For a start, I can only beta read either on my computer or on my laptop, so I can add comments. Beta projects are often unpolished, and therefore do not flow as easily as finished works, and this can slow down the reading considerably. I’ve had projects where I’ve had to train myself to ignore punctuation because, the use of commas, is fairly arbitrary making it, impossible to use it to, help with understanding.

 

I often have to go back and re-read sections, especially in the first few pages. What have I taken in? What have I missed? Has the author introduced too many characters too quickly? Is there too much background information given, rather than getting straight to action?

 

I’m constantly questioning what I read, and this means that I have to check facts – what exactly was she wearing? Did we get told she changed clothes? Is it possible she changed but we weren’t told? How many days have passed? What day of the week does this work out as?

 

This means that beta reading takes far more time and concentration than normal reading. It is not a way to get free books to read! It requires time and patience, and a good understanding of how books should flow. It requires tact and patience in explaining issues to the author. I am not – at that point, at least – the book’s editor or proofreader, and I will not point out every single mistake (more on the different roles in another post) but I will point out consistent errors and issues, and I will point out when a sentence does not get its message across clearly. I can pick up dictation errors if the author has used dictation software. I will point out where punctuation/grammar obscures the meaning. I will also point out general writing weaknesses, such as inconsistent points of view or over-reliance on adverbs, if necessary.

 

The read is focussed on the structure of the story, and while it is not in the depth required by a developmental or structural edit, it should provide plenty of information to help you identify the strengths and weaknesses of your novel and point you towards how to improve it.

 

All this makes for an enjoyable but challenging way of helping authors to produce their book. It is also a good way for the author to get to know the way I work, and for me to get to know the author and the story, before discussing any further editorial/proofreading work they may require. Part of the beta fee may be deductible from the final fee.

 

How can a beta reader help?

It’s important to understand how a beta reader can fit into the development of your writing. Making the best of all the resources at hand will lead to a higher quality end product, and after putting all that effort into your book, it makes sense to follow through properly.

 

A beta reader isn’t a proof reader. They aren’t an editor. They do not even need a high standard of written English themselves. But the one important thing about a beta reader is that they are a reader, and preferably one who enjoys the genre of books you’ve written and understands how stories* work.

 

You should expect a beta reader to read your novel* and give honest feedback. They should comment on characters, plot and flow of the novel. They should leave you with a better understanding of how your novel works for a reader: which bits are unclear, which bits are boring, which bits really help the reader imagine the scene, whether the characters work well. They should point out any inconsistencies they come across, and any plotholes they notice. Some might offer to correct errors for you, but please remember that they are not professional proofreaders, and as there are likely to be plot/structure changes needed as a result of the beta reading, it’s a little early to worry too much about spelling errors and typos. Some writers like to give a beta reader a questionnaire to fill in, or a set of targeted questions, but you should not expect a fully detailed critique of your novel. Remember that the beta reader is reading for free, or for a very small fee, and is not necessarily a writer themselves. They should, however, be able to explain whether a book works for them, and give reasons to justify their answer.

 

You can find beta readers via a site like goodreads, or kboards, or you could ask friends or family – but if you know the beta reader personally, you need to make it clear that you’re not looking for a cheerleader (although they can serve their purpose!) but for constructive criticism. Some established authors have websites or facebook pages where they have built up a network of people who may be called on to help out, but at first you might need to try out a few people and see who responds in good time, who gives useful feedback and who really isn’t worth the effort of sending your work to. As long as they respond in reasonable time and you find their observations helpful, it’s worth putting them on a list for future runs. Remember that they are reading in their spare time; don’t nag them daily, but you should be prepared to set a deadline and/or give them a nudge if you hear nothing for more than a couple of weeks. Usually you would be expected to provide either a Word document or a PDF format, but some beta readers prefer an epub. Personally I prefer to add comments to a Word document or sticky notes to a PDF. This does limit my reading to the computer or laptop, but it means I can add comments as I go through.

 

A beta reader should be contacted once you have a complete draft you want feedback on, but before you start to consider an editor. You can choose whether to build up a close relationship with one beta reader or use several, which gives you the benefit of a variety of opinions but can be more time-consuming to manage. You aren’t obliged to implement everything a beta reader might suggest, of course, but if two or three people suggest a passage drags then that’s an area you should definitely focus on, and likewise if a passage is confusing or unbelievable, or if there are plotholes noticed, or repeated issues with a character. 

 

If you feel you want more help than a beta reader can offer, some editors are willing to work closely with you on the plot; this is called substantive editing, and can be expensive, depending on the experience and ability of the editor. Bear in mind that you are expecting this person to spend a lot of time with your work, and to go through it thoroughly; all this is time-consuming, and the editor has to charge a sensible amount in order to make a living. On the other hand, you should make sure you are happy with what they offer before agreeing to the work. Most editors will give a free sample edit so that you can see how compatible you are. Some editors might be willing to provide a cheap beta read/critique along with a sample edit. This will provide you with basic feedback and allow them to see whether they feel they can help you. Again you are not obliged to follow their suggestions, unless the editing is provided as part of a publication deal, but why pay for someone’s advice if you are unwilling to follow it?

 

Once you have considered carefully all the feedback from the beta reader(s), it’s time to redraft, and depending on the amount of changes made you might feel you need another beta read. Take your time, and redraft/rebeta as often as you feel you need, but remember that you will never, ever reach a point where you feel your novel is perfect! Just make sure you have done the best you can before you hand it over to an editor for a final polish.

 

* I have spoken here about novels and stories, plotlines and characters, but of course what I say applies to other types of writing as well, for example memoirs and other non-fiction. You may, however, find it harder to find beta readers willing to help you out for these other types of writing. This is one example of where a paid beta might be useful or necessary.

 

For further information see my article How do I beta?

More on BBC Basic

Since my previous post about BBC Basic I’ve been looking into the topic further, and it appears the language might have something going for it after all – it’s very similar to the pseudocode used by OCR, and OCR seems to be supporting it, as they have provided training materials using BBC Basic to illustrate solutions.

 

One problem the language does seem to have is a lack of materials available, so I decided to have a go at remedying that, and have produced a KS3 workbook, similar to my Python workbook, which provides guidance into the first few steps of programming – input, output, variables, IF statements and loops – using BBC Basic, including simple exercises. My intention is that the booklet provides enough information for the more able students to progress by themselves, while others will benefit from extra guidance from their teacher.

 

I myself missed out on BBC Basic, as by the time it was introduced in schools I was at the top end and about to leave, but I did start off with Sinclair Basic, which was very similar. I do miss the old days of line numbering, but I have to admit that these days it’s far easier! If there is a generation of teachers out there who need to learn how to teach computing in a hurry and they’re already familiar with – or even just have a passing acquaintance with – BBC Basic, then capitalising on that would seem to be a viable way forward.

 

I intend to look further still into BBC Basic and pseudocode, as students are expected to understand pseudocode anyway for OCR GCSE Computing, and being able to write programs in pseudocode that translate directly into executable code would be useful, but I do feel that there needs to be some sort of introduction to another language as well. Watch this space for more news on training materials.

 

I remember reading once (a long time ago, admittedly!) that universities don’t want students who have already learned a programming language because they get confused when learning a second, but on the other hand those who already have experience in two find it far easier to learn a third. I myself have found that it’s the thinking and planning skills that are vital – once you understand exactly what you are trying to do, finding the exact syntax in the language of your choice becomes the easy bit. It’s like learning to drive a car – when you first learn, you’re bothered by every small difference in another car – the side the indicator is on, the biting point of the clutch – but once you gain more experience you’re aware of the differences and can work better with the similarities.

Hopscotch – programming on iPad

Hopscotch looks similar to Scratch in many ways

Hopscotch looks similar to Scratch in many ways

I’m always on the look-out for interesting ways to introduce children to programming, and recently I came across Hopscotch, a free iPad app.

 

At first glance, Hopscotch looks very much like Scratch, but it is much simpler, while making full use of the interface possibilities of an iPad.

 

Blocks available to use are limited to

  • motion: move, rotate, set heading, change x by, change y by, set speed
  • lines: leave a trail… end, set line color, set line width, clear
  • controls: repeat… end, wait
  • looks: scale by, set opacity, change costume
  • operators: random

Each script starts with an event trigger:

  • When play button pressed
  • when I shake the iPad
  • When I tap the stage
  • when I tilt the ipad down/left/right/up
  • when I tap the object
  • when I hear a loud noise
  • when [this object] collides with……

    The program can produce simple graphics

    The program can produce simple graphics

One sample program that came with the app produces this output, by using several sprites to each draw a section of the image:

 

My first reaction was that not having the full functionality of Scratch is a real disadvantage – there is no possibility of embedded maths, for example, because the only operator offered is one that generates a random number.

 

Part of the code for the Sydney Opera House program

Part of the code for the Sydney Opera House program

However, on reflection, this could also be a strength, as limiting the code that can be used forces attention on those that can be used, so the coder can really explore the possibilities without getting too bogged down in complicated code blocks.

 

It’s my impression that the app is constantly under review and development, as since I first investigated it the collision function was added, so it’s very possible that within a few months Hopscotch turns out to be a fully developed, child-friendly graphical app design tool.

 

Tabs show different sprites in the program, while a simple diagram helps with placement on screen

Tabs show different sprites in the program, while a simple diagram helps with placement on screen

In the meantime, it does offer basic functionality that enables creators to create interactive animations and activities involving basic logic. Its Event -> Action format would also serve as a good introduction to Gamemaker or other similar products, and of course the drag and drop graphics make it very easy for even young children.

 

I suspect that older children would find this rather limiting after a while, but I would certainly recommend it at key stage 2 for exploring possibilities in programming, and even as a cross-curricular maths tool, exploring distances and angles, for example giving a drawing to copy and seeing if children can describe the sequence needed to draw it.  Results could of course be recorded by screenshot and drawings to copy can be as simple or complex as needed, leading to natural differentiation by task.

 

There is a limited selection of cartoon-like graphics that can be added to projects, plus a text object. This limits what can be done rather, but again I suspect that this could well be developed in the near future, including hopefully the ability to import your own graphics.

 

There is a limited selection of objects available, plus a text object

There is a limited selection of objects available, plus a text object

In summary, a basic tool that provides a good introduction to programming for younger children and has strong possibilities, but which at the moment is likely to be rapidly outgrown by anyone who has already experienced Scratch, as the interactivity offered by the iPad is negated by the limited instruction set.

 

If you have a class set of iPads, then this is would be useful. If you haven’t, then you’re not missing very much at the moment, but this could well be one to keep an eye on for the future.

Gamestar Mechanic and the new computing curriculum

gamestar mechanic logoOne resource I was pleased to come across was Gamestar Mechanic. This is a purely web-based resource that teaches elements of game design. It’s aimed at 4-9th graders (I make that 9-14 year olds) and offers them a chance to move from playing games through fixing games to making and sharing their own. Of the many resources I’ve used with key stage 3, it’s the one I see consistently used voluntarily by the students outside of formal lessons. As we’re partway through our year 7 computing unit, which so far has looked at Scratch, I thought I’d take a closer look at GSM and see exactly what offers in terms of learning and how it fits in with the new computer-orientated curriculum.

 

One feature that makes GSM easy to use in class is that the registration system does not require an email address. It does, however, have a system to recover passwords that depends on students being able to remember a username and sequence of favourite colour, subject and animal, which isn’t ideal (it can change from attempt to attempt, let alone lesson to lesson!) so this time round I intend to make students make a note of their user name and passwords somewhere secure. They can use any nickname as their user name as long as it’s not already taken, but often it’s easier to tell them to use their school log-on names and passwords rather than spend hours trying to think of something suitable.

 

Once registered, the student is presented with a quest to work through. There is one quest available free, while others are available for those with premium membership ($19.95 for premium membership, and it may well be that students are interested enough to get their parents to pay for it, but free membership is plenty for school use).

 

There are two other areas of the site that will also interest users: in the workshop they can create their own games, while in Game Alley they can publish their games and try out those made by others, but more of those later.

episode 1 screen

Episode 1 screen

There are teaching materials provided by the website to serve as an introduction to the site, in the form of five lessons. Lesson 1 works through episodes 1 and 2 of the quest and then provides an opportunity to reflect on learning so far. The resources provided for lesson 1 are a set of cards that can be printed and used for matching – one set provides images of various concepts, while the other set provides names and explanations of those concepts, which are grouped into mechanics, space and components. For example, under the space group you will find bounded and unbounded space, under components you will find health meter and avatar, and under mechanics you will find collecting mechanic and exploring mechanic. This will give the students a whole collection of key terms and concepts to build the rest of the unit on, but I wonder just how many they will be able to take in and remember. The suggestion is that in small groups they work to pair up concepts and images and then everyone goes through the answers. I’m considering giving them worksheets with the concepts on and the cards with the names on, so they can fill in their worksheets and keep them for reference.

 

Lesson 2 introduces the core design elements, which are defined as space, components, rules, mechanics and goals. Episodes 3 and 4 of the quest provide a chance to investigate ways of changing each of these and showing the effect on the games. The resource provided for this lesson is a graphic to serve as a reminder of the core design elements.

 

Lesson 3 looks at balance, investigating how the different core design elements balance a game to achieve the right level of difficulty. This focuses on episode 5 and then gives students the first opportunity to build their own game. This ability is there right from the beginning, by the way, via the workshop, but each challenge the player completes in the episodes unlocks another feature they may use, either a different sprite, different background or something similar, so the further through the quest they get the more they have to use in their own games.

games creation screen

Games creation screen

 

Lesson 4 gets the students to design their own game, and offers challenge cards for different themed games should you wish to use them.

 

Lesson 5 encourages students to play-test each other’s games and give feedback via the sheet provided. This guides them into answering questions like “What were the core mechanics of the game?” “how well was this game balanced?” and “how could this game be improved?”.

 

So far so good, but what got me really thinking was when I started looking at the new computing curriculum and how Gamestar Mechanic might be considered to fit into it, because that was when I struggled to find anything in there that would link easily to games design. While games design is only a small part of what computing offers, at the age of these students it’s their most immediate attraction and links in most closely with what they already enjoy doing, so whether it fits into the computing curriculum or not,  I feel it has a lot to offer.

 

One aspect of the computing curriculum is to use two or more programming languages. Does this provide a programming language? Well no not really, but it does provide objects that have attributes. By changing those attributes the student interacts with elements of the game and causes changes. While this does not count as a programming language, I would certainly argue that it is an important step towards moving into object oriented programming in systems such as Greenfoot, by providing a way to play with parameters and settings in a very controlled and accessible way.

 

Object oriented programming gets no mention in the computing curriculum, which is a shame. I’m starting to get the impression that it was written without the needs of children in mind; I can’t imagine too many children being excited at learning sorting algorithms, but give them a chance to learn games programming and they’ll be much more engaged (I know that object oriented programming and games design are not the same, but the latter provides a very good way into the former). What they learn via games design can then be applied more widely as they develop their skills.

games alley, showing published games

Game Alley – published games

 

What about the creative element of the computing curriculum? Undertake creative projects that involve selecting, using and combining multiple applications … to achieve challenging goals… well it’s selecting, using and combining multiple elements and experimenting to see how they work together in order to achieve a playable game, does that count? It’s not really multiple applications, although it is multiple elements, which can include sound. What students can’t do with this, as far as I can see, is design their own elements. I’ll be taking a look at Gamemaker very soon, which is a natural successor to Gamestar Mechanic and does offer this facility.

 

Create, reuse, revise and repurpose digital information and content with attention to design, intellectual property and audience – well it’s doing some of that, not intellectual property maybe, but attention to design and audience, and combining the elements in a suitable way, particularly if you use the challenge cards to set a specific purpose or setting for the game.

 

Maybe Key Stage 2 would fit it better? After all, if the students haven’t been through computing at key stage 2 there’ll be some need for overlap for a year or few. Here we have solve problems by decomposing them into smaller parts, use sequence, selection and repetition in programs; work with variables and various forms of input and output, use logical reasoning… I would argue that it covers all those, although maybe not in the way those who created the curriculum were expecting them to be covered.

 

What it does do is provide a common language and set of concepts for games design that can then be developed further in many directions, so that students can move on to programming their own objects while already aware of concepts like level design, object interaction, responding to events and parameters.

 

Key stage 4? Here we fare much better.  It should provide a chance to develop their capability, creativity and knowledge in computer science, digital media and information technology and to develop and apply their analytic, problem-solving, design and computational thinking skills, all of which I would say it does. Considering the restrictions on it, however, I would suggest that GSM would need to be used as a springboard to Gamemaker, Greenfoot or Scratch, all of which are much more versatile and provide more opportunity to incorporate a wide variety of imported assets. It does, however, have the advantage of allowing students to focus on the game design elements and how they interact without worrying too much about how they create them, so they are not trying to learn everything at the same time.

 

So strangely, this seems to fit in far better with the older key stage than with the younger ones (although, of course, the key stage 4 curriculum was deliberately left very vague in order to fit in with the many ICT and computing qualification courses already available).

profile page showing badges earned

Each games designer earns badges as they learn

 

Looking at the old ICT levels, Gamestar Mechanic seems to fit in much better: strand 1 covers planning, developing and evaluating systems, using feedback to develop work, strand 2 covers creating sequences of instructions and changing variables and explaining the impact, and strand 3 covers presenting information in a range of forms for specific purposes and audiences.

 

In summary, while GSM doesn’t completely seem to fit the new computing curriculum, it does seem to have a lot to offer as an introduction to game making, and as part of a larger unit or with explicit teaching on various aspects such as changing parameters and looking at audience and purpose, it does have a place in either late key stage 2 or early key stage 3 learning. More importantly, I would argue, it engages students and keeps them coming back for more, and shows them the satisfaction of creating their own games for others to play and comment on. Any frustration they eventually feel at the limitations of games created through this method can then be directed into Scratch etc, where they have much more control but need to create the behaviours themselves.

game review screen

Game review screen

 

And that reminds me of another aspect that appears to be missing from the new computing curriculum: there is no mention of collaboration in there, of working together as a team to achieve a common goal and of supporting each other in their learning. This was present in the old system (use ICT to communicate and collaborate) and would appear to be a vital digital literacy skill, considering the extent to which young people use ICT to share ideas in the real world. In Gamestar Mechanic they have a chance to do this by writing reviews for games.

 

Still, until the new computing curriculum is confirmed and we have more concrete information about what it entails and how to deliver it I’m happy that my students will indeed experience the games design fun of gamestar mechanic.

 

Python at Key Stage 3

a simple programI recently had the pleasure of introducing some year 8 and year 9 pupils to Python. They had previously dabbled in Scratch, but the idea of writing formal text-based programs was new to them, so we took it slow and steady.

 

The first lesson was mostly taken up with getting to know Python – we started by typing commands directly into the shell, and then they learned how to open up a new window, type a simple program into it and run the program. By the end of the first lesson they could type up print statements and simple maths statements into a program listing, save it correctly and run it.

 

Lesson 2 introduced the idea of variables and input. I reminded students at the beginning of the session how to start up a new window and create a program rather than type into the shell, and how to save their program with .py on the end to conserve the colour coding. They were also starting to discover the pleasures of debugging, and learning to look carefully at their code to spot errors. They helped each other out with this, and I showed them how to check not only the area of code that Python highlighted as a concern, but to check just before it as well, as often the error was missing speech marks or closing brackets.

 

Lesson 3 was where the real fun began, as we looked at if statements. Combining these with input meant that we could create a question and answer program, and combining that with a variable called score gave them the option of creating their very own quiz. Reactions varied, as some struggled to get their program running and grew frustrated while others started to really fly, creating inventive listings that checked for a user name and password before allowing access to the quiz. Generally, they seemed to enjoy the sessions, and my favourite reaction was that of frustration expressed as the code refused to work, followed by that surge of satisfaction and achievement as the error was spotted and fixed.

 

Our work developed by way of writing programs to solve problems, and for this I used my flash resources. This had the advantage of offering different levels of challenge and support, so that those who were able could work at a higher level while I could help those who were really struggling. By the end of the sessions all students understood a little more about how programs are made and they had learned that little details like capitals and spelling really matter. Most were starting to see how their program worked and how to fix errors and develop the functionality, while a small number really enjoyed the unit and were starting to come up with their own ideas and solutions.

 

This was only a very brief introductory look at programming, but it was enjoyable and worthwhile as a taster of computing rather than ICT, especially for those going into options, and encouraged students to think carefully and increase the accuracy of their written work. I saw expressions of satisfaction from both ends of the ability level, as those who struggled finally got something working while those who experimented showed off what they had managed to work out for themselves. Students whose first reaction as “This is stupid” moved over to “Oh, I see what the problem is”, as they learnt that the computer would do exactly what was it was told to do, and discovered for themselves the harsh realities of Garbage In Garbage Out. Even if they never see another Python statement, I believe they’ve taken away the understanding of how carefully you need to express yourself in order to be properly understood and how accuracy leads to better results.

 

As a result of my experiences I’ve developed a workbook and some flash resources, which you can find on my website here.