Inactive Creature Definitions
- Thread starter woodspeople
- Start date
One more time let me explain what I have been trying to do. Most of my development work over the past 25 years has been in research prototyping, proof of concept, brainstorming, scoping, exploring at the starts of large projects. This is a standard process and one I have gone through dozens of times, usually in a group. You all seem to be unfamiliar with it, but I assure you it is well established, reliable and practiced (and recognized) by many.
What I am trying to do is:
1. Make a list of a million questions you could ask about a minion or group of minions. Stop when it seems like the list is wrapping around onto itself again.
2. Go through the list. Choose some subset of the questions that are more likely to matter for the society of mods that will grow up around the game. Base this choice on group intuition: whatever seems most exciting, important, big.
3. For that subset, go through this process:
a. Come up with at least two and no more than five answers to each question. Each answer must start with the words, "I want to write a mod in which..." Example: To the question "can minions carry things" one answer is "I want to write a mod in which the player interacts with donkeys as beasts of burden. They carry stuff for the player, and they carry the player. The player can increase what their donkey can carry by "leveling it up" with enchantments created using essences derived from increasingly rare plants found in the world. The donkey can never be carried by the player; it is large and too heavy. It is also stubborn, however, so the player must find other means to get it to move when it doesn't feel like moving: carrots, sticks, other donkeys, etc."
b. For each answer-mod, answer these two additional questions:
I. What information does this mod need to work? Is that information likely to be specific to that mod, or can it be expected to be shared among many different mods? Should it be something each mod has to instigate, calculate, and keep track of itself, or should there be a centralized facility for doing so in the game engine? For the donkey mod, it would be important to keep track of weight capacity the donkey can carry. Weight capacity is likely to come up for many other mods, since help carrying things is something likely to come up often in various ways (magical trunk, steampunk airship, pipeline, etc). So that's a low-level requirement with widespread use. However, leveling up donkeys and keeping track of leveling-up points, as well as placement of rare plants, is likely to be limited to this mod or a few similar; so that is not information usefully kept at the low level.
II. What functionality does this mod need to work? Is that functionality likely to be specific or general? For the donkey mod, it will need some way for the player to put things in the donkey pack, see what's in there, and take them out again. This might piggyback on the chest interface, so no extra functionality is needed, and if the mod makers want more they can add it themselves.
After this process is complete, what results is a prioritized list of metadata and functionality worth building into the game engine that will support the rapid proliferation of a robust society of mods that do many amazing things regarding minions, towards the creation of a "game of games" lots of people want to play. When implemented, this list of features in the modding system will make the game attractive not only to players but also to modders, who are the sina qua non of a game like this growing to immense heights of popularity.
What I am trying to do is:
1. Make a list of a million questions you could ask about a minion or group of minions. Stop when it seems like the list is wrapping around onto itself again.
2. Go through the list. Choose some subset of the questions that are more likely to matter for the society of mods that will grow up around the game. Base this choice on group intuition: whatever seems most exciting, important, big.
3. For that subset, go through this process:
a. Come up with at least two and no more than five answers to each question. Each answer must start with the words, "I want to write a mod in which..." Example: To the question "can minions carry things" one answer is "I want to write a mod in which the player interacts with donkeys as beasts of burden. They carry stuff for the player, and they carry the player. The player can increase what their donkey can carry by "leveling it up" with enchantments created using essences derived from increasingly rare plants found in the world. The donkey can never be carried by the player; it is large and too heavy. It is also stubborn, however, so the player must find other means to get it to move when it doesn't feel like moving: carrots, sticks, other donkeys, etc."
b. For each answer-mod, answer these two additional questions:
I. What information does this mod need to work? Is that information likely to be specific to that mod, or can it be expected to be shared among many different mods? Should it be something each mod has to instigate, calculate, and keep track of itself, or should there be a centralized facility for doing so in the game engine? For the donkey mod, it would be important to keep track of weight capacity the donkey can carry. Weight capacity is likely to come up for many other mods, since help carrying things is something likely to come up often in various ways (magical trunk, steampunk airship, pipeline, etc). So that's a low-level requirement with widespread use. However, leveling up donkeys and keeping track of leveling-up points, as well as placement of rare plants, is likely to be limited to this mod or a few similar; so that is not information usefully kept at the low level.
II. What functionality does this mod need to work? Is that functionality likely to be specific or general? For the donkey mod, it will need some way for the player to put things in the donkey pack, see what's in there, and take them out again. This might piggyback on the chest interface, so no extra functionality is needed, and if the mod makers want more they can add it themselves.
After this process is complete, what results is a prioritized list of metadata and functionality worth building into the game engine that will support the rapid proliferation of a robust society of mods that do many amazing things regarding minions, towards the creation of a "game of games" lots of people want to play. When implemented, this list of features in the modding system will make the game attractive not only to players but also to modders, who are the sina qua non of a game like this growing to immense heights of popularity.
Very last list of questions, because this is getting in the way of actual work. This one made by going around the house looking at objects to get ideas.
- A scale for weighing things. How much do minions weigh? Can the player carry them? Can they carry the player? Can they carry each other?
- A ball. Do minions play games? What kind of games do they play? Do they make up games? Can the player play games with them? What happens? What happens if the player disrupts their games? Do they require the player to give them things to play games with? Do they need toys? Do toys make them more creative, industrious, happy?
- A bag of dog food. What do minions eat? Will they eat "minion chow" or do they need a more interesting diet? Does the player need to make sure they get enough to eat (and drink) or can they take care of that themselves? What happens if they don't have enough to eat? Will they die? Get weak? Live longer?
- Recipe books. How do minions know how to make things? Do they use recipes? Do they write recipe books? Does the player find their recipe books? Do minions have writing systems? Are they gibberish or can the player decipher them? Does deciphering minion languages lead to any benefits for players? If the player learns a minion language can it help them influence/persuade/control minions?
- A dishwasher. Can minions operate machinery?
- Oven mitts. What about safety? Does the player have to deal with minion safety, or do they handle that themselves? Does the player need to, say, place guard rails around quarries? Does the player have to provide minions with safety equipment to protect them from fire, falling, etc?
- Teapot. Do minions have rituals? What are they like? What if the player gets in the way of rituals? Is that bad? Can the player take part in rituals? Can the player create minion rituals?
- Gong. Can the player call minions using some sort of sound? Can minions call each other? Can they call the player?
- Broom. Do minions clean up after themselves, or do they leave messes everywhere? Do they clean up after the player?
- Clothes. Do minions wear clothes? Does the player have to procure clothes for them? Do they have clothing preferences? Do they have styles? Do they react differently to different things the player might wear? Do they obey more, for example, if the player wears their robes of godhood?
- Armor. Do minions need or use armor, shoes, other protections? Will they accept it? Will they demand it? What will they do with it if given? Will they make their own? Will it protect them? From what?
- Toilet. Do minions need facilities? Does the player have to set them up? Who will clean them?
- Piano. Do minions play music? Do they like music? Will music change their behavior?
- Dog. Do minions have pets? How might that work?
- Chickens. Do minions eat meat? Do they ever refuse to do so? Are there vegan minions? Are there Atkins-diet minions?
- Clock. Do minions watch the clock? Do they need clocks? Do they punch time clocks? How many hours a day will they work?
- Globe. What do minions know about the world? Do they know things the player doesn't know?
I understand what you're doing, in that your goal is to build a list of development milestones that provide functionality that support gameplay concepts that are derived from your list of questions.woodspeople said:
However, in the short term, I'm personally focused on implementing a limited set of behaviors to wit: movement, (incl pathing), combat, communication to the player (text in the log or dialog box), communication from the player (hotkeys, toolbar, or dialog box), being able to place blocks, being able to harvest blocks, being able to pick up items, being able to drop items.
While this is a small subset of the desired end-state behaviors, it is a more realistic development goal for a short-term milestone. I would love miniions that quoted Proust while murdering their best friend for stealing delicious bacon, but that kind of emergent behavior is a significant ways off.
This is to not in any was discourage you, this is more of an apology for me not being more involved in the discussion of miniion behaviors (because after we have the basics in place, I would be very interested assisting in the enumeration).
Seems like a pretty solid design process - I like it. I'm completely unfamiliar with it tho. And you have a gong in your house? No fair 
At the same time - yeah, I'm sort of in the same boat as ironchefpython
I'm thinking about setting up teams after we go Xenforo, this would be a great exercise for a Design team. There's even a similar (smaller) line of questions over in the "The world is flat" thread, page 5
At the same time - yeah, I'm sort of in the same boat as ironchefpython
I'm thinking about setting up teams after we go Xenforo, this would be a great exercise for a Design team. There's even a similar (smaller) line of questions over in the "The world is flat" thread, page 5
If you want to look up the design process I am talking about, I suggest looking up the term "sensemaking" which will lead you to way more than you could ever want to read on the topic (some of which has been written by yours truly). I have actually been paid to do this sort of work by big corporations and governments, and so have lots of other people, so it's not made up or anything.
I understand the short-term vs long-term focus thing. My reasons for trying to "start the ball rolling" on some kind of longer-term design process were: (a) this is what I know how to do, hence the best contribution I can make given that I don't have time to code (writing lists of questions takes very little time compared to writing coherent functionality); (b) it matters to think at least a little bit about the long term even while working on the short term (yes I know it is hard and believe me I have been there, and often); and (c) I'd rather - in my own interests admittedly - snip any buds of minions being implemented only in ways that make the game non-fun for me and my kid. Otherwise, as I said before, this is not the right group for us, which, nothing wrong with that.
To give a quick example: the child and I recently gave the game "Towns" a try. It is full of minions. It is a minion-management game. We wanted to like it, and we liked some parts of it, but when the minions started dying horrible deaths and the dreaded "goblin seige" came closer, with no apparent options to change ANY elements of the game experience, we regrettably dropped it. So close and yet so far. It would be sad if TS went that path, since it has so much promise, or seemed to, in terms of making a variety of gaming experiences a variety of people would love.
So, pretty selfish minion motivations on my part, while still being helpful, hopefully. Happy to "drop it" and keep this idea/process/content in the background until such time as people are more ready for it.
Last question:
I understand the short-term vs long-term focus thing. My reasons for trying to "start the ball rolling" on some kind of longer-term design process were: (a) this is what I know how to do, hence the best contribution I can make given that I don't have time to code (writing lists of questions takes very little time compared to writing coherent functionality); (b) it matters to think at least a little bit about the long term even while working on the short term (yes I know it is hard and believe me I have been there, and often); and (c) I'd rather - in my own interests admittedly - snip any buds of minions being implemented only in ways that make the game non-fun for me and my kid. Otherwise, as I said before, this is not the right group for us, which, nothing wrong with that.
To give a quick example: the child and I recently gave the game "Towns" a try. It is full of minions. It is a minion-management game. We wanted to like it, and we liked some parts of it, but when the minions started dying horrible deaths and the dreaded "goblin seige" came closer, with no apparent options to change ANY elements of the game experience, we regrettably dropped it. So close and yet so far. It would be sad if TS went that path, since it has so much promise, or seemed to, in terms of making a variety of gaming experiences a variety of people would love.
So, pretty selfish minion motivations on my part, while still being helpful, hopefully. Happy to "drop it" and keep this idea/process/content in the background until such time as people are more ready for it.
Last question:
- Is there some difference between "miniion" and "minion" I am missing?
I had kind of been wondering about the extra i myself, I figured it was just a bit of flair from Overdhose
Sensemaking - neat! And yes, that is a lot of reading
I'm fully seeing the promise and want to see more of it. I just want us to find the best possible way to use it. Maybe we should have a "Designer" forum when we get Xenforo up? Or mix that with a general Suggestions forum? If you could lead up something like that on more topics that'd be great, if you're willing and happy to do it anyway
I wish we could implement all of it. Keeping an open design approach for the long-term and a focused effort on topics interesting to an implementer short-term will probably get us to good places.
Sensemaking - neat! And yes, that is a lot of reading
I'm fully seeing the promise and want to see more of it. I just want us to find the best possible way to use it. Maybe we should have a "Designer" forum when we get Xenforo up? Or mix that with a general Suggestions forum? If you could lead up something like that on more topics that'd be great, if you're willing and happy to do it anyway
I wish we could implement all of it. Keeping an open design approach for the long-term and a focused effort on topics interesting to an implementer short-term will probably get us to good places.
I never meant to imply that this team would or could ever build all of that. Apologies if I seemed to imply that. Where I'm coming from is: build it, or build the start of it, well enough, and a vast mod-making army will come and build lots more of it. (Modding minions?)Cervator said:
muhahahahaha
Let's say miniions is the development codename to identify minion related things, a child needs a name, that's all
indeed... the extra i in miniions... well I made a typo in miinions at some point, looked at it, grinned, then though it was to similar to some nintendo pr, and moved the I up.if you build it they will come ....
Let's say miniions is the development codename to identify minion related things, a child needs a name, that's all
Overdhose: sorry for filling up your thread with stuff that got in your way. I actually did it out of respect. I thought if I started another "minions in the future" thread it would seem to diss what you were doing NOW with minions. Probably that would have been better though.
IF it is wanted, I could start a new thread with a "future minion support system design workshop" kind of thing, where we do the thing I blundered badly into trying to do before, but better this time.
My plan would be to
(1) put all my starting questions into something (spreadsheet? table on forum? wiki page with table?),
(2) ask everyone to add more, then
(3) we start "voting" in some way to decide which questions to
(4) answer and consider, towards
(5) making a triaged minion-support-system design document.
I volunteer to put energy into this process, if and only if (a) it is wanted by the group and (b) people plan to contribute (ie at least half of the questions will not come from me). Note: About 10% of "my" questions actually came from the child, with whom all were discussed. Also, I realized later that ironchefpython actually asked some good questions in his joky post, and those should be added to the list. E.g., can minions burn? What happens then? Etc.
Whadya think? No offense taken if this is not the right time or place. BUT let me say that I do think this kind of thing could be VERY good for TS in general, versus the option of no design effort at all. (Last pitch on that.)
My plan would be to
(1) put all my starting questions into something (spreadsheet? table on forum? wiki page with table?),
(2) ask everyone to add more, then
(3) we start "voting" in some way to decide which questions to
(4) answer and consider, towards
(5) making a triaged minion-support-system design document.
I volunteer to put energy into this process, if and only if (a) it is wanted by the group and (b) people plan to contribute (ie at least half of the questions will not come from me). Note: About 10% of "my" questions actually came from the child, with whom all were discussed. Also, I realized later that ironchefpython actually asked some good questions in his joky post, and those should be added to the list. E.g., can minions burn? What happens then? Etc.
Whadya think? No offense taken if this is not the right time or place. BUT let me say that I do think this kind of thing could be VERY good for TS in general, versus the option of no design effort at all. (Last pitch on that.)
One last thing: many projects benefit from a "design wiki". This is not the same as an informational wiki, but it is a place where people discuss all the ways the system could be designed, but in a structured way. For example, instead of "wouldn't it be cool if" ideas going into the general forum discussions, which should be discussions, not listings of ideas, there is a "great ideas" post on the design wiki where things get compiled and sorted and triaged and connected. The thing about a design wiki is that for it to work well (especially in a wide-open-source project) it has to be easy to find and contribute to, and it has to be maintained, in terms of people keeping it clean and organized. So that might be a good idea here?
I'm totally in for that now - we have the forum space finally (let me know in the other thread if I should split Design & Implementation as per the notes there). I also think we should be using the wiki more (in preference over spreadsheets and Google docs as the wiki is better integrated) for storing the actual "output" from discussions like that. I haven't played much with the Xenforo one yet, but I'll try to dig out how to actually give permissions to it tonight (might be another example of what the different topic teams get access to automatically?)
I'd hugely appreciate your leadership on this, since it sounds like it could end up putting something together that'll qualify for this "creature definition" thing I've been raving about for months - and I'll be sure to contribute personally
I'd hugely appreciate your leadership on this, since it sounds like it could end up putting something together that'll qualify for this "creature definition" thing I've been raving about for months - and I'll be sure to contribute personally
Okay - oddly difficult to find a good place to easily manage and review groups, so still tinkering with that. The general "Contributor" group has a few rights on the wiki now - woodspeople, feel free to look at it, you should be able to edit (let me know if not)
More fun with groups tomorrow
More fun with groups tomorrow
Magic thread split power activate! Which is actually magic post move power activate + magic thread merge power activate as each set of moved posts got its own thread - but the dust has settled now and it looks like magic took place!
Note that this new design thread might read kinda funny if you don't know it came over from http://forum.movingblocks.net/threads/miniions.292/ and that I split the posts to the best of my ability - some conversations were broken up in the process
Note that this new design thread might read kinda funny if you don't know it came over from http://forum.movingblocks.net/threads/miniions.292/ and that I split the posts to the best of my ability - some conversations were broken up in the process
I have a certain idea. Players can spawn in a set area of the world. So lets say Server host generates a 1000km^2 map. Players will spawn at certain points on the map and they're given 3-4 minions. You can also ally with other players a sort of "alliance" where these minions will live together but only "operate" under the player they spawned with.
Then if the minions mingle with another players minions, these can be controlled by both the players. You would create a sort of "purpose" for players and minions. Hell it would form a caste system or something amazing.
idk probably off-topic but reading woods ideas made me think of this.
Then if the minions mingle with another players minions, these can be controlled by both the players. You would create a sort of "purpose" for players and minions. Hell it would form a caste system or something amazing.
idk probably off-topic but reading woods ideas made me think of this.