Ever want to use CAOS to check if an object is edible? Invisible? Pickup-able by the hand?
Deciphering ATTR and BHVR values at a glace isn't the easiest thing in the world, and it's not exactly glaringly obvious how one would do so with CAOS, either. This is just a really simple script that teleports everything in the world that is edible by creatures to the hand, to demo how you might go about identifying BHVR or ATTR values in an agent.
enum 2 0 0
setv va00 bhvr
andv va00 16
doif va00 = 16 and movs = 0
mvsf mopx mopy
velo 0 0
endi
next
(Yes, this enums through everything in family 2. In big worlds, on slower machines, you might not want to run this script as it may lag you to oblivion and back. Try a clean DS-standalone world if you're having problems.)
It's really difficult to explain exactly how ANDV works if you have no background knowledge of bitwise operators. Heck, I confuse myself with it. But what you really need to know is this:
If you ANDV an agent's ATTR/BHVR value with the ATTR/BHVR value you're checking for, it will return that same value if it is valid.
Say you want to find out if an agent is set to Suffer Physics (ATTR number 128), you would set the ATTR in a variable and ANDV it 128. If it returns 128, the agent does indeed suffer physics. If it returns anything else, it does not.
So in this above example you can see that we've taken the BHVR number that declares the creature can eat said agent, 16, and ANDV'd it to the BHVR. If it returns 16 (and movs = 0, to stop it from trying to move items in vehicles and throwing errors), it is indeed edible, and thus is moved.
If you run this script, assuming your pointer is in a valid spot, all the edible objects in the world should come spewing forth from your fingertip. You'll notice this includes edible critters, including fish from your ponds and pests. Go on and try it!
You did try it, right?
You've probably noticed then, depending on what you've got in your world, that some of the agents weren't the sort of thing the game intended on having moved. Apples and blossoms may hang in midair, as well as other fruits that had been growing on plants. As an exercise, you might try altering the script to check for physics and collisions as well,
Here's a hint-- you can add the values together that you want to check for. For example, if you wanted to check if a creature could push (BHVR 1) and hit (BHVR 8) an agent, you can add those two and simply ANDV the BHVR 9. If it returns 9, both conditions are true.
I know this is supposed to be a tutorial, but I am having way too much fun spewing food and critters all over the place, so I will have to come back to this later. I am sure you more mature developers out there can actually find something useful to do with these commands.
Wednesday, January 11, 2012
Monday, January 9, 2012
PHP, and other ways to enhance Creatures
I’ve been cheating a bit on CAOS, you see. I’ve decided to branch out a bit and dabble in some other programming languages, starting with PHP. I started by writing up some simple ATTR/BHVR calculators; if you’re a developer, you might find these useful. But I’ve been thinking a lot about other ways programming languages besides CAOS can be used to enhance gameplay and benefit our tiny community as a whole.
Of course, other programming languages have been aiding the CC for a long time. Web-based programming is what brings us wonderful tools like LiveGMS and The Creature Repository, not to mention the Creatures Wiki and all our forums and blogs. And it's hard to even start when you get into non-web applications: all our 3rd party sprite viewers, gene editors, and direct game tools like DevThing... why, the community simply would not be the same without these tools.
I decided to start with PHP because web-based programming seems to be the way of the future. My first inclination, as told by my first calculators, is to use PHP as an aid in writing CAOS.
Now, it wouldn't be too impossible to write, say, a code generator in which you input a few variables like classifiers, image file names, and so on, and it spits out the cosfile for a basic food/toy agent. But I just really don't see that benefiting the community much, especially since, in my opinion, I believe we as developers ought to be focusing on additions to the game that mix things up and change the way we play; not just creating more of the same thing with different sprites.
But on the other hand, it might be a good starting point for new developers-- they might excitedly generate a Creatures version of their favorite toy and then seek to learn out to alter it to make it more complex, which could be a lot less intimidating than writing code from scratch. Something else to consider is the occasional newbie who is still enchanted by vanilla gameplay and would really enjoy a simple way to create their own food and toys on a whim.
But if I'm going to make code generators, I'm more inclined to generate Magic Words templates or code for dialogue boxes (I hate, hate coding dialogue boxes; finding an easier way is actually very high priority for me)
Something else that's been brought up is the notion of a web-based version of EasyPRAY. Personally, I think that utilizing something like CAOS2PRAY would remain easier, since the "blanks" you fill in would be about the same, only you'd have to go through the extra steps of opening your browser and downloading the generated prayfile. But it's still something to consider, particularly since agents for the Garden Box I've been working on actually use their own chunk type-- something neither EasyPRAY nor CAOS2PRAY supports. I also might be able to code a way to search the cosfile for potential dependencies, which could take some work off the developer's hands.
So the potential of using PHP to develop CAOS aids is certainly there, but what about other aspects of development? Something I was tossing in my head long before I picked up PHP was the idea of a site that focused on collaborative community projects, with a variety of features.
The first aspect would be a sort of developers' database, wherein developers (anyone registered on the site) would create a profile containing contact information, information about what they like to develop, their availability, and their skillsets, be that CAOS, spriting, 3D modeling, gene editing, concept sketching, as well as other programming languages and really, any skill that might be useful to the community. You could then basically search for a spriter or a coder or whatever you needed, and then contact them to see if they were interested in helping you out.
The second aspect would be a project ideas database, where people could post project proposals and ideas, and other users could vote in favor or against certain ideas. It would then be easy to gauge what ideas were popular and in demand just by glancing at the list. When an idea became popular enough, it would open up to development. A project manager (by default, the user who proposed the idea, but the role could be handed off to someone else if needed, or even shared among multiple people) would then make a task list.
Each task would include the skillset required and a detailed description of what needed to be done. Some tasks would obviously need do only be done once, something like "Spriting: A red and yellow-striped beach ball with animations for bouncing and popping." but it could also be a repeatable task, especially in the early/planning stages, something like "Sketching: Five concepts for undersea creatures, front and side views."
Interested contributors could then search for tasks that were needed by category and apply for them. Some tasks would require approval of the project manager first (to avoid say, someone signing up for something they may not have the skillset for.) Their contributions to various projects would be tracked in their profile.
Another, sort of offshoot feature would be a favor-trading board. This would be for tasks that aren't a part of a larger project; for example, if I was working on a personal project and need a sprite done, or if someone with no scripting experience just wanted an agent that turned norns to statues when they were touched (or something) and couldn't do it for themselves, they could post this on the favor-trading board, and offer something in exchange from their own skillset.
Something like this, while way out of my league at the moment, is still entirely possible for the future. The biggest problem with something this big and well-organized though, is that our community is simply just too small and inactive to fully utilize it. It would be an enormous amount of work for something maybe twenty or so people would really actively use. Still, it's nice to dream sometimes.
What of you guys? Can you think of any web-based programming possibilities that might benefit the community?
Of course, other programming languages have been aiding the CC for a long time. Web-based programming is what brings us wonderful tools like LiveGMS and The Creature Repository, not to mention the Creatures Wiki and all our forums and blogs. And it's hard to even start when you get into non-web applications: all our 3rd party sprite viewers, gene editors, and direct game tools like DevThing... why, the community simply would not be the same without these tools.
I decided to start with PHP because web-based programming seems to be the way of the future. My first inclination, as told by my first calculators, is to use PHP as an aid in writing CAOS.
Now, it wouldn't be too impossible to write, say, a code generator in which you input a few variables like classifiers, image file names, and so on, and it spits out the cosfile for a basic food/toy agent. But I just really don't see that benefiting the community much, especially since, in my opinion, I believe we as developers ought to be focusing on additions to the game that mix things up and change the way we play; not just creating more of the same thing with different sprites.
But on the other hand, it might be a good starting point for new developers-- they might excitedly generate a Creatures version of their favorite toy and then seek to learn out to alter it to make it more complex, which could be a lot less intimidating than writing code from scratch. Something else to consider is the occasional newbie who is still enchanted by vanilla gameplay and would really enjoy a simple way to create their own food and toys on a whim.
But if I'm going to make code generators, I'm more inclined to generate Magic Words templates or code for dialogue boxes (I hate, hate coding dialogue boxes; finding an easier way is actually very high priority for me)
Something else that's been brought up is the notion of a web-based version of EasyPRAY. Personally, I think that utilizing something like CAOS2PRAY would remain easier, since the "blanks" you fill in would be about the same, only you'd have to go through the extra steps of opening your browser and downloading the generated prayfile. But it's still something to consider, particularly since agents for the Garden Box I've been working on actually use their own chunk type-- something neither EasyPRAY nor CAOS2PRAY supports. I also might be able to code a way to search the cosfile for potential dependencies, which could take some work off the developer's hands.
So the potential of using PHP to develop CAOS aids is certainly there, but what about other aspects of development? Something I was tossing in my head long before I picked up PHP was the idea of a site that focused on collaborative community projects, with a variety of features.
The first aspect would be a sort of developers' database, wherein developers (anyone registered on the site) would create a profile containing contact information, information about what they like to develop, their availability, and their skillsets, be that CAOS, spriting, 3D modeling, gene editing, concept sketching, as well as other programming languages and really, any skill that might be useful to the community. You could then basically search for a spriter or a coder or whatever you needed, and then contact them to see if they were interested in helping you out.
The second aspect would be a project ideas database, where people could post project proposals and ideas, and other users could vote in favor or against certain ideas. It would then be easy to gauge what ideas were popular and in demand just by glancing at the list. When an idea became popular enough, it would open up to development. A project manager (by default, the user who proposed the idea, but the role could be handed off to someone else if needed, or even shared among multiple people) would then make a task list.
Each task would include the skillset required and a detailed description of what needed to be done. Some tasks would obviously need do only be done once, something like "Spriting: A red and yellow-striped beach ball with animations for bouncing and popping." but it could also be a repeatable task, especially in the early/planning stages, something like "Sketching: Five concepts for undersea creatures, front and side views."
Interested contributors could then search for tasks that were needed by category and apply for them. Some tasks would require approval of the project manager first (to avoid say, someone signing up for something they may not have the skillset for.) Their contributions to various projects would be tracked in their profile.
Another, sort of offshoot feature would be a favor-trading board. This would be for tasks that aren't a part of a larger project; for example, if I was working on a personal project and need a sprite done, or if someone with no scripting experience just wanted an agent that turned norns to statues when they were touched (or something) and couldn't do it for themselves, they could post this on the favor-trading board, and offer something in exchange from their own skillset.
Something like this, while way out of my league at the moment, is still entirely possible for the future. The biggest problem with something this big and well-organized though, is that our community is simply just too small and inactive to fully utilize it. It would be an enormous amount of work for something maybe twenty or so people would really actively use. Still, it's nice to dream sometimes.
What of you guys? Can you think of any web-based programming possibilities that might benefit the community?
Sunday, January 8, 2012
CAOS2PRAY: An Easier Way
Sometime
last fall, while I was preparing for CCSF, I discovered a little thing
known as CAOS2PRAY. It would not be too much of a stretch to claim that,
were it not for CAOS2PRAY, I may not have gotten around to releasing as
many agents as I did, because I hate, hate hate hate writing prayfiles,
and even easyPRAY was giving me problems.
CAOS2PRAY is basically a method of embedding your PRAY info in your .cos file so you don't have to deal with a separate file (or if you're using easyPRAY, a separate program as well). I really feel that it is a wonderfully simple way to compile agents, but is not very well known or understood; hence this little guide.
All I learned about CAOS2PRAY, I learned from the official documentation here. This tutorial attempts to simplify that manual, but you should refer to it for further information.
CAOS2PRAY was actually developed by RProgrammer as part of Jagent. As such, you need to use Monk to compile your agents for it to be effective. Malkin has already written a simple guide to Monk, so I'll skip those details and jump right into the unknown. Note that this tutorial also assumes you've written a PRAY file before and understand what information is generally required.
Again, CAOS2PRAY is not a program or anything of the sort. It's basically just a syntax you follow to, instead of writing the prayinfo in a separate file, write in the cosfile itself, in a much more simplified fashion.
If you were to decompile my Advanced Muco (or any of my more recent agents), you would notice the top of the cosfile contains text like this:
**CAOS2PRAY
*# Pray-File "advmuco.agents"
*# DS-Name "Advanced Muco"
*# Depend blnk.c16
*# attach advmucoo.c16 advmucohelp.catalogue
*# desc = "A display next to Muco the Egg Layer that allows you to choose breeds from a list."
*# Agent Animation File = "advmucoo.c16"
*# Agent Animation String = "0 1 255"
*# Agent Sprite First Image = 0
*# Agent Animation Gallery = "advmucoo"
*# Web URL = "naturingnurturing.blogspot.com"
*# Web Label = "Naturing :: Nurturing"
This is all I needed to write. Then I just made sure all the inline files were in the same folder, dragged and dropped the cosfile onto monk, and it spit out a complete and packaged agentfile, no prayfile required! It's incredibly easy to write up a "template" like the one above and just copy/paste it at the beginning of your cosfiles, changing the info as needed.
Now, if you're a careful observer, you may have noticed that some lines in the example contain equal signs [=] while others do not. That is because there are two different sorts of lines that Monk understands, commands and tags.
Tags are very simple, so we'll start with them. They're the ones with the equal signs, and they translate directly to the prayfile.
Let's say you write the following lines in CAOS2PRAY:
*# Agent Animation Gallery = "advmucoo"
*# Agent Sprite First Image = 0
*# Banana Cream Pie = "in your face"
*# Number of Pies = 42
This is the same thing as writing the following in a typical prayfile:
"Agent Animation Gallery" "advmucoo"
"Agent Sprite First Image" 0
"Banana Cream Pie" "in your face"
"Number of Pies" 42
Not that you would actually need to define the latter two unless you had a modified agent injector that read those values, but you get the point.
At first glance, it may appear that CAOS2PRAY is more writing than a typical prayfile. But there are shortcuts available, too. You may have noticed in the example, a tag simple labeled "desc"
*# desc = "A display next to Muco the Egg Layer that allows you to choose breeds from a list."
Monk translates this to the following in the prayfile:
"Agent Description" "A display next to Muco the Egg Layer that allows you to choose breeds from a list."
It doesn't matter if you use "desc" or "Agent Description" -- it will be read the same way. Here are the shortcuts that Monk supports:
"anim" -- "Agent Animation String"
"anim file" -- "Agent Animation File"
"desc" -- "Agent Description"
"anim start" OR "anim img" OR "anim image" OR "first image" -- "Agent Sprite First Image"
"bioenergy" "Agent Bioenergy Value"
As you can see, there are shortcuts for a lot of values in the example that I chose to write out instead of using the shortcut. I'm not really sure why I did that. Obviously if you're typing it all out by hand, it would be quicker to use the shortcuts, but in the end it doesn't matter which you use, especially if you're just copy-pasting a template.
Now, the commands. This is where CAOS2PRAY really shines.
Command lines do not contain equal signs, they are simply written as {command} {something}.
The commands are as follows:
Pray-File: This is what the output file will be named. Be sure to include the .agent extension. This is required!
DS-Name: The name of the agent as displayed in the DS agent injector.
C3-Name: The name of the agent as displayed in the C3 agent injector. Only required if your agent is C3-standalone compatible. Remember that your C3 agent name cannot be the same as your DS agent name!
Depend: This specifies dependencies (images, sounds, etc that the agent needs to function) but does not compile them into the agent. These must be separated by spaces and include the file extension. The nice thing about this is that you don't have to define a category like you would when writing a PRAYfile by hand; Monk does this for you. As you can see in my example, I got lazy and didn't include all the dependencies my agent needed. You should probably not follow my example, and instead try to list all the images, sounds, etc that the agent needs, even if they are included with C3/DS, because you never know when someone might accidentally delete half their sounds folder and then spam you with angry messages when they inject your agent and it gets autokilled instead of just throwing a dependency error.
Attach: This specifies dependencies and compiles them into the agent. Monk will throw an error if you don't have these files included in the folder with the cosfile while compiling the agent. Same rules apply as with Depend (must be separated by spaces and include the file extension). You use this for sprites, sounds, catalogue files, etc that are not native to C3/DS. If you list a file in Attach, you do not have to list it in Depend.
Inline: This compiles files into the agent, but will not specify them as a dependencies (unless you also list them in Depend). I'm not really sure why you would use this when you can just use Attach, but it's there, just in case.
Link: Supposedly this allows you to link to other cosfiles you want to include in the agent. I've never used it, though.
As I mentioned earlier, Monk finds your agent's remove script on its own-- you don't need to specify it manually like you would when writing up a prayfile by hand.
Hopefully this guide will help some of you get a grasp on CAOS2PRAY and have an easier time compiling C3/DS agents. If you have any trouble, get confused, or notice any errors in this guide, do let me know. I aim to keep this as understandable and accurate as possible.
CAOS2PRAY is basically a method of embedding your PRAY info in your .cos file so you don't have to deal with a separate file (or if you're using easyPRAY, a separate program as well). I really feel that it is a wonderfully simple way to compile agents, but is not very well known or understood; hence this little guide.
All I learned about CAOS2PRAY, I learned from the official documentation here. This tutorial attempts to simplify that manual, but you should refer to it for further information.
CAOS2PRAY was actually developed by RProgrammer as part of Jagent. As such, you need to use Monk to compile your agents for it to be effective. Malkin has already written a simple guide to Monk, so I'll skip those details and jump right into the unknown. Note that this tutorial also assumes you've written a PRAY file before and understand what information is generally required.
Again, CAOS2PRAY is not a program or anything of the sort. It's basically just a syntax you follow to, instead of writing the prayinfo in a separate file, write in the cosfile itself, in a much more simplified fashion.
If you were to decompile my Advanced Muco (or any of my more recent agents), you would notice the top of the cosfile contains text like this:
**CAOS2PRAY
*# Pray-File "advmuco.agents"
*# DS-Name "Advanced Muco"
*# Depend blnk.c16
*# attach advmucoo.c16 advmucohelp.catalogue
*# desc = "A display next to Muco the Egg Layer that allows you to choose breeds from a list."
*# Agent Animation File = "advmucoo.c16"
*# Agent Animation String = "0 1 255"
*# Agent Sprite First Image = 0
*# Agent Animation Gallery = "advmucoo"
*# Web URL = "naturingnurturing.blogspot.com"
*# Web Label = "Naturing :: Nurturing"
This is all I needed to write. Then I just made sure all the inline files were in the same folder, dragged and dropped the cosfile onto monk, and it spit out a complete and packaged agentfile, no prayfile required! It's incredibly easy to write up a "template" like the one above and just copy/paste it at the beginning of your cosfiles, changing the info as needed.
- To make use of CAOS2PRAY, you need to understand a few things:
- Since you're putting this text directly in the cosfile, you have to start each line with an asterisk [*] to comment it out so it doesn't throw errors when C3/DS tries to read it.
- When compiling with CAOS2PRAY, Monk searches for the hash/pound sign [#]. Thus, you have to start each line that you want Monk to recognize with the asterisk followed by the hash sign [*#]. The only exception is the remove script, which Monk finds on its own.
- It's best to put your CAOS2PRAY info at the top of your cosfile, or at the very least, not at the bottom. Once Monk hits your remove script, it will stop reading further commands, so if your info is at the bottom, under your remove script, Monk won't see it.
Now, if you're a careful observer, you may have noticed that some lines in the example contain equal signs [=] while others do not. That is because there are two different sorts of lines that Monk understands, commands and tags.
Tags are very simple, so we'll start with them. They're the ones with the equal signs, and they translate directly to the prayfile.
Let's say you write the following lines in CAOS2PRAY:
*# Agent Animation Gallery = "advmucoo"
*# Agent Sprite First Image = 0
*# Banana Cream Pie = "in your face"
*# Number of Pies = 42
This is the same thing as writing the following in a typical prayfile:
"Agent Animation Gallery" "advmucoo"
"Agent Sprite First Image" 0
"Banana Cream Pie" "in your face"
"Number of Pies" 42
Not that you would actually need to define the latter two unless you had a modified agent injector that read those values, but you get the point.
At first glance, it may appear that CAOS2PRAY is more writing than a typical prayfile. But there are shortcuts available, too. You may have noticed in the example, a tag simple labeled "desc"
*# desc = "A display next to Muco the Egg Layer that allows you to choose breeds from a list."
Monk translates this to the following in the prayfile:
"Agent Description" "A display next to Muco the Egg Layer that allows you to choose breeds from a list."
It doesn't matter if you use "desc" or "Agent Description" -- it will be read the same way. Here are the shortcuts that Monk supports:
"anim" -- "Agent Animation String"
"anim file" -- "Agent Animation File"
"desc" -- "Agent Description"
"anim start" OR "anim img" OR "anim image" OR "first image" -- "Agent Sprite First Image"
"bioenergy" "Agent Bioenergy Value"
As you can see, there are shortcuts for a lot of values in the example that I chose to write out instead of using the shortcut. I'm not really sure why I did that. Obviously if you're typing it all out by hand, it would be quicker to use the shortcuts, but in the end it doesn't matter which you use, especially if you're just copy-pasting a template.
Now, the commands. This is where CAOS2PRAY really shines.
Command lines do not contain equal signs, they are simply written as {command} {something}.
The commands are as follows:
Pray-File: This is what the output file will be named. Be sure to include the .agent extension. This is required!
DS-Name: The name of the agent as displayed in the DS agent injector.
C3-Name: The name of the agent as displayed in the C3 agent injector. Only required if your agent is C3-standalone compatible. Remember that your C3 agent name cannot be the same as your DS agent name!
Depend: This specifies dependencies (images, sounds, etc that the agent needs to function) but does not compile them into the agent. These must be separated by spaces and include the file extension. The nice thing about this is that you don't have to define a category like you would when writing a PRAYfile by hand; Monk does this for you. As you can see in my example, I got lazy and didn't include all the dependencies my agent needed. You should probably not follow my example, and instead try to list all the images, sounds, etc that the agent needs, even if they are included with C3/DS, because you never know when someone might accidentally delete half their sounds folder and then spam you with angry messages when they inject your agent and it gets autokilled instead of just throwing a dependency error.
Attach: This specifies dependencies and compiles them into the agent. Monk will throw an error if you don't have these files included in the folder with the cosfile while compiling the agent. Same rules apply as with Depend (must be separated by spaces and include the file extension). You use this for sprites, sounds, catalogue files, etc that are not native to C3/DS. If you list a file in Attach, you do not have to list it in Depend.
Inline: This compiles files into the agent, but will not specify them as a dependencies (unless you also list them in Depend). I'm not really sure why you would use this when you can just use Attach, but it's there, just in case.
Link: Supposedly this allows you to link to other cosfiles you want to include in the agent. I've never used it, though.
As I mentioned earlier, Monk finds your agent's remove script on its own-- you don't need to specify it manually like you would when writing up a prayfile by hand.
Hopefully this guide will help some of you get a grasp on CAOS2PRAY and have an easier time compiling C3/DS agents. If you have any trouble, get confused, or notice any errors in this guide, do let me know. I aim to keep this as understandable and accurate as possible.
Monday, December 5, 2011
"Garden Box" Mini-injector-- Another sort of opinion poll
So while I was brainstorming the structure and logic of the aforementioned planting-stuff-into-walls agent, I stumbled on an idea that I'm not sure how I feel about.
The goal of this agent is to make world-customizing easier and more interesting, but the way I have the agent currently planned out, it might be a little laborious. If you wanted to plant a strawberry patch, you would have to go to the injector room, inject the strawberry planter agent (assuming you already had the plant-stuff-into-walls-core installed), scroll back to the room you wanted to plant the patch, find the spot to plant the patch (a bit of a pain in large worlds like C2inDS), and plant it. Now imagine you want to plant six, or twelve strawberry patches. You would have to go back and reject the module each time, re-find the place you wanted to plant it, and so on. This, to me, sounds like anything but what the joy of customizing a world should be.
There are a few different ways to make this a bit easier, like creating reusable seed packets that one can just carry around with them to create more patches. I don't know about you guys, but I don't really know what to do with seed vendors once I'm done with them; I don't like to have them imposing on the scenery and if I stick them somewhere I tend to lose them. Maybe that's just me.
My current brainstormed-solution is to, instead, create what I am terming a "Garden Box." This would essentially become and contain the plant-stuff-into-walls-core, and would sit as a little icon in the bottom corner of your screen, that when clicked, would expand into a floating box containing a list of all the garden box modules you have installed. From there all you would have to do is select the plant you wanted, confirm it, and plant your patch. When you were finished, the box could be minimized back to its icon form.
Something like this could be expanded far beyond an easy way to use wall-plantable agents; it could be expanded to contain other seed modules too, and possibly critters, scenery objects, etc., so you would basically have a centralized place for world-customizing stuff. Plants and critters already native to C3/DS would (I think) be fairly easy to add to the box, for easy re-creation in other areas of the world. Creators would have to rewrite any existing 3rd party agents if they wanted them to show up in the Garden Box (hopefully something that wouldn't be too difficult if I can implement it right), so it wouldn't be a universal solution by any means, but it still could simplify things.
What do you guys think? Is there a better solution to this? Does it bother you having to reinject an agent several times? Do you try to avoid having a bunch of seed vendors lying around? Does something like the Garden Box sound worth the wait, or should I just focus on the wall-plantable stuff on its own?
The goal of this agent is to make world-customizing easier and more interesting, but the way I have the agent currently planned out, it might be a little laborious. If you wanted to plant a strawberry patch, you would have to go to the injector room, inject the strawberry planter agent (assuming you already had the plant-stuff-into-walls-core installed), scroll back to the room you wanted to plant the patch, find the spot to plant the patch (a bit of a pain in large worlds like C2inDS), and plant it. Now imagine you want to plant six, or twelve strawberry patches. You would have to go back and reject the module each time, re-find the place you wanted to plant it, and so on. This, to me, sounds like anything but what the joy of customizing a world should be.
There are a few different ways to make this a bit easier, like creating reusable seed packets that one can just carry around with them to create more patches. I don't know about you guys, but I don't really know what to do with seed vendors once I'm done with them; I don't like to have them imposing on the scenery and if I stick them somewhere I tend to lose them. Maybe that's just me.
My current brainstormed-solution is to, instead, create what I am terming a "Garden Box." This would essentially become and contain the plant-stuff-into-walls-core, and would sit as a little icon in the bottom corner of your screen, that when clicked, would expand into a floating box containing a list of all the garden box modules you have installed. From there all you would have to do is select the plant you wanted, confirm it, and plant your patch. When you were finished, the box could be minimized back to its icon form.
Something like this could be expanded far beyond an easy way to use wall-plantable agents; it could be expanded to contain other seed modules too, and possibly critters, scenery objects, etc., so you would basically have a centralized place for world-customizing stuff. Plants and critters already native to C3/DS would (I think) be fairly easy to add to the box, for easy re-creation in other areas of the world. Creators would have to rewrite any existing 3rd party agents if they wanted them to show up in the Garden Box (hopefully something that wouldn't be too difficult if I can implement it right), so it wouldn't be a universal solution by any means, but it still could simplify things.
What do you guys think? Is there a better solution to this? Does it bother you having to reinject an agent several times? Do you try to avoid having a bunch of seed vendors lying around? Does something like the Garden Box sound worth the wait, or should I just focus on the wall-plantable stuff on its own?
Saturday, December 3, 2011
CCSF wrap-up, Advanced Muco Bugs, Looking Ahead
CCSF really, really burned me out, guys. Wow. I've never done so many things at once in such a short period of time. I think I had a total of like fifteen downloads throughout the whole thing. Granted most of them were only a few lines of code, but that's still quite a bit to put out.
I never got a chance to write a proper wrap-up post. After it was over, I furiously scrambled to catch up on my NaNoWriMo story (which I did manage to finish, but wow I have never written a worse story in my life), and well, it's not too hard to tell how creatively exhausted I am right now. Kind of a shame too, considering I really wanted to contribute to the Creatures Community Advent Calendar but I simply had nothing left in me.
I really wanted to thank everyone who made blog posts during the CCSF; I don't know about everyone else, but for me it was really inspiring to see something new happening every day, and went a long way in motivating me to keep up as well. I originally planned on making some little award buttons/banners for the participants, but it was just something that kept getting pushed to the back burner. It's still something I'd like to do, though, belated as it may be.
Also, there have been a couple reports on Advanced Muco acting a little bit funny when used to select creature breeds that have never been injected before. I haven't had a chance to thoroughly investigate this, but in the meantime, if you're having a problem with a breed of creature that you haven't yet injected throwing errors/autokilling muco when selected via Advanced Muco, try using Advanced Muco to select the creature before the newly installed breed, then clicking on muco itself to select the next breed the old-fashioned way. Inject the egg, and hopefully you won't have any more problems selecting the breed normally via Advanced Muco. If you have any other issues with this, do let me know. It's something I'll look into eventually, and it will be be big help if I have some specific details from you guys.
In spite of all this creative exhaustion, my mind is already hatching new ideas for agents. The release of the Biodomes especially got me thinking about pulling away from my current obsessions with norn genetics/interaction/functionality and looking a little more at world customization.
One thing I'm tossing around in my head right now is an agent that essentially lets you plant a fruit or nut into the background/wall. You would select a region of the world (the idea being that you would do this with an area of the background that contains an image of a shrub or tree, but of course you could do whatever you wanted), possibly set some settings (like if you only want the fruit to grow in certain seasons, how often it should grow, etc), confirm it, and then the fruit would just start spawning in that selected area of the background, giving the illusion that the bush (or whatever) is bearing fruit. Kind of like the apples and seed pods grow in the C3 norn area-- they don't really grow on a plant agent, they're just set up to spawn in random areas of the treehouse.Would open up some nice world customization abilities anyway.
What do you guys think? I think I could set it up to be modular, so you could inject the "plant stuff into wall" core, and then individual agents for each type of food-- lemons, justanuts, apples, whatever, so it wouldn't be too hard for developers to make their own wall-plantable foods; it would just be a matter of writing a basic food agent and setting a few variables that sync up with the core. Could be fun? Maybe?
I never got a chance to write a proper wrap-up post. After it was over, I furiously scrambled to catch up on my NaNoWriMo story (which I did manage to finish, but wow I have never written a worse story in my life), and well, it's not too hard to tell how creatively exhausted I am right now. Kind of a shame too, considering I really wanted to contribute to the Creatures Community Advent Calendar but I simply had nothing left in me.
I really wanted to thank everyone who made blog posts during the CCSF; I don't know about everyone else, but for me it was really inspiring to see something new happening every day, and went a long way in motivating me to keep up as well. I originally planned on making some little award buttons/banners for the participants, but it was just something that kept getting pushed to the back burner. It's still something I'd like to do, though, belated as it may be.
Also, there have been a couple reports on Advanced Muco acting a little bit funny when used to select creature breeds that have never been injected before. I haven't had a chance to thoroughly investigate this, but in the meantime, if you're having a problem with a breed of creature that you haven't yet injected throwing errors/autokilling muco when selected via Advanced Muco, try using Advanced Muco to select the creature before the newly installed breed, then clicking on muco itself to select the next breed the old-fashioned way. Inject the egg, and hopefully you won't have any more problems selecting the breed normally via Advanced Muco. If you have any other issues with this, do let me know. It's something I'll look into eventually, and it will be be big help if I have some specific details from you guys.
In spite of all this creative exhaustion, my mind is already hatching new ideas for agents. The release of the Biodomes especially got me thinking about pulling away from my current obsessions with norn genetics/interaction/functionality and looking a little more at world customization.
One thing I'm tossing around in my head right now is an agent that essentially lets you plant a fruit or nut into the background/wall. You would select a region of the world (the idea being that you would do this with an area of the background that contains an image of a shrub or tree, but of course you could do whatever you wanted), possibly set some settings (like if you only want the fruit to grow in certain seasons, how often it should grow, etc), confirm it, and then the fruit would just start spawning in that selected area of the background, giving the illusion that the bush (or whatever) is bearing fruit. Kind of like the apples and seed pods grow in the C3 norn area-- they don't really grow on a plant agent, they're just set up to spawn in random areas of the treehouse.Would open up some nice world customization abilities anyway.
What do you guys think? I think I could set it up to be modular, so you could inject the "plant stuff into wall" core, and then individual agents for each type of food-- lemons, justanuts, apples, whatever, so it wouldn't be too hard for developers to make their own wall-plantable foods; it would just be a matter of writing a basic food agent and setting a few variables that sync up with the core. Could be fun? Maybe?
Subscribe to:
Posts (Atom)