The Den source files

The Den was a room by Sentinal, many years ago. It was meant to be a series of rooms to go with the Raccoon norns, and while only the male Raccoon norns were completed, a number of things were made for the Den.

You can download the Den source here.

Well-worth a look!

Aquatilis Caverna Source (Rooms 1 & 2)

As promised, here is the source files for Aquatilis Caverna rooms 1 and 2.

Download the source here.

I'll make a post sometime soon talking about some of the plans we had for the rooms.

Chocolaty Addendum.

So in the tutorial I released, I had the reader make a very basic vendor that did only as much as getting the job done.  But there are a lot of little things, finishing touches, if you will, that could still be done!

Here’s a quick list of them with code examples.

• Drop sounds.  That nice “thud” that comes from dropping an agent.

  scrp 2 23 9000 6
      lock
      sndc "drop"
      wait 5
  endm

  scrp 2 11 9000 6
      lock
      sndc "dr10"
      wait 5
  endm

• Different chemicals from eating the bar. Fat, sugar.

  scrp 2 11 9000 12
      stim writ from 79 1
      sndc "chwp"
      doif pose eq 0
          pose 1
      elif pose eq 1
          kill ownr
      endi

  targ from

  chem 10 .25
  chem 3 .25

  endm

• A stimulus for “pushing” the vendor, to encourage Norns to do it, placed in the Activate 1 script.
  
  
  • stim writ from 90 1
    
• And I also didn’t go over Commenting.  Anything you put after a * sign is a comment. So for instance, you can say:
  
  
  • *inject .25 fat
    chem 10 .25
    *inject .25 sugar
    chem 3 .25

It can be very helpful in organizing your script. :)

Hopefully you all can use these things. :)  If you ever don’t understand something, just try looking it up in the CAOS Documentation, and if you still don’t get it, ask about it here or here.

Beginner Tutorial Part 3

Welcome to the final part of the beginner tutorial.  Our chocolate vendor is almost ready.  All we have left is to

1. Have it vend chocolate
2. Make the chocolate edible

Which might not seem like much, but there’s a LOT of new concepts here.

Your script so far should look something like this:

new: simp 2 23 9000 "moe_tutorial_chcd" 7 0 300
bhvr 1
attr 198
elas 10
aero 5
accg 7
fric 50
mvto 6100 9110

scrp 2 23 9000 1
lock
    frat 2
    anim [0 1 2 3 4 5 6]
    over

 

rscr
enum 2 23 9000
    kill targ
next

Now, it’s time to make chocolate come out of our vendor. But before we actually put in the script for making a chocolate bar, we already know that we’re going to need to move the chocolate bar to the vendor’s current location.  So how do we find that?

Well I need to introduce you to the concept of the TARG.

Let us imagine for a moment that we are the engine running this script.  For everything, every code, and ever alteration that occurs, we are working with the “owner” of the script, that is in this case, the chocolate vendor.  As soon as we add the code for the new piece of chocolate, our “targ” is going to change to the chocolate.

I have highlighted this because it’s an important concept.  There are codes to get the position of an object which we will be using, but in order for us to get the position of the vendor, and move the chocolate to it, we need to set a couple variables to store the vendor’s position before we create the chocolate bar, because the codes are only going to work on the currently targeted object.  You’ll see what I mean below.

Our next lines of CAOS are:

setv va00 posl
setv va01 posy

But what does that actually mean? 

The primary way of making objects change and interact is to set variables, and operate (change, divide, add, subtract, etc) on them.  There are five types of variables we can define:  Object Variables, Game Variables, Engine Variables, Named Variables, and Script Variables.

Each type of variable has a different “name”, and is used for different purposes, but each one can hold anything from a number, to a sentence, to an agent in the world.  Variables are VERY powerful.

In this case, we’re using a Script Variable.  You can define in any Script Variable from va00 to va99.  These variables are useful because they will IGNORE the current target and stay in the script until it ends, at which point, they’ll be discarded and lose their values.

So for instance, we are telling the engine that we want to setv (set variable) va00 to the position left of the current target (which at the moment is our Chocolate Vendor).  What this command will do is examine our vendor, and it will look for the left-hand side of the vendor, and return whatever X-Coordinate on the world that happens to be.  Just like using the coordinate tool we used to place our vendor in the beginning, but automatically.

The second command did the same as the first, except it returned the Y-Coordinate of the world at the center of our agent.

-----

Below is a diagram of all the position commands and what value they’ll return to help you understand what each one does.

“posr” will return the X coordinate of the right of the agent.

“posl” will return the X coordinate of the left of the agent.”

“post” will return the Y coordinate of the top of the agent.

“posb” will return the Y coordinate of the bottom of the agent.

“posx” and “posy” will return the X and Y coordinates, respectively, of the center of the agent’s bounding box.

