That works -- as different elements get added each node (either a type or function or combination) could require specific activities related to it - Thanks -- had something in my head but wasn't gelling at all. Probably 5am being the reason. If technically this could be used to create weapon (or other things) models in game for use - it would be an extra-ordinarily powerful tool for consumer created content being utilised.


Edit: Just occured to me before I went to sleep: if the above is feasible then would be interesting it can also bescaled down in such a way as to also effectively decorate weapons armour etc in relief patterns and stylised features. I like this a lot...which means some tech will say "yes we can do it but it will require a really really really hot cup of tea" and you just know those damn tech's don't want "billy tea".

I like it a lot, someone should do it, i'll sit here and wait for it

I will comment the suggestions by hughinn as a mix with the world of goo system as suggested by Stormynature.

Just creating some basic variables like density of a metal and how long the weapon is

It would be possible to customize the sword frame yourself. You could set width and length of the blade, and also how width varies from root to end of the sword. Width could go from broad to narrow as it reaches the tip, or it could maintain most of it's width, and then suddenly lead into a tip at near the end of the sword. Width could also increase. Another is if the blade is curved. You can make it very complex.
The materials could themselves be player crafted/gathered and with unique properties.

Some issues I see with this, is categorizing the different blades. Having a set of different materials (wood, iron, steel, obsidian, etc.) simplifies the categorizing scheme into fixed categories. Additionaly it may be advisable to reduce amount of items with custom parameters. A player will usually have no more than a few swords, but lots of crafting materials. Just picking out the materials you want could be very time consuming (or buying), if every material has custom parameters. I'd imagine that if the sword was unsucessful, then you'd want to salvage the materials (you won't get a full return). Number of items with custom parameters should not be to high.


Also, in the world of goo scenario there will always be minor differences, as you won't place stuff at the exact same location, and also (like in World of goo) the construction can have movements. Actually, I believe the calculations behind this are quite expensive, and something which you probably can't do serverside. The building process may have to be done locally, and once completed the server can test the construction. Locally the construction would be constantly tested so that you yourself can see the attributes realtime. The player would click finish, and a still image of the construction would be taken, which will be used in testing. There are problems with this, as someone could alter the game, so that they sent copies, or slightly altered copies of a very good design.

Using a combination of both your ideas into one would be a nice trick to do imo. Either of you have any ideas how you would do that in making of an Axe for example?

I don't think "striking the hammer at a certain time" goo ball construction fits well together. Anyways, in the world of goo scenario. An axe could for instance consist of a wooden shaft, and an iron blade. The frame would then require wood goo balls in the shaft area, and iron goo balls in the blade area.
I intended that a goo ball will represent a material. If yoiu have 30 iron materials, and you can use up to 20 iron materials in the axe design, then you will have 20 iron goo balls at your disposal. If you use all 20 iron goo balls when making the axe, then you have consumed 20 iron materials. You now only have 10 iron materials remaining. If you try to make a new axe, you will only have 10 iron goo balls at your disposal which is probably to little to make a decent axe.

When making the design, it should be possible to remove goo balls from the construction. If you notice that some goo balls should be placed differently, then you can remove them, but at the risk of loosing the goo balls you remove. This is however far better than loosing many more goo balls (materials) into something which is doomed to be a bad design.

I apologize, I meant to reply sooner but have been ill the past few days.

@Kyan
@AltarofScience

I wish you both well in your game/project - they both sound fun[/quote]
Thank you, and likewise to you and yours should you also have something in the works.

In similar fashion to the previous idea jeffereytitan proposed of an arcane language you could implement a very basic programming like structure that the player unravels to make full use of the robotic possibilities. I must admit my mind is a bit aghast at thinking about the technical aspects in terms of design but I am probably overthinking it without study.[/quote]
To be perfectly honest, I gave it a great deal of thought and simply couldn't come up with a mechanism to make it fun for non-programmers.

To programmers, the draw is obvious. In that case, a special API backed by a scripting language of some kind - say, Lua or Python or Ruby - rammed into a sandbox would suffice. You can get a lot of mileage out of a simple MVC framework, command queue, and state machine.

For everyone else, however, I was at a loss for what they might find interesting. The problem, it seemed to me, was that compared to a system such as the "arcane language" suggested above, robots aren't malleable or changeable in any kind of theoretical way. They're physical entities whose structure doesn't change on its own accord. A robot with treads and a sonar gismo will never start spewing flames or be able to swim, unless the player manually switched out the parts to make that happen. Furthermore, these robots aren't supposed to be capable of higher-order intelligence; they're just function monkeys. Thus, the "language" is simply a subset of verbs that a robot may potentially do, essentially making it a poor man's LOGO.

Now, keep in mind it's still not a bad idea. With some work and perseverance you can probably do some interesting things. However, the core issue in my mind was this: what part of this language's functionality cannot be represented by a UI? And the answer, frankly, is none. Not only that, but a well-constructed UI would likely be much easier to use and much faster to prototype various behaviors with; after all, a move() command - and thus the player - needs to be concerned with distance markers and measurements, but with a UI the player can just click where they want the robot to go instead.

Lastly, you might ask, "Kyan, the inspiration for the UI concept obviously came from Bethesda's AI dev kits" - and you would be right, hah - "so why couldn't you do what they did and sort of combine the two? Like, make a robot's reactions scripted but provide a UI to accelerate mundane activities? Obviously, you'd also refrain from plaguing the world with yet another terrible scripting language and read a book about Q&A instead."

The honest answer is that while my project seeks to make, and keep, crafting relevant it isn't really the focus. Designing a UI to be compatible for scripting by complete beginners and experts alike - things such as help pages and "useful" tooltips and intellisense - simply wouldn't be worth the effort. If I was designing for an MMO or some kind of crafting-specific game, however, I'd give the idea some serious consideration. I think, in that case, the ability to "share" various robot scripts would be mandatory and perhaps be immediately available upon part examination.

Anyway, this thread has some interesting ideas. I wasn't aware people were so passionate about crafting in general.

To be perfectly honest, I gave it a great deal of thought and simply couldn't come up with a mechanism to make it fun for non-programmers.

Yes, I can see that being a problem. I think non-programmers would find it easier to think in terms of qualities than precise instructions. I recall someone wrote a game where you could swap bits of brains to get new behaviours. Perhaps in a game like yours you could say "I want the ferocity of a lion plus the loyalty of a dog" or something like that. Break behaviours along some "common sense" lines and allow mix and match? Also I wouldn't say it's impossible to change the robots after creation. For example, you could order a robot with a claw/gripper to remove it's gun and replace it with a flamethrower from a beaten enemy robot in the field. Probably not what you're aiming at, but just a suggestion.

[quote name='Kyan' timestamp='1334194398' post='4930449']
To be perfectly honest, I gave it a great deal of thought and simply couldn't come up with a mechanism to make it fun for non-programmers.

Yes, I can see that being a problem. I think non-programmers would find it easier to think in terms of qualities than precise instructions. I recall someone wrote a game where you could swap bits of brains to get new behaviours. Perhaps in a game like yours you could say "I want the ferocity of a lion plus the loyalty of a dog" or something like that. Break behaviours along some "common sense" lines and allow mix and match? Also I wouldn't say it's impossible to change the robots after creation. For example, you could order a robot with a claw/gripper to remove it's gun and replace it with a flamethrower from a beaten enemy robot in the field. Probably not what you're aiming at, but just a suggestion.
[/quote]

Actually I think you might be overthinking it - the trick would be too establish a basic language set that each word represents a larger subset of algorithms -- rather than have the algorithms themselves necessarily be heavily designed. Draw it back a level and treat it more like an interface issue -- the real trick is bringing enough complexity to make that level a challenge. For example command: fetch objectname would be the level of interface interaction (this is dumbed down for purposes of clarity) for the player -- and the underlying algorithms for fetch and objectname would not be dealt with by the player. Things like movement - path-tracking would feed out of the existing framework of the larger MMO structure.

The addition or subtraction of parts would simply make those parts of the interface relevant to the part accessible or inaccessible. A further aspect of this is a consideration of remote control capabilites. The UI interface as an altering system based on parts combined etc would definitely be more fun than a text language -- nice!

Actually, I believe the calculations behind this are quite expensive, and something which you probably can't do serverside. The building process may have to be done locally, and once completed the server can test the construction. Locally the construction would be constantly tested so that you yourself can see the attributes realtime. The player would click finish, and a still image of the construction would be taken, which will be used in testing. There are problems with this, as someone could alter the game, so that they sent copies, or slightly altered copies of a very good design.

Going to assume you mean extensive and not expensive but correct me if I am wrong. Localised creation with server implementation (this could also be used as functional deathpoint for some creations i.e. a hidden flaw breaks the axe does sound workable, though with regard tech specifics someone else would have to confirm/deny.

Plagiarism - yes always an issue -- however if the process of manaufacture is unique to the maker i.e. they might mimic the shape but unravelling the formula and steps might be tricksome then someone else who manages to unravel the solution is not necessarily a plagiariser but also a crafter who has learnt that technique. I have no doubt there will be debates on this aspect for years. Unique model copying = plagiarism Vs mastering the technique =/= plagiarism is probably where it will end up.

With the growing trend of free media and the appeal of simplistic none linear editing, I think a bard might be an interesting busking profession in an MMO. Collecting game replay videos, cutting, transitions and showing them off around fires with epic tunes from the game (perhaps displayed in the flames) to groups of heroes interested in watching. Entertaining events and achieving bard missions that invovle capturing video of enemy scripted moments. This element could be used not only with hilarious results but as a training tool for noobs or just showing off amazing moments and it saves players from having to youtube everything, keeping them in the game. Its a complex idea I supose but nothing that would require an MMO engine rewrite. Let me know what you think.

I really do wish I could rate you up 2 points for this particular idea.

Am brainstorming here despite having thought about this for the last two hours or so. But first of all - Awesome idea! I have seen a lot of videos on youtube made from video games - some concerning gameplay, some concerning raid instruction, some presenting dramatic or mucial pieces and there is definitely an audience that exists out there.

I think the idea should not necessarily be limited to using captured video sequences mind you I also believe the introfuction of original musics could also be done here.

One way in which a bard might operate is the ability to cast a number of "spyballs" which can capture video from different perspectives and then an interface setting by which those video elements could be edited into one contiguous whole for a story. Creating a crafting interface that held validity in the lore of an MMO would be interesting but if steampunk can introduce modern technology developed out of clockworks then it is feasible. Moreover it would provide a completely different MMO experience in my view.

I really do have to think about it more but this is an original viewpoint of a bard profession that stands out imo.

Exploring the Lionhead studio'ss Fable games world of "funny" crowd pleasing and crowd appealing actions and animations the profession of a Jester/Dancer could be interesting as well. A library of funny physical comedy or naughty burlesque combined with an "open mic" voice chat areas for Jester profession players to unlock and actually tell jokes or sing for groups of players to respond to (probably limit that to animated emotes) could be fun. The ambiguous exploration of what's funny/entertaining can be explored and shared between players. Missions to cheer up kings or distract lords with well timed dance, appealing humor and music could make a player feel like a pivotal part in a mission where they never need to pick up a weapon if they don't want to.

Exploring a unique GUI here could interesting, maybe have 3D GUI over targeted players or parts of the crowd and timing actions and music to players and parts of the crowd to delight and grow your audience. A player to NPC ratio could exist as well, for each player the entertainer brings in three or four NPCs could approach as well, quickly building huge crowds. I would imagine the code on this one would be substantial as well and the animation would be daunting. The challenge to games like WOW is to keep players interacting with one another in a positive setting, this would be a creative profession with lots of player feedback, not for the meek but for the truly skilled and social (not something often asked of players ;).