How to get a full listing of the CAOS commands acceptable to your C3/DS engine.
If
you don't have access to the CAOS Tool, there is still a way to get
documentation about all of the CAOS commands you need to start
developing. This file acts as a dictionary of all the CAOS commands
that are being used in your game, and is very useful when developing.
The information can be presented in two ways - an alphabetical listing
of the commands, or a categorical listing. Both formats are useful so it
is worth getting both. The alphabetical listing is useful for a
quick-glance reference, and the categorical listing is useful when
you're thinking about what each of the commands do, in relation to
similar commands.
Open up the CAOS command line in-game CTRL+SHIFT+C and type in the following (all on one line):
The computing curriculum: what every child should know
Jon Hall, The Open University and Lucia Rapanotti, The Open University
Ask a parent what a school should teach and they’ll tell you, “When my child leaves school, I want them to be able to understand money, to work well with others, go to university or to get a good job.”
Ask an inspirational teacher and they’ll give a different answer. In physics they’ll say students should be inspired by questions about how the universe started and whether there’s life out there. In chemistry, to learn how to build new drugs and materials that will revolutionise our lives. In history, to learn from our mistakes and successes to build a better future.
What should an inspirational teacher say about computing, the discipline that defined the late 20th century and that is already constructing the 21st? And what computing knowledge and skills should a parent expect their child to know when they leave school? Answers to these questions should inspire and define the content of any computing curriculum, including that to be delivered for the first time in the UK in September 2014.
Which skills?
The beginning of the modern information age can arguably be traced back to Manchester University’s “Baby”, the first programmable computer. Baby ran its first, hand-crafted 17-line programme on midsummer’s day 1948. The programme – which finds an integer’s highest factor – is very hard to read. It was written in a very early programming language, one without the bells and whistles many have today.
Even so, a student of computing should be able to read and understand how the first programme works. Computational thinking – the computer-science led basis of the UK’s new computing curriculum – provides some great tools to do so.
A replica of the 1948 “Baby” computer in Manchester.KGGucwa, CC BY-SA
But being able to read and understand Baby’s first program clearly isn’t the same as being able to write it – in the same way that being able to read and understand Shakespeare isn’t the same as being able to write Romeo and Juliet.
And what if we need to bring Baby’s programme up to date? How about making it work on the web, with password protection to guard its use, or on a smartphone. What would it look like then?
Solving problems like this requires different skills. Great writers, such as George Polya, have taught us that to solve problems you need a “method”. And because much of the real-world value of modern computing is delivered through its modern methods, in addition to computational thinking and creativity that the curriculum recommends, students at each stage should be appropriately introduced to the modern ways that computing builds solutions. But this view of computing appears to be missing from the new curriculum.
Schools caught in the schism
Soon after Baby’s first programme, computers started to leave academia and make their way into business and beyond. Those were heady days when everything seemed to fall within computing’s grasp. There were breakthroughs on both sides.
Business computing invented ways of thinking about real-world problems, fuelling the development of methods able to cope with increasing complexity and high pace of change, from reaching a better understanding of users’ needs, to capturing good software design and practice for reuse, to using software to drive business change and as the backbone of today’s digital economy. With these and more, software and information systems engineering took shape.
Academia, too, made great strides: researchers pushed the boundaries of computation, learnt how to build error-free software and how to bring human logic, reasoning and other capabilities into the machine – with artificial intelligence. They learned how quickly algorithms could run and developed new ways of thinking about computation. With these and more, computer science took shape.
Unfortunately, the divide between business computing’s need for engineering and academia’s wish for computer science grew. Much of what the two approaches had in common was lost and something of a schism opened up.
Schools, which should have been the beneficiaries of their synergy, emerged with the lowest common denominator of “digital literacy” as a result of this schism. Their job was to teach children how to use office applications such as Word and PowerPoint – devoid of either engineering or science.
As ability to do computing has faltered, the realisation grew that digital literacy was not enough. But it took Eric Schmidt, executive chairman of Google, to get politicians to listen. And so a new computing curriculum was born.
The excitement and backlash in computing circles was palpable. What would schools teach and how would we introduce the next generation to computing?
A curriculum for 21st century computing
With computational thinking, the new curriculum certainly meets the challenge to go beyond digital literacy. Yet, its emphasis on code and computation appears to neglect the real world context of much of today’s computing and the hard lessons of decades of engineering software systems fit for real-world problems.
Full blown, industrial strength software engineering is like industrial chemical engineering: too complex to be taught in schools. But coding without an appreciation of computing’s methods and their associated tools simply misses the point and has as much chance of preparing someone for the complex and volatile world of computing as an English curriculum that teaches just spelling and grammar does for a student of Shakespeare wishing to emulate their teacher.
What should the next generation to meet their first computing teacher hear? It should sound something like this:
Good morning children!
If you want to solve the world’s problems with computers you’re going to have to know about how to build software with the computing method. You’re going to be able to help spacecraft fly to the stars, to discover new drugs that will make people well again, to build thinking machines that rival the human brain, to build new businesses that no-one has ever thought of before. With computing, you can dream of solving the world’s problems.
Now, here’s a problem I want you to solve with the three “C"s of computing: computational thinking, creativity and computing methods.
An introduction to Boolean logic, as used in CAOS for C3/DS.
Boolean logic is a kind of algebra used in computer programming that tests whether something is true or false.
There are three main rules with Boolean logic:
Whatever is true, is true.
Whatever is true cannot also be false.
In Boolean logic, there are no shades of gray, there is no maybe, no in-between.
From this, in CAOS, we can set up a number of true-false tests using a conditional (DOIF) statement, and using the modifiers OR, AND and NOT. Conditions can be joined together with AND and OR.
The Venn diagrams
below show everything that can exist in the box - the 'universe'. The
circles represent certain situations. Red represents our target, and
white represents stuff that we exclude.
OR is a term we use when we want to make our true-false test very broad.
You can see how it covers situations when either one of the conditions
are true, and the area in-between where both situations are true.
AND is a term we use when we want to make our true-false test narrower,
because both conditions have to be true for it to work. You can see
that only the overlapped area where both conditions are true is
highlighted. (e.g. a seed that only sprouts when there is enough soil
moisture AND there are fewer than 3 adult plants nearby)
NOT is a term we use when we want to find out when our condition is
false. (e.g. a fish critter NOT being in water will suffocate.)
In order for our statement to work, we need to say if this condition is
equal to a certain situation, does not equal a certain situation, or if
it is greater than a certain situation, or less than a certain
situation. A statement which, like OR, gives us a broader definition of
'true' are the commands 'greater than or equal to' and 'less than or
equal to'. The symbols below (<>, =, >=, >, <=, < )
and the letters (NE, EQ, GE, GT, LE, LT ) can be used interchangeably.
is equal to
EQ
=
is not equal to
NE
<>
is greater than
GT
>
is greater than OR equal to
GE
>=
less than
LT
<
is less than OR equal to
LE
<=
Conditions are read from left to right - unlike in algebra, in CAOS,
round brackets don't force the engine to do those tests first. This
means that you need to put the first thing first, and 'step along' with
the code, doing one check after the other.
Using the ELIF command lets us make another true-false test run directly after the first one has run its course.
It's good practice to put an ELSE
command in at the end of a DOIF statement, in case your agent runs up
against a situation in which none of your true-false tests apply - and
it gives your agent something to do if all else fails.
The last thing to do is to close your DOIF statement with an ENDI.
The following code is in the Gnarler timer
script, which helps keep the Gnarler out of the Ettin Desert's pond by
using the water CA. It isn't held in a subroutine.
**keep away from bodies of water
*Do this if you're in a room.
doif room targ ne -1
*Do this if you smell any water at all.
doif prop room targ 5 ge 0.00001
*Look for the room next to this one that smells less like water.
setv va00 lorp room targ 5 0
*Go towards the centre of the room that smells less like water.
setv va01 torx va00
*If the less-smelly room is on your left and you were going right, turn around.
doif va01 lt 0 and ov10 gt 0
negv ov10
*or else, if the less-smelly room is on your right and you were going left, turn around.
elif va01 gt 0 and ov10 lt 0
negv ov10
*end the turning around doif
endi
*end the 'smelling water' doif
endi
*end the 'I'm in a room' doif
endi
AquaShee's Crabs use a reversed version of this to help them seek out water sources.
How to use Monk, half of the Java-based Creatures development tool Jagent.
For the CCSF 2009, I wrote a tutorial on how to use Monk, half of the Java-based Creatures development tool Jagent.
Here is the tutorial, abridged and pictureless. I hope it helps.
For C3 and DS, agents can contain images, sounds, scripts, and
information about where agents inject inside one file - the agent file.
To extract the components of an agent, you must decompile it. Open
Monk and set the type of file you're working with to "PRAY Source".
Then drag and drop the .agent or .agents file onto the white square,
where it says 'drop files here'.
Shortly afterwards, a folder will appear in the same directory to which
you have your source agent file in. It will contain the sprites
(s16/c16), sounds (wav), code (cos), catalogue file, and a txt file. The
txt file is your PRAY file, it is what you need to master in order to
compile agents.
To compile, you must understand how to PRAY. Your PRAY file can be
saved as a .txt file. Have all the files you plan to compile together
in the same folder as the PRAY file. Set Monk's mode to "PRAY Chunk"
and drag and drop the PRAY .txt file onto the drop pad. It will create a
new agent in the same folder as the pray source.
As an addendum, for Windows, it's best to move your agent or files from
your Program files directory to somewhere else, like My Documents or the
desktop before attempting to use Monk on it, as Windows doesn't
appreciate Monk trying to unpack the files.
The US and UK governments often mirror each other’s strategies when it comes to new education policies, and the recent introduction of coding into the school curriculum is no exception. From this September, all children aged five and up will have to learn to code, with the English coding revolution reflecting the vision encapsulated in President Barack Obama’s famous quote: “Don’t just play on your phone – program it!”
This change is being accompanied by a surge of resources aimed at helping children code creatively, with tools ranging from non-digital board games such as Robot Turtles to Google’s completely visual, character-free programming language. While some tools are commercially produced, others like The Missionmaker Core, have been developed through research and development projects in collaboration with schools.
It’s not just about the tools though. Concerns have been raised about the government’s inadequate training plans for teachers, and the risks of simplifying coding into procedural building blocks rather than conceptualising it as a new 21st century skill.
Mixed signals
The problem is that we’re getting our coding metaphors mixed up. Editor at Mother Jones, Tasneem Raja, argues that good coders are like good cooks who are able to create creative dishes out of some basic ingredients. Others compare coding to music and composing, there is a rhythm and melody to it. Another popular metaphor is that of poetry and art.
There are some important similarities between these metaphors: they all share the notion of working steadily towards proficiency. Those who code daily for hours are likely to be those who will be good at it. All three metaphors also implicitly point to audience awareness: a musician, poet or cook derive great delight from those they “code” for.
Code for and with the community
Another way of looking at coding is that of creating a story, built by a community. If we characterise coding in this way, we move the concept beyond linear code-writing to multi-dimensional coding, co-created by multiple authors, who actively make as well as consume the code.
Seeing coding as community-story projects can help answer questions around how to educate and foster a generation that loves coding rather than teaching a set of skills demanded by employers. It moves us to conceptualising coding as part of computing science which can be taught without touching a computer and which needs to be taught differently to different age groups.
Importantly, it implies that children and teachers have to collaborate to use online tools together. Teachers could code apps and websites with the children, for various contexts of use. We need more examples of apps which are innovative and meet specific needs, like we saw with the Devonport High School for Boys app, created by Plymouth students aged 14 and 15 for students, staff and parents to communicate better with each other.
Seeing coding in this way might provoke a society-wide dialogue about empowering more people to become involved in the creation of the content they would like to see in the digital sphere. It could inspire politicians, the private sector or not-for-profit organisations to support free coding lessons to parents, grandparents and the general public, and so avoid widening the cross-generational digital divide even further.
It could also provide an accessible way in which to demonstrate the need for gender and racial diversity in the coding industry. With a new generation of community coders, we are less likely to see social software applications designed for and by predominantly young urban white men.
Metaphors have the power to create realities we would like to see. If we are ever to reduce the cross-generational gap in digital skills we have been experiencing since 1990s and the digital divides within generations on the rise since the early 2000s, using the metaphor of community storytelling seems like a good one.
The Mini Empathic Vendor has a script which, when the main empathic vendor has its hearing turned on, causes it to vend food in response to educated norns complaining about hunger, and causes the three food vendors in the norn meso (justanut, lemon and carrot pods) to vend food if the mini empathic vendor is not close enough.
The advantage of using the catalogue files in this way is that it will work for norns speaking English or any other language - as long as they are educated, the vendor will be able to hear them.
From "empathic vendor.cos", in the DS bootstrap:
** The Vendor's Ear scrp 2 23 3 126 **this whole script will not fire unless ov00 is 1. The ear is set as 'on' by default, but it can be set as 'off' by clicking the relevant button on the main empathic vendor. doif ov00 = 1 lock sets va00 _p1_ seta va01 _p2_ inst doif va01 <> null targ ownr rnge 1000 ** Check to see if you can actually see the speaker, if not.. get one of the pods to make some food! doif seee ownr va01 = 1 setv va99 1 endi ** Get the hunger sentences from the catalogues. ** Protein **this sets va10 as being the first entry in the 'creature drives' catalogue that can be 'read' by the ear. This is 'hungry for protein'. sets va10 read "Creature Drives" 1 ** Starch **this sets va11 as being the second entry in the 'creature drives' catalogue that can be 'read' by the ear. This is 'hungry for starch'. sets va11 read "Creature Drives" 2 ** Fat **this sets va12 as being the first entry in the 'creature drives' catalogue that can be 'read' by the ear. This is 'hungry for fat'. sets va12 read "Creature Drives" 3 ** Check Sentence to see if it wants Fat (Food) **do if the string-in-string search, in lower case, is nearby (va00) and has expressed a need for fat doif sins lowa va00 1 lowa va12 <> -1 part 1 frat 2 anim [4 5 6 5 255] snde "empv" **if you're too far away doif va99 = 0 ** Tell the Carrot Pod to make a Carrot inst enum 2 23 4 doif targ <> null mesg writ targ 0 endi next wait 15 targ ownr part 1 frat 5 anim [1 2 3 2 255] stop **or if you're close elif va99 = 1 ** Tell yourself to vend Peaking Pie mesg writ ownr 1003 stop endi endi ** Check Sentence to see if it wants Protein (Fruit) doif sins lowa va00 1 lowa va10 <> -1 part 1 frat 2 anim [4 5 6 5 255] doif va99 = 0 ** Tell the Lemon Pod to make a Lemon inst enum 2 23 6 doif targ <> null mesg writ targ 0 endi next wait 15 targ ownr part 1 frat 5 anim [1 2 3 2 255] stop elif va99 = 1 ** Tell yourself to vend Yarn Fruit mesg writ ownr 1002 stop endi endi ** Check Sentence to see if it wants Starch (Seeds) doif sins lowa va00 1 lowa va11 <> -1 part 1 frat 2 anim [4 5 6 5 255] doif va99 = 0 ** Tell the Nut Pod to make a Nut inst enum 2 23 5 doif targ <> null mesg writ targ 0 endi next wait 15 targ ownr part 1 frat 5 anim [1 2 3 2 255] stop elif va99 = 1 ** Tell yourself to vend Star Seeds mesg writ ownr 1001 stop endi endi endi endi endm