If this confuses you at first, don’t worry. Just keep it in mind, and you’ll understand what happens when we make the chocolate bar. :)

-----

Let’s make the chocolate now.  Add this after the last command we typed.

new: simp 2 11 9000 "moe_tutorial_chcd" 2 7 301
bhvr 48
attr 195
elas 10
aero 5
accg 7
fric 50
mvto va00 va01

Much of this is review, so I won’t go through it all, but basically, we’re making a new: simple object, which is a generic (2), food (11), in the 9000 range. It uses the same sprite file as our chocolate vendor, but only uses 2 frames, and starts at frame 7.

Our chocolate is edible and and carryable by creatures, so it’s bhvr is 48 (16 + 32), and it has all the same attributes as our vendor, except it cannot be activated.  The rest is the same, except for the mvto command.

This mvto command is moving the piece of chocolate, not to a predefined coordinate, but to the variables we saved earlier.  Remember, va00 is the left hand side of our vendor, while va01 is the Y coordinate for the center of our vendor.  We defined those earlier.  Now you may be beginning to understand why we set those variables before making the chocolate.

As soon as we used the new: simp command, our target changed.  If we were to “setv va00 posl” right now, va00 would be set to the left-hand X-Coordinate of the chocolate, not the vendor, since the chocolate became our target when it was made, and since technically the chocolate hasn’t been placed anywhere, it would return a value of 0, and would never be moved! D:  That’s why it was important to set our variables for the position of the vendor before creating the chocolate.

-----

Now, we just made some chocolate come out of our vendor. Let’s give it a kick.  It looks like the chocolate would come out of the vendor and go flying left a bit, so let’s give it some left velocity.

Add a “setv velx –10” to give it some “umph” coming out. This will tell the engine to make this object move, that is, set it’s velocity to, –10 pixels a second along the X axis.

-----

Ok, so we have our vendor, and when it’s pushed it animates, vends some chocolate, and then what?  Well it needs to go back to it’s original pose now that the chocolate has popped out.

To do this, we’ll add “targ ownr” which tells the engine to target the owner of the script (our chocolate vendor) because right now we’re still targeting the chocolate, and then we’ll add “pose 0” on the next line, to tell it to set it’s pose back to 0.

That’s all this script needs to do, so now we need to end the script. To do this, we add an “endm” line. This tells the engine that’s the end of the script, it can close it up and add it to the Scriptorium and/or stop running it.

Your script should now look like this:

new: simp 2 23 9000 "moe_tutorial_chcd" 7 0 300
bhvr 1
attr 198
elas 10
aero 5
accg 7
fric 50
mvto 6100 9110

scrp 2 23 9000 1
lock
    frat 2
    anim [0 1 2 3 4 5 6]
    over

setv va00 posl
setv va01 posy

new: simp 2 11 9000 "moe_tutorial_chcd" 2 7 301
bhvr 48
attr 195
elas 10
aero 5
accg 7
fric 50
mvto va00 va01
setv velx –10
targ ownr
pose 0

endm

rscr
enum 2 23 9000
    kill targ
next

 

We’re almost done!  But oh no! We forgot that this vendor has a sound file!  Right before it pops out the chocolate, it needs to play the vending sound.  To do this, simply type:

sndc “vdnr”

This tells the engine to play a sound that is controlled, named “vndr”. 

Put this piece of CAOS right above the “setv va00 posl ” command, that way it makes the sound just as it’s vending, right before chocolate pops out. :)

new: simp 2 23 9000 "moe_tutorial_chcd" 7 0 300
bhvr 1
attr 198
elas 10
aero 5
accg 7
fric 50
mvto 6100 9110

scrp 2 23 9000 1
lock
    frat 2
    anim [0 1 2 3 4 5 6]
    over

sndc “vdnr”
setv va00 posl
setv va01 posy

new: simp 2 11 9000 "moe_tutorial_chcd" 2 7 301
bhvr 48
attr 195
elas 10
aero 5
accg 7
fric 50
mvto va00 va01
setv velx –10
targ ownr
pose 0

endm

rscr
enum 2 23 9000
    kill targ
next

There.  Now we just need to make the chocolate edible and we’re done. :)

To make the chocolate edible, we’re going to make a new script.  For future reference I won’t tell you to close the script with “endm” just know that it must be done. I usually just write out the script’s name (scrp X X X) and endm first, then just place my cursor in between and type, that way I never forget an endm.

So!  We need to make an eat script for our food.  If you remember how we made the activate script for our vendor, this should just be review. 

scrp 2 11 9000 12 (remember this is our food, it’s 2 11, not our vendor, which was 2 23)

stim writ from 79 1
sndc "chwp"
doif pose eq 0
    pose 1
