|Hopelessly Lost in Coding on 5/24/2013 | 1 comment | 2 likes
I've been dreaming up things to make into agents and metarooms since I was a little girl, and I've got the artsy part down pat, but I lack the most important skill for making such things! I have a complete lack of coding knowledge. I'm eager to learn, but I don't even know where to start!
First thing's first, where can I learn what all this coding gobbledygook means? What tools do I need? Have you any tips for an eager beginner? I'm drowning in a sea of ideas, with no way of making them a reality!
I'm happy to be able to say that we have a great series of beginner's tutorials right here on CreaturesCaves: the CAOS Chaos trilogy, written by our very own AquaShee! These were the tutorials I used when I first started agenteering, so I can vouch for their helpfulness. The first installment also lists the basic programs you'll need to make a simple agent, which makes it an excellent starting point.
I'd also recommend checking out the CAOS section on this page, in addition to this article, both of which list a lot of development-related resources that may be of use to you.
Probably the best advice I can give you other than that is to grab the CAOS documentation (the first link in the paragraph above explains how) because it lists a lot of really great information. The descriptions of CAOS commands are a little tricky to understand at first, but the lists of attributes, stimuli, script numbers, etc. become extremely handy as you start making a wider range of agents.
Good luck with your foray into coding, it's always great to see new people getting started!
|How a Hungry Critter Eats on 5/23/2013 | 1 comment | 1 like
When making a critter agent that eats other foodstuff agents, what's the benefits and drawbacks of using "kill targ" on the foodstuff or using "mesg writ" to trigger the "I have been eaten" script for the foodstuff itself?
I used to use "kill targ" exclusively whenever a critter ate another agent, until AquaShee pointed out the advantages of the "mesg writ" method; since then I've been sold on the idea, and am biased against using "kill targ" except when necessary. Most of the reasons for triggering the foodstuff's eat script instead of killing it relate to flexibility and compatibility, such as:
1. Sometimes edible agents have relationships with other agents, which can go awry if the edible agent suddenly disappears. This is more likely to be true of other agent types (eg. flowers) than standard foods, but is good to keep in mind in general. Agents' own scripts usually have failsafes to keep them from being eaten when they shouldn't be, but killing the agent forces the critter to essentially cross its fingers and hope it didn't just cause a disaster for the other agent or its "friends".
2. Sometimes the edible agent might be "inedible" temporarily. For instance, if a carrot is not yet fully grown, it might be invisible and inedible for Creatures. In that case, you might not want your critter to indiscriminately eat the baby carrots. You might be able to have the critter check the food object's code to see what growth stage it's at, and this may not be too impractical if your critter only eats one or a few specific food types. But it's still a lot simpler to just trigger the eat script instead, and let the food agent handle the attempt the same way it would handle a Creature trying to eat it.
3. Sometimes we might run into the opposite scenario: a food agent that is meant to be eaten, but isn't supposed to get used up in the process--such as the fish food agents designed to keep the stickeltrout from dying out. In such cases, forcing the agent to disappear after it's eaten could have very annoying consequences. I might feel safe if my critter eats food instead of bugs, but you never know when someone will invent an "infinite block of cheese" that my critter will perceive as less than infinite; at least if I use "mesg writ", that other person's agent can still function the way they wanted it to, without my critter making a pest of itself. (No pun intended)
4. Using the food's eat script also enables the critter to take advantage of any other special features the food might have. If I use the "kill targ" method for my critter, it has to determine the sound effect used when it eats food, and the food is gone after the first bite, unless I hard-code it to check the food type. But if I use the "mesg writ" method, the food itself will determine all the specifics. The sound effect will always be consistent for that kind of food, and if it has multiple bites, the critter will be able to take a single bite out of it instead of eating the whole thing in one go.
5. The critter will always eat food agents appropriately, even ones that will be developed after the critter itself is released; if a new food behaves differently than the critter's coding anticipated, all will still run smoothly, without the need for an update.
There are still other situations in which "kill targ" is a more appropriate choice. Perhaps I made an agent a year ago that isn't edible, and now I want to make a critter that can eat it. To use "mesg writ" I would need to patch the old agent to make it edible. Or I can just make things easy on myself and use "kill targ". I'm already familiar with how the old agent works, so it's relatively safe for me to do it that way.
Or as another example, Norns aren't edible, but I wouldn't want to make them edible just so that Rexes could eat them using "mesg writ"... that would open the door for things I might not want my Norns to do to one another, or it might conflict with other scripts I had planned.
But hopefully this has given you some idea of why "mesg writ" can be useful for a hungry critter... and why sometimes it is not so useful!
|Blender on 5/23/2013 | 2 comments | 1 like
I've gotten the basics of Blender down, and I have finished my first model! However, I'm now stuck trying to figure out how I'm going to turn my model into a set of functioning sprites!
What process did you go through to get your Blender creations in the game? Do you have any tips or tricks for people wanting to make multiple sprites from the same model? What kind of lighting do you use?
First of all, congrats on your first model!
Spriting is not usually difficult--especially if you have a program like Photoshop or Gimp which you can use to edit your sprites. However, you've asked a lot of good questions, so I'm going to write you a bit of a novel.
The first thing to be aware of is the fact that pure black will be transparent in Creatures; you can try making your object's textures Emit just a little (a trick Moe taught me) so that its shadows will never be pure black, or you can adjust the lighting in another program after you render. The end results are the same, but the Emit method takes less time.
The second thing to be aware of is the way Blender handles blurring (called anti-aliasing). The scene settings screen includes options to change anti-alias settings; you can turn it off completely by unchecking the "oversampling" button. You may also want to experiment with what kind of anti-aliasing is applied (in my version, the drop-down box is located beneath the oversampling button). The default is Gaussian, but I like CatRom better because it preserves more detail.
Once you've adjusted the camera position and dimensions, and anything else you might want to fine tune, hit the "Render" button or hit F12 to render. Blender does have settings to let you save a rendered image in BMP, PNG, etc. format. I know Moe developed a method for batch processing the render-save process, but I'm not very savvy about batch processing. I usually just cheat and print-screen the finished render, then paste it into Photoshop.
Theoretically, you can completely skip the need for further processing by making your object Emit a little, turning anti-aliasing off, and making the background black.
My favorite method is to render the sprite itself with oversampling turned on, so the details will look nice and pretty. Then I render a second version with oversampling switched off. That way I end up with both a "pretty" sprite with smooth details, and an exact outline I can use to cut out the background in Photoshop.
For multiple sprites:
If we're talking about something that could conceivably have joints (an animal, a robot, a tree with swaying branches, etc.), it's best to give it a skeleton and create an animation. (I learned the basics from Blender 3D: Noob to Pro.)
If it's something that can't have a skeleton, but undergoes some basic transformation like getting bigger (a growing plant) or turning at an angle (a rolling ball), animations are good for that kind of thing too. Blender animations let you "tween" an object, so you only need to specify the number of frames, and the beginning and end settings, and it will calculate the settings for the frames in-between for you.
If it's something so drastic that you really need to use multiple models, an easy way to handle that kind of scenario is to put each duplicate on a different layer in the same file. (In my version of Blender, the layers appear as a grid of white squares just below the camera window.) Hit 'M' and pick a square to move an object to a different layer.
The same object can be placed on more than one layer if you like (hold down Shift to select multiple squares), so you can have a machine with some stationary parts, include the same lamps on all layers for consistent lighting, etc. Only the objects/lamps on the layer you're currently viewing will be rendered, so it's a lot like having multiple files in one--except lighting and texture changes are a lot easier.
For lighting techniques:
I don't have any set "formula" for lighting, because different settings may look better on differently shaped or textured objects. What looks really good on a soccer ball might look really bad on a stingray, and vice-versa. Each object is an experiment.
In general, it helps to have one bright light high up (the "sun" and dimmer lights on the sides, at roughly the same height as the object. This can help make it look like you have more diffused, natural lighting. Experimenting with the side lamps' settings can give a lot of interesting results; you can try making them different colors, or turning specularity off (on the same panel where you change their color/brightness) which will make it so that the object doesn't shine where those lights hit it. That makes it a lot easier to include more light sources, and still keep them subtle.
|Free Graphics Programs? on 5/23/2013 | comment | 1 like
What are your favourite free graphics programs? What tutorials are there for these free graphics programs that have really helped you in your developing?
Although I don't use very many free programs, even if I did I still know what my favorite would be: Blender!
It definitely has a steep learning curve; the trick for me was to experiment lots. It's best to start out by goofing off and exploring, instead of starting projects right away and hoping they will be usable. Or if you hate spending time on stuff you won't use, consider a poorly made model to be the equivalent of a "sketch" drawn on paper: not the final product, but a "rehearsal" to remind you of what your goal is and how you might (or might not!) go about making it.
Blender has changed so much over the past five years that most of the tutorials I relied on either no longer exist, or they wouldn't make any sense to people using newer versions of the program. Generally speaking, though, there are three kinds of resources that I would recommend:
1. I'd pick a video tutorial over a written one any day. Some processes (like modeling a soccer ball) are much easier shown than described, and if you're having trouble finding things on the program's interface, they can help immensely.
2. Blender 3D: Noob to Pro covers a ton of different concepts. I'm not sure how much it's kept up with the times, but out of all the written tutorials I've used, this series was some of the easiest to understand.
3. A good forum where you can ask for help, and see what tricks other people have learned. My favorite forum no longer exists, but there are plenty of others out there, including Blender.org's own official forum.