How to convert a C1 SPR file to a C3/DS C16 file, using The One Stop Sprite Workshop and Jagent.
Get The One Stop Sprite Workshop and Jagent.
Choose a SPR file to work with. If it is an official Creatures 1 sprite, then Gameware’s general copyright exception applies, but with other sprites, it’s a good idea to get the permission of the original COBbler.
Open the SPR file with The One Stop Sprite Workshop. If you navigate to
the folder that your sprite is in, but you can’t see it, make sure that
you check that the ‘Files of type:’ dropdown is showing ‘Creatures 1
Sprite Files (*.spr)’.
You should see a small preview with a black background. Go to File >
Save As and choose ‘Creatures 2 Sprite Files 16 bit format (*.s16)’,
and save it with a sensible name. Close The One Stop Sprite Workshop.
Open this S16 file with Edos, and you should see the agent itself with a
blackish border, without a background. Go to Save and save it with a
sensible name, AND the .c16 extension. (For example, saving a lemon
sprite as lemon.c16). In addition, you have to use Edos’s dropdown
option to choose ‘Files of Type’ ‘Compressed Sprite File (*.c16)’.
Thursday, 9 July 2015
Saturday, 4 July 2015
Moving Items Into Your World With TMVT
A short tutorial on how to move new agents into your world by checking their location first with TMVT.
To find a good position for something to appear in the world, use the key command Ctrl-Shift-X. (Docking Station or Docked worlds only, but it will still be valid with C3 standalone.) This will give you two numbers that appear next to your hand in the world. Hover the fingertip over the place you want your agent to appear, and write down the two numbers. These are your coordinates.
mvto will make the top left point of a target agent appear exactly at the coordinates you chose.
mvsf will try to make an item appear in the general vicinity of the coordinates, at a slightly different spot that it considers 'safe'.
So what if you want to use mvto, but you want to make sure that the game won't crash if the spot isn't suitable?
You use a doif block with tmvt.
tmvt is a command that tests if the target can move to the given location and still lie validly within the room system. tmvt returns 1 if it can, 0 if it can't.
You can see that you can extend this code to try to place your object in multiple locations, if need be.
I like to first try to move my objects into a C3 location, and then if that isn't valid, move it to a valid DS position - thus incorporating a rough C3/DS check into the positioning of the agent. 'If the player isn't running C3, or a C3-docked world, then they must be running Docking Station!'
There are many, many other ways of running that C3/DS check and positioning the agent appropriately, but this is the one I use.
This can also be used in the push script for vendors to make sure that the vended item is made in a valid place in the world.
To find a good position for something to appear in the world, use the key command Ctrl-Shift-X. (Docking Station or Docked worlds only, but it will still be valid with C3 standalone.) This will give you two numbers that appear next to your hand in the world. Hover the fingertip over the place you want your agent to appear, and write down the two numbers. These are your coordinates.
mvto will make the top left point of a target agent appear exactly at the coordinates you chose.
mvsf will try to make an item appear in the general vicinity of the coordinates, at a slightly different spot that it considers 'safe'.
So what if you want to use mvto, but you want to make sure that the game won't crash if the spot isn't suitable?
You use a doif block with tmvt.
tmvt is a command that tests if the target can move to the given location and still lie validly within the room system. tmvt returns 1 if it can, 0 if it can't.
*If the test move works doif tmvt X Y eq 1 *actually move the object to where I want to mvto X Y *If the test move doesn't work else *move the item safely to the same location mvsf X Y *End the doif block endi |
You can see that you can extend this code to try to place your object in multiple locations, if need be.
I like to first try to move my objects into a C3 location, and then if that isn't valid, move it to a valid DS position - thus incorporating a rough C3/DS check into the positioning of the agent. 'If the player isn't running C3, or a C3-docked world, then they must be running Docking Station!'
There are many, many other ways of running that C3/DS check and positioning the agent appropriately, but this is the one I use.
This can also be used in the push script for vendors to make sure that the vended item is made in a valid place in the world.
Monday, 22 June 2015
Getting Your C3/DS CAOS Language Guide
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):
After you have done this you should find a file called "CAOS alphabetical.html" has been created in your journal folder.
To create the categorical version, type the following:
This creates the file "CAOS categorical.html" in the same place.
If you are running Creatures Exodus it is a little harder to find the file you need.
On Macintosh, look in your ~/Library/Preferences/Creatures Labs/Docking Station/data/Journal folder.
If you're on a PC, you'll want to look in My Documents for an analogous Journal folder.
If you are running Docking Station on Linux, you'll need to display hidden files, and then look for the Journal folder in ~/.dockingstation/Journal.
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):
file oope 1 "CAOS alphabetical.html" 0 dbg: html 0 file oclo |
After you have done this you should find a file called "CAOS alphabetical.html" has been created in your journal folder.
To create the categorical version, type the following:
file oope 1 "CAOS categorical.html" 0 dbg: html 1 file oclo |
This creates the file "CAOS categorical.html" in the same place.
If you are running Creatures Exodus it is a little harder to find the file you need.
On Macintosh, look in your ~/Library/Preferences/Creatures Labs/Docking Station/data/Journal folder.
If you're on a PC, you'll want to look in My Documents for an analogous Journal folder.
If you are running Docking Station on Linux, you'll need to display hidden files, and then look for the Journal folder in ~/.dockingstation/Journal.
Thursday, 18 June 2015
The computing curriculum: what every child should know
The computing curriculum: what every child should know
Jon Hall, The Open University and Lucia Rapanotti, The Open UniversityAsk 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.

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.

Jon Hall is Senior Lecturer in Computing and Communications at The Open University.
Lucia Rapanotti is Senior Lecturer at The Open University.
This article was originally published on The Conversation. Read the original article.
Sunday, 14 June 2015
An Introduction to Boolean Logic
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.
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.
Further reading
*Laws of Thought - Wikipedia
*CAOS Chaos | Our Simple Object Un-Simplified!
*Nested DOIF? - Hack Shack
*Conditions - Creatures Wiki
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.
Further reading
*Laws of Thought - Wikipedia
*CAOS Chaos | Our Simple Object Un-Simplified!
*Nested DOIF? - Hack Shack
*Conditions - Creatures Wiki
Saturday, 6 June 2015
Gnarler Water-Shyness
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.
AquaShee's Crabs use a reversed version of this to help them seek out water sources.
**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.
Thursday, 28 May 2015
Beginner's Guide to Monk Abridged
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.
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.
Subscribe to:
Posts (Atom)