elif pose eq 1
    kill ownr
endi

endm

First we declared the new script. It’s an eat script (12) for our generic object (2), which is food (11), with a species of 9000.

Then we told the agent to “stimulate” the from in a certain way.  The from will be whatever agent activated this script. In this case, a creature will most likely activate it, so it will stimulate the creature.  Examine your Beginner’s document for more information about stim writ, or check the list of stimuli in the CAOS Documentation. The value of 1, was the amount we wanted to stimulate the creature.  I went ahead and had it stimulate the creature fully.  When you stim a creature, they learn from the action. The creature that eats this chocolate will learn that it gains nutrients from chocolate. :)

Then we had it produce a sound, in this case, a nice chomping sound called “chwp”.

The next bit is going to take some explanation.  Welcome to the world of the doif.  It’s one of the most important commands in the game, and the most versatile.  Luckily it’s pretty self-explanatory.

[Do] if something equals something,

do something.

[Else] if something eq something other than the first value we tried,

do something else.

end the doif block.

So basically it reads, if the pose eq 0, set the pose to 1, if pose eq 1, kill the owner of the script (the piece of chocolate).  It’s very simple if you just read it. :)

This basically tells our block of chocolate that it can be eaten twice.  On the first try it changes it’s pose to have a bite out of it.  On the second try, it’s destroyed.

-----

Now there’s ONE last thing we need to do.  Add the chocolate pieces to our remover script, and also make our remover script able to remove all the scripts we’ve added to the Scriptorium.

enum 2 11 9000
    kill targ
next

scrx 2 23 9000 1
scrx 2 11 9000 12

----

The scrx command will remove whatever script number you put after it from the scriptorium. We had an eat script for the chocolate, and an activate script for the vendor, so we scrx’ed both of those.

And that’s it!!!! Our chocolate vendor is FINISHED!

Bellow is the full code. :)

 

new: simp 2 23 9000 "moe_tutorial_chcd" 7 0 300
bhvr 1
attr 198
elas 10
aero 5
accg 7
fric 50
mvto 6100 9110

scrp 2 23 9000 1
lock
    frat 2
    anim [0 1 2 3 4 5 6]
    over

sndc “vdnr”
setv va00 posl
setv va01 posy

new: simp 2 11 9000 "moe_tutorial_chcd" 2 7 301
bhvr 48
attr 195
elas 10
aero 5
accg 7
fric 50
mvto va00 va01
setv velx –10
targ ownr
pose 0

endm

scrp 2 11 9000 12

stim writ from 79 1
sndc "chwp"
doif pose eq 0
    pose 1
elif pose eq 1
    kill ownr
endi

endm

rscr
enum 2 23 9000
    kill targ
next

enum 2 11 9000
    kill targ
next

scrx 2 23 9000 1
scrx 2 11 9000 12

Beginner Tutorial Part 2

Now that we’ve got ourselves all set up to code, let’s begin! :)

 

Now as you all know, I’m also working on the C2toDS project, so naturally, I’ve always got my eye on things I can convert from Creatures 2.  As I was browsing The Creatures of Avalon for interesting cobs, I came across this C2 Chocolate Vendor, credited to Creature Labs.

I knew then exactly what I wanted to do a tutorial on!  We’ll be remaking this vendor, from start to finish. :)  So let’s um…start!

First, grab the tutorial files here, and place them in your Tutorial 1 directory.  Also, place the sound file, “vndr” in the Creatures Sounds directory, and the sprite file, “moe_tutorial_chcd” in the Images directory of your Docking Station folder.

 

Open the CAOS Tool (which is highly recommended as it has syntax checking), or whatever program you’ll be using, AND start Docking Station.  Never try to develop and agent without having Creatures running!  A good developer beta tests constantly!

Also, start the Sprite Builder tool, and open up “moe_tutorial_chcd”.  Keep this open, we’ll be referring too it soon.

With the CAOS Tool open, make a new empty document.  The first thing we’re going to do is just write up the basic install and remove script for the vendor.

The script for creating this object is:

new: simp 2 23 9000 "moe_tutorial_chcd" 7 0 300

An explanation card of what each of these components “means” is below, a text version of this can also be found in your Beginner Document and the CAOS Documentation.  Here is a card explaining just what each value means (click for larger version).

The new: simp command is obvious as to it’s function, and if you look at Table 4 in your Beginner Reference Document, you’ll immediately see why the first two values are 2, and 23.  It tells the engine it’s a generic object, 2, known specifically as a vendor, which is 23.  Creatures’ brains interact with these classifiers and it’s how they know what an object is called and does.

But what about the 9000?  Well the 9000 is the Species Range.

All objects in the world have a Species. It helps the engine tell one object apart from another, since there could be more than one vendor in the world for example, each doing different things.  If it stopped at 2 23, how would the engine know that this is a Chocolate Vendor, and not the Justanut pod?

For this tutorial I’ve taken a portion of Creature Lab’s registered range, 0-10,000 and allocated 9000-9099 to tutorials. :)

Since this is our first vendor in the 9000-9099 range, we’ll be using 9000, but if it were our second vendor, we’d need to use 9001, so they don’t conflict.  Which means in a range from 9000-9099, you could have 100 vendors all doing different things!

In case you’re wondering, the Justanut pod is “2 23 5”. The Infinite Cheese Machine on the Shee Ark? That’s “2 23 1”.  See how they’re all different but still classified as a generic object (2), and vendor (23)?

The “2 23 9000”, as a whole, is called the “Classifier”. 

----- “moe_tutorial_chcd”

The second component of our first line of script is the name of the image file.  It’s pretty straight forward.  Whatever your sprite file is named, put quotes around it and type it out. :)  Our sprite file is named “moe_tutorial_chcd” so we’ve put quotes around it and…well there it is. That’s pretty much it… lol  Be sure to put quotes and don’t spell things wrong!

----- 7 0

The next two numbers are tricky and can give beginners a hard time. They tell the engine that this particular object is using 7 frames from it’s sprite file, and that it starts at frame 0.

But why 7?  Well if look up at the sprite file, you’ll see that the vendor has sprites from 0 to 6.  Frames 7 and 8 are the chocolate, so we don’t need those yet.  We want the engine to cut out frames 0 to 6, and keep those ready for when we animate the vendor.

But still, you may be wondering, why 7?  The last frame of the chocolate vendor seems to be 6, so why are we cutting out 7 frames?  Well, this can be confusing for beginners, but remember that we COUNT 0 as 1 frame.  Sure, it’s known as frame 0, but it’s still ONE frame and we need to count it. 

So we count, starting at 0, “0 1 2 3 4 5 6”. That’s seven numbers, 0 just happens to be the name of one of them.

Now we’re going to tell the engine what sprite to start at.  We want our vendor to start at the first frame, which is “named” 0.  That’s what the “0” is for in the “7 0”.

Advanced tip - The “0” is also known as the “Base” All frames are RELATIVE to this one. So if you told the engine to start at frame 4, that frame would be known as 0 to that agent.  It’s confusing at first, but you’ll see what I mean when we get to the chocolate.

----- 300

The 300 is the “plane”.  Ever notice how some objects are “in front of” or “behind” others?  This is how the engine knows where to put the object.  Usually you’ll want this to be around 500, but I did 300 for demonstration purposes.  When we inject the agent, you’ll notice it’s behind most other objects in the world, including creatures.

-----

On to the next line! :D

Now we want to tell the engine what properties our object has.  Is it heavy? Can it be clicked?  Does it fall under gravity or float? if it falls, how fast? Will it bounce? Slide?

new: simp 2 23 9000 "moe_tutorial_chcd" 7 0 300
bhvr 1
attr 198
elas 10
aero 5
accg 7
fric 50

I’ve written in a whole bunch of new commands, but don’t be overwhelmed, they’re self-explanatory, most of them. :)  We’ll start at the bottom first.

“fric” tells the engine how much friction this object has on surfaces. A fric of 100 will make it completely immobile.  It won’t slide even on a 89 degree slope!  A fric of 0 will make it slide forever!  I’ve used 50 to make it slide a little, but stop fairly soon, and stay put on most angled floors.

“accg” is the object’s “accelleration due to gravity”.  Basically, how fast does it fall?  I’ve used 7 because it’s a pretty heavy vender.

“aero” is the objects air resistance.  Think of it like friction, but in the air. If you toss this object or it falls, how much is it going to slow down as it travels through the air?  That’s what aero defines.  I chose 5 arbitrarily.  It doesn’t really matter for our vendor cause it’s so heavy.

“elas” is the object’s elasticity. How bouncy is it? Our vendor has an elasticity of 10.  It’s metallic and heavy, so it doesn’t bounce much.

Now we get to something a bit more complicated: attr.

“attr” defines an object’s attributes. Can it be picked up?  Does it collide with walls? Respond to physics?  You can set the accg to 10, but if your attr isn’t set to obey physics, the object won’t fall. So how do you know what value to put here?

Well if you look at Table 1 in your Beginner Document or the Attribute Values in the CAOS Documentation, you can see what each number represents. 

We want our object to be carryable by the hand, activatable by the hand, suffer collisions, and suffer physics. And if you’re looking at the CAOS Documentation or your Beginner Reference you can see that each of those things has a value next too it. 

Mousable (which means it can be picked up by the mouse) is “2”, “Activatable” is “4”, Suffer Collisions is “64”, and "Suffer Physics is “128”.  So just add those together!  It’s that simple!

2 + 4 + 64 +128 = 198 – so our attribute value is 198. :)

The same thing is done for bhvr, which can be read “behavior” meaning “how can a creature interact with this object?” also known as “Creature Permissions”, except the values here mean different things. 

We only want our creature to be able to activate the vender, not eat it, hit it, pick it up, or anything else, so we’ll just use the number 1.

-----

Great, so our object is just about set up.  But where is it going to go, exactly?  Right now the engine makes the object, but it’s not put anywhere!  We need to tell the engine to move the object someplace.  We do this with the “mvto” command.

new: simp 2 23 9000 "moe_tutorial_chcd" 7 0 300
bhvr 1
attr 198
elas 10
aero 5
accg 7
fric 50
mvto 6100 9110

Ok great! The engine is moving our object somewhere, but where did the 6100 and 9110 come from?  Well if you go into Docking Station and press Shift+Ctrl+X on your keyboard, a tool will appear by your hand.  This tool tells you the X and Y values, or coordinates, the pointer is pointing at. 

Everything in the world is placed on this invisible pixel grid of X and Y values.

I moved around in the Comms Room till I found a good place beneath the agent injector and wrote down the values.  The 6100 is the “X” value.  Think of it as “left to right” on the screen.  The 9110 is the “Y” value.  Think of it as “top to bottom”.  Move around the world with this tool to get a feel for how it works.  You can choose to place the chocolate vender anywhere, I’ve just chosen to do so in the Comms Room.

Advanced Tip – If you get an error when trying to put the object someplace, try using mvsf instead of mvto.  It’s just like mvto, but moves the object to a “safe” location. Be aware however that mvsf is a Docking Station ONLY command.

Now our agent will be in the world, but how do we get it OUT of the world?  Now most developers do this LAST, but I like to do it first so I can test easily, and won’t clutter my world with hundreds of vendors!

rscr
enum 2 23 9000
    kill targ
next

“rscr” tells the engine this is a “Remover Script”.

“enum 2 23 9000” tells the engine to look at, or “target” every object with the classifier 2 23 9000. It actually means “enumerate over objects with this classifier”. Enumerate is just a fancy way of saying, “target them all one by one”.

“kill targ” does just what it says.  It kills the target, which currently is every object with the classifier 2 23 9000, because if you recall, we just told the engine to target all those with the “enum” command.

“next” basically just tells the engine to continue after targeting all the chocolate vendors with whatever comes next in the script.

-----

Ok, so our chocolate vendor is in the game, and it’s removable.

new: simp 2 23 9000 "moe_tutorial_chcd" 7 0 300
bhvr 1
attr 198
elas 10
aero 5
accg 7
fric 50
mvto 6100 9110

 

rscr
enum 2 23 9000
    kill targ
next

But, if you try and inject it now you’ll get an error, because we’ve told the engine that a creature can activate it, but we haven’t actually written in any activation script, so the engine is a bit miffed at us for not doing that!

Let’s ease it’s concerns and make our vendor functional by giving it an activation script.  To write a script we type this (before the rscr but after the mvto):

scrp 2 23 9000 1

“scrp” tells the engine that this is a new script.  As you know, the 2 23 9000 is our chocolate vendor’s classifier.  So the engine knows that this script belongs to our chocolate vendor.

But what kind of script is it?  That’s what the last number is for.  If you look at “Script Types” in your Beginner Documentation or in the CAOS Documentation, you’ll see what each number represents.  We want this to be an “Activate 1” script, so we’ll make it 1.

Now the engine is going to add this script to the “Scriptorium”.  Basically it’s an imaginary repertoire of scripts that the engine uses and references when things are activated.

So, when your pointer or a creature goes to push the agent, this script is going to be dragged out of the Scriptorium and ran.  So!  Now we get to write in what happens!  Things are getting exciting! :D

First and foremost we want our vendor to animate.  You can see from the sprite file that we have seven frames of animation to run through. So let’s tell the engine to animate our vendor.

scrp 2 23 9000 1
lock
    frat 2
    anim [0 1 2 3 4 5]
    over

”lock” locks the script.  I don’t want it being interrupted until it’s done. If you put a lock on a script, nothing can interrupt the script once it starts running. This will be necessary because our chocolate only gets vended AFTER the animation.  If it didn’t get locked, a norn could keep pressing the vendor forever, and the animation would keep resetting, but never finish, and thus, never vend any chocolate, and that would be sad. :(  So we’ve locked this script.  It can’t be interrupted until it finishes.

“frat 2” tells the engine that any animations that follow need to have a frame rate of 2. You can think of it as the engine playing each frame twice, thus slowing down the animation by 1/2. A frat of 4 would slow it it down 4xs.

“anim [0 1 2 3 4 5]” this is our animation sequence.  It says start at frame 0, and animate through frames 1 2 3 4 5.

“over” tells the engine, don’t evaluate anything below this command until any animation currently playing finishes. So the engine will “wait” until the animation finishes.  That way the chocolate won’t come out until the chocolate vendor has reached frame 6 (where it actually looks like it’s coming out).

-----

Time to actually make chocolate! :D

This next section is going to be a bit confusing…so I’m going to put it in a brand new post. It’s going to include a lot of new concepts and some review, so that’ll make it all the more difficult.  Stay tuned.

Beginner Tutorial Part 1

So you want to make agents? Awesome! But where do you start? That’s what this post is all about.

The easiest way to understand CAOS is to simply jump right in, but you’ll want a few resources available before you do.  I’m assuming you have already downloaded the CAOS Tool from the Creatures Development Network, or are using some other program to code in.

Also, be sure to download the Sprite Builder tool, or you can use Edos, which comes with the Jagent application suite.

------

First, you’ll want the CAOS guide. You can access it with the CAOS tool by opening the CAOS Tool and pressing F1 or F2 on your keyboard. F1 will open the Alphabetical Guide, while F2 will open the Categorical Guide. The documentation should open in a new browser window.

Alternatively, you can tell the engine to output the CAOS documentation directly. Start Docking Station and press Shift+Ctrl+C and type, “file oope 1 "CAOS categorical.html" 0 dbg: html 1 file oclo” without the quotes, and press enter.

 

Notice the engine said, “OK”.  If it says anything else, try again, and check for typos. The engine will save the HTML file to your Docking Station Journal Directory.  It is located in the same place as your My Agents directory.

Once you’ve navigated to the directory, the file should be there.

You can open this document in any browser.  Safari, Internet Explorer, Firefox, Google Chrome, or whatever you use. :)

This reference is extremely valuable once you really get into coding.

--------

The second thing you’ll want is a handy file I created when I first started developing.  I have supplied this document HERE. [Updated 9/16/10] It contains many of the most basic commands, and frequently referenced values for things like Bhvr, Attr, and the C3/DS Chemical list, as well as a quick overview of basic codes you’ll use frequently as a beginner.

I created one of those when I first started, and it made developing so much easier!  Many of those references are also in the CAOS Documentation, but I find a text document is quicker sometimes, and it’s also more compact.

Feel free to add to your document anything you think you’ll need at any time throughout your developing career. :)  Or delete things you no longer use as you begin to memorize things.

-------

The last thing you’ll want to do is set up some folders.  I KNOW this is tedious and seems like a waste of time, but LET ME ASSURE YOU that you’ll be grateful you did this in the long run.

Create a new folder someplace.  Your desktop, Docking Station directory, My Documents--wherever you feel comfortable--and organize it. For this tutorial I recommend creating the following folder structure:

Stay tuned! In Part 2, we’ll actually code something!  (Part 2 will be up in a few days, if all goes well.)

Why do I develop?

I was reading Amaikokonut’s blog earlier today, and came across an interesting post entitled Why Develop?

I’ve been considering the question of ‘why do I develop’ for so long now I’m no longer entirely sure I know what the question means!

First off, why Creatures, and not some other game? Why not a newer game that combines writing and nice code/art? The answer to this question is pretty simple for me. One, I know these games well. I’ve been playing Creatures for almost 10 years, and I’ve been playing BGII for 7. The next reason is that I know how to develop for these games, and I don’t need to learn a whole new way of thinking. It’s relatively simple for me to pick up the CAOS tool and tap out a functioning agent. But beyond those things, there is something that keeps me coming back.

When I think about it, the pessimist in me says, “What’s the point? The community’s surely no more than thirty people scattered over various sites, and out of that thirty few are actually going to try whatever you make. The community is small, none of the games are officially supported and—let’s face it—the series is thoroughly outdated. Why bother?”

I know several other people who regularly ask themselves this. I’m not the only one. There are so many reasons not to develop for Creatures, so many reasons to pick up the Dragon Age toolset and make a brand-spanking new companion called Jamir who has a penchant for heels and rouge-- or, uh, possibly not--but you get my drift. There are far more recent games, with much larger audiences to play any mods I release.

Despite this, I keep coming back for more. There is something about this game, this series, this concept that just hooks me in. And if I’m honest with myself, it ain’t the norns.

I remember when I was first introduced to Creatures. I was 11 or 12, and Dad bought it from a computing store, thinking that I might enjoy it. I can remember first visiting the CL website and downloading the Purple Mountain Norns, and being so excited at the prospect of playing with new objects and imported norns. (As I recall that was also my first foray into the internet, as well, and we all know how that ended up: I’m virtually attached to a screen at all times.) I would come home from school, boot up Creatures, and play until I was booted off by well-meaning parents worried about the effects of too much time in front of a computer. (They’ve given up now that I’m no longer living at home, thankfully. That would just be awkward.)

I played Creatures 1 because I loved raising norns. I was so attached to them that often remember there being a few tears when they died. It was my great love of norns that drove me to download my first few third-party objects—sadly I don’t remember what they were—but I do remember that they were to help me care for my intrepid creatures. But though my intentions were noble and norn-serving, with those ventures into the world of 3rd party objects, I was forever changed... though I didn’t know it yet.
It didn’t take me long to decide to make my own cobs, though initially I didn’t get far. I think I followed a tutorial on making some cheese, at which point Creatures 2 was bought for me and that was far more interesting. Frustratingly I didn’t find Creatures 2 as engaging as Creatures, but I faithfully played it until I got Docking Station.

Docking Station was something of a turning point in my Creatures-playing-career, as it signified the point where I stopped playing for the creatures themselves. Of course, earlier on I was playing for the new addons, to try out new breeds and cobs, but I was still mainly in it for the norns, ettins and grendels... but with the release of Docking Station, I found I couldn’t engage with my furry liyylr subjects. Still, I loved the look of the game, the new interface, and the plethora of objects that soon became available... as well as the lively atmosphere on Albia2000 and the GE Forums, where I spent much of my online life. The norns didn’t interest me, but the community and the addons did, and I soon decided to help out with several projects.

Within less than a week I was hooked. And then a couple of us developers got to talking, and BLG showed up and posted some amazing artwork on the GE forums, and most of you probably know the story from there.

I’m still not sure what’s so alluring about development itself. I think it’s the strange feeling of joy when you get something ingame that you worked hard to create. It’s hard to describe until you’ve experienced it yourself. It’s very satisfying, and I suspect more than somewhat addictive. Using Docking Station, it’s relatively easy for me to create something and get it ingame due to my previous experience... so it makes sense that I would keep coming back, in that way.

With all this blathering, however, I still haven’t answered the question of why I develop despite the community being small and my paranoia that few people ever actually install and play my modifications. There is just something about the community and the game that keeps me coming back. One theory is that it’s my history, the countless hours I’ve spent participating in the community, the fond memories of development teams and forum roleplay, of hours spent perfecting models in 3D Studio Max and yet more hours spent inputting code to the CAOS tool to make my models come to life.

Or maybe it’s just that Creatures is bloody awesome, and I’m going to keep caring about it and making addons for it until I finally get a job in the game development industry, and maybe beyond.

If I had to choose, I think I like reason #2.

Crossposted to the Creatures Development Blog.

The Lost Cave Released!

The Lost Cave Story
The Albian Temple has always been a mystical place, somehow special beyond others, especially to Norns and Ettins. Perhaps it is no wonder that in the eruption following the Lone Shee's departure from Albia, the Temple was saved. Encased in molten lava, the Temple and its surrounds remained untouched as it was flung into space in the explosion. The lava quickly quickly cooled, forming a protective bubble around the Temple. As the Temple travelled through space, the inhabitants began to evolve, forming entirely new species, distinct from those of Albia. Evidence that some other strange race visited the Temple exist in the form of the symbiotic Caveweed and Cavefish, which are totally unlike anything from Albia. Currently, the Lost Cave (as it has come to be called), is in orbit around a sun in some distant part of the universe.

On one of his regular excursions through the Warp, the Lone Shee came across the Lost Cave... and marvelled at the ability of life to exist in almost any circumstance.

History
The room originally began as a project by artist Bifrost, back in 2004. I (Liam) volunteered to code it, as Bifrost was struggling, and coded several objects before Bifrost and I moved onto other things in our lives and in the community. Several attempts were made to restart the project, but it wasn't until I started working on Creatures 2 to Docking Station with Moe that I began to seriously think about finishing it.

With Moe's help, I pulled together what was existing and between us we added several new things to give the room a little more life, and am now proud to present The Lost Cave to the community.

Credits
The Lost Cave and several of the objects were created by Bifrost. Moe worked to create new images for the remaining objects needed, and shared the code-load. Moe made the fantastic c1-style music and added further sound effects and enhancements. A big thank you to our testers pirate-rob and TreeSprite for ensuring everything worked OK, and for pointing out remaining bugs.

Concept and background: Bifrost
Object graphics: Bifrost & Moe
Coding: Liam & Moe
Descriptions: Moe & Liam
Packaging: Liam

Download the Lost Cave here!

Apple Norns Released!

Hi all!

I've got an exciting announcement to make... after many years languishing on Moe's harddrive, we dusted off a norn breed hitherto unreleased to the CC! With help from Grendel Man, geneticist extraordinaire, we have a fantastic new breed for you to play with.



Pulled from Moe's archives, these Apple Norns, originally meant to be released with the Canopy, are finally seeing the light of day. You can trace the Apple Norns' ancestry back to the Treehugger norns, though these Norns are very social and love to eat fruit. Their fur is waxy and smooth, making them prefer moist environments. They are at one with nature, and will chase clouds or any kind of weather when homesick. They have a strong immune system; boasting a resistance to ATP Decoupler and Cyanide, which is found in trace amounts inside of apple seeds. They tend to be great navigators and bear eggs with considerable ease.

They occupy Norn Slot Y.

Credits:
Liam - Forced takeover of the project!!!
Moe - Images
Edash - Concept
GrendelMan - Genetics
Vampess - CFE Genome

You can download the Apple Norns by clicking on the banner above, or clicking here!

And by popular request, some pictures of the Apple Norns ingame:

Script Masher

So this beta of C2toDS I just released was the amalgamation of 18 separate COS files-- agents with their own install, remove, and event scripts-- and it was made into one injectable COS file in just 2 clicks. Anyone who's ever tried making a large addon like a metaroom or agent pack knows the significance of what I just said…

I too know the pain of trying to take all the install scripts and put them in one document, and then all the different agents' scripts and put them into one document, and all the various removal scripts and put them into one document. Doing this took ages, and I got tired of it after just trying to do my emitters.

So I took my hand to some of the most advanced and clever use of CAOS I've ever endeavored, and I created an agent that would combine them all for me.

Probing the Journal directory for COS files, the Script Masher will load the files, and merge them into one pray ready COS file in just two simple clicks. :) I don’t know how much use it would be to the community, but I’ll release it soon just in case!

Script Reservation Guidelines and Revisions

Since I have taken the liberty of assuming management of Script Reservations for the community, I have implemented a few guidelines to ensure the list is fairly distributed.

Size

Script reservation will be divided into much smaller ranges than in the past. Few, if any developers, have ever filled the previous norm of 100 “script-wide” slots. In fact, I know of no developer who has even made close to 100 agents.

For this reason, script ranges will now be reserved in sets of 10-25, depending on the scope of your needs.

Proof of Ability, Activity

Proof of ability and production will be required. Too many script ranges are[/were] filled with developers who never created anything.

Henceforth, you cannot request a range unless you have something- a script, preferably an image/sprite/background/screenshot, just about anything- that proves that you are able and actively creating work for the Creatures series. You will not be granted a range until proof-of-ability has been provided.

Proof is very important. Your proof will also be the determining factor in how large a script range you are given. IE: You will not get 100 script slots if you only show me a screenshot of a beach ball.

Time-Out

After one year, if you have failed to create content as you had planned, your script range reservation will be truncated or removed, unless you can once again provide proof that you are still actively developing.

You will not be given warning!!! It is your responsibility to keep up with your script range if you have not released agents. I will not hesitate to simply remove your reservation.

Note: This time limit does not apply to those who have used their reserved range at least once.

Identification

You must be able to identify yourself as a member of the community. Provide links to profiles on websites like Creatures Caves, Albia2000, The Creatures Wiki, or Creaturetopia. You will not be given a range unless you can identify yourself as an active member of the community.  Note: The above websites are just examples.  The German and French communities and their respective websites are also perfectly viable for application. :)

Furthermore, if for any reason I e-mail you, and your e-mail is defunct, your range will be deleted or truncated. Please keep an updated e-mail address.

FAQ:

“I had a range! What happened to it?”

I sent out e-mails to all the unidentifiable range holders. If your e-mail address was defunct and no agents could be found bearing your script range, you lost your range. Please keep an up-to-date e-mail address.

“I had a range, and I’ve released agents! What do I do?”

First, let me apologize, secondly, contact me. I’ll restore your range.

“I know someone who has released agents but isn’t on this range!”

Contact me, and I will add them to the range.

“I’ve released agents but don’t have a range!”

Contact me to get one.

“I’m on the list, but I don’t need to be.”

Please contact me so we can free up your range for others.

“I want a range, how do I get one?”

Please ensure that you meet the guidelines listed above.  You must be able to identify yourself in the community and have proof of ability before you will be considered for a range.  If you meet the qualifications, contact me and we will find a range suited to your project scope.

-----------------------

Please understand that I am relying on a mix of memory, intuition, and light research to filter through the script reservations. It is nearly impossible, and unreasonable, for me to track down every agent ever made, decompile or inject it, and identify the script range. If I don’t get a response from attempts at contact, and I don’t know of any of your agents off-hand, I would see no reason to keep your range reserved. My apologies if I accidentally purged your reservation.

 

For comparison purposes, the old reservations page is HERE.