Hi, thanks for the thoughts! It's never late :)

Let's say you have a slider from 1 to 10. This slider represents power

Well, it's not quite what I had in mind... In your case, players construct a spell from the other side – from expected result.

I thought contrariwise – player can combine some basic things and get resulting spell, according to what he has made.

In case of fireball and your idea, it could be this way:

slider for "collecting" radius (in which area player will affect "fire elements")

slider for resulting radius (in which area those elements will be moved)

slider for speed for such movement

slider for force which will be applied to push resulting fireball

But this approach is not universal – the most complex thing is to mark starting area (where to collect the elements) – it could be not only circle, but any shape; the same for resulting figure – it could be ball, circle, wall, etc.

And second thing is – how to describe the final movement. It could be just push, could be moving to some point, could be just "freeze", could be disperse from some point and so on.

Also, need to be possible to "bind" to a target.

In common, there is not very much options, but sliders/checkbox does not looks good enough for me.

Also, it will not give the feeling of "real" magic/casting a spell.

I thought about gesture options – maybe you have played the old game "Black and White"? There was a gesture-based casting of miracles.

But still looking for other possible options...

So, if anyone interested, I've finally realized how it's possible to make teleportation/portal abilities. And also now I has a basic idea how to make custom "physical" abilities, in addition to "magical".

Here is a common description for magical abilities.

At first, there are several particles types in the game, for example:

• Mind: in addition to in-game meaning, used to bind control and/or AI scripts

• Life (Blood?): responsible for vitality, Health Points and so on

• Mana: required to control other particles, a kind of power for telekinesis; Magic/Mana Points

• Elemental particles: fire, water, air, earth

• Other types (such as Dark/Light, Poison, Electricity, etc...)

Interaction rules

1. Interaction:

   1. All particles could interact with any other particles (with one exception) and with any characters (players, NPCs, mobs).

   2. “Mind” particles could interact only with other “mind” particles (and other particles can’t interact with mind particles)

   3. How exactly each particles interact: this still need to design (fire burns, air blows and so on – but how exactly?).

2. Binding:

   1. Any particles could be “bound” together (a kind of “quantum entanglement” in real physics).

   2. The “quantum” link could be created only between a particles of the same type (fire to fire, blood to blood and so on) with one exception.

   3. “Mind” particles could have a link with any other types of particles.

   4. When 2 particles are connected – anything what happens with one particle happens to the other.

   5. When connecting a bunch of particles at once – they will behave as a big single particle on each side: so, any object that will “enter” such structure will “exit” on the other side of the link – so, it will be a portal.

      1. With the same rules, if a mage will bind a volume of air with different volume of air – all inside this volume will be teleported to the different location

      2. Those particles still have a basic interaction in that case. For example, if someone made a portal with fire particles – will it burn as a basic fireball.

   6. The link could be made in the line of sight OR to a special mark (which need to be placed in advance)

Physical abilities is completely different.

• in physical abilities constructor, player could choose the hit type (such as stab, chop, slash, etc)

• there will be different "targets" types available (such as "humanoid", "beast", etc – depending on what kinds of enemies will be in the game)

  • I mean, “humanoid” is completely different from a “beast” – there are different vulnerable points, different parts of body and so on. So, each type of enemy could require own combat style, own movements. But not to force player to create different abilities for each enemy type, player could set up the single ability against multiple enemies types.

• each ability could be targeted against single or multiple types of enemies (depending on player skills level)

• to have more damage, player can choose not just to hit the target, but for aimed hit – to the specific vulnerable point

Physical abilities mechanic is not yet detailed as magical part, but I hope it will allow to make pretty interesting things. Also need to think about rogue-style abilities – maybe it will require something to add in such system...

I know all this may looks chaotic and messy, since I'm thinking about the mechanic for 2-3 months already, and it looks pretty clear for me.

In case if anyone really interested or have any additions/suggestions – feel free to ask or even participate, I have a kind of game-design-ish document with those stuff and more other things for the game.

Anyway, no one needs my ideas to steal, but anyone could probably help with it.

Hi, I've just read the entire thread. It's very interesting from a design perspective and I like your general vision : crafting a world with basic laws and implementing customization and emergent gameplay by allowing the player to freely use/modify those rules. It's certainly a very "pure" approach to sandbox. However I think you are looking at some things the wrong way.

First you want to make a game that is all about that customizable gameplay, but you are not designing the lore or the other features and mechanics to serve that gameplay. Instead you are trying to make that gameplay fit the model of a traditional rpg. That is a mistake. When I started reading your original post, I thought to myself : "that could be a fun way to craft spells", then I read about warriors and rogues and "physical" classes and skills and I was confused. The original system you described only makes sense as magic, and that is why you ended up designing a second, different system to deal with physical skills, because it was impossible to make it work. Yet you seemed to be attached to having a single unified system and it would indeed be better to only have one system. So, why do you need physical classes ? They make sense in a standard rpg with static skills that are balanced between each classes because their lore can work with the mechanics of the game, but that's not the case here. In fact, why do you have classes at all ? You want to make a completely customizable spell crafting experience that is free from predefined options and then you negate that with classes ? The ONLY purpose of classes is to provide different gameplay options. You already do that by default since the skills are completely customizable, so there is really no need for classes at all. Don't create a system with extreme freedom only to restrict it with arbitrary and pointless classes only there because other games have them. Let the players "create" their own classes using the freedom you gave them. You are not only solving most of your design problems by doing that, you are promoting a dynamic, player-defined class system that would elevate customization and build identity to ridiculous heights. You end up with essentially the same result but better and with a single system that controls everything instead of the frankenstein monster you are currently struggling with. It makes the classes customizable, emergent and potentially way more creative and unique and numerous than anything you could have designed while being more coherent and more easily balanced and more easily designed because they all use the same global system. Have only one unique hard coded class : the mage, and let the players make up necromancers and elementalists and fire benders and tanks and assassins and supports, etc, themselves by using your spell crafting system and their imagination.

You should really focus on designing features and mechanics that serve your gameplay. If they don't and you only want to include them because of traditions, it's bad design and it also makes your game that much less original and unique. I can play warrior and rogue and necromancer in hundreds of other rpgs, what's the point of allowing such a deep level of customization if it's to end up emulating games that don't have that freedom ? Your core idea is a cube and you are trying to fit it in a triangle hole, it's not going to fit and that is why you are having such a hard time designing the mechanics. Design around your core idea : make a square hole for your cube. Not only is forcing your cube through the triangle hole nearly impossible, even if you manage it you are going to deform it in the process and end up with something looking more like a pyramid than a cube. It would be a shame considering that we already have plenty of pyramids to play with and not many cubes. I hope I didn't go too far with my metaphor and you understand what I mean.

The second thing you are doing wrong in my opinion is designing the spell crafting system from the "end" perspective and I really don't understand why you are doing that since you yourself criticized ideas from other people in this thread for that very reason. You should design a solid core mechanic first, your "particle" system (and really you should call them "objects"), with simple and basic rules and interactions. Then once that is done and you have worked out all the design kinks, you can expand on that core system and make it more complex, with more content and more customization options. You don't want to have a fireball template nor design for it, you want fireballs to naturally emerge from your spell crafting system, yet you go and try to twist your original idea to allow for portals, teleportation, physical attacks and many more very specific and static things that just can't work in the system you designed. It's the same problem I described above : you are not designing your system to support your core idea, you are designing it to fit a regular rpg model and regular rpg skills. What is the point of that level of customization if it's designed to only allow you to craft slight variations of the spells you can find in any other rpg ? Players will spend a lot of time mastering the spell crafting only to achieve the same result other rpgs give them without requiring that amount of work. In fact they will even achieve a lesser result because players are not game designers and they won't spend hundreds of hours worrying about balance and optimization and player experience. If you do that, all you will achieve is a generic looking rpg with an insanely complex crafting system that basically only allows you to make your own fireball that doesn't feel as good as the carefully crafted static fireball other rpgs give you for free. If you try to design the system as something coherent, incrementally adding new object types and new laws governing those objects and new interactions between the objects and the player and new controls to affect all of those when crafting spells, then you will end up with truly emergent skills and infinite possibilities. Don't design your system to include a specific skill, design to increase the freedom of the player and the possibilities. If you really want a specific type of skills to be craftable, then use it as an inspiration to guide your next increment of the system, but don't reshape your entire system just to accommodate it. And certainly don't make a completely different system in addition to the main one just to include something people won't care about anyway. Do you really think anyone is interested in basic sword attacks when they could be reshaping the world through sheer will ?

The third problem is complexity. It's a problem with three concrete aspects : designing the game, running the game and playing the game. To allow more freedom and a higher level of customization, you need more complexity, but when you increase complexity, you also increase how difficult it is to make the game, run the game and play the game. You yourself did not fail to identify that problem and it was one of your first questions : how to make the spell crafting mechanic easy to use, casual. You can't avoid complexity, you can reduce it and optimize your system as much as possible but the only ways to truly bring down complexity are to reduce the customization and/or reduce the complexity of the medium. And you need to bring down complexity because it's the only way to make the spell crafting easy and not cumbersome or confusing. Even with an excellent graphic interface using the industry's standards for customization that players are already familiar with like sliders (and you need sliders since you don't want predefined options), the spell crafting you describe will be too complex. In fact even a tiny fraction of what you describe, just enough to make something like a fireball is already too complex. The player would need to worry about the 3D position and size and shape of the targeting area (where your fire object is), about the object (fire) and its current parameters, about the trajectories and the actions needed to take that fire, shape it into a fireball and throw it at something, about the energy/mana requirements of all those actions and about the timetable of all those actions. If you start adding the other features you described to the mix, then the pvp elements possibly including countermeasures, I think that "too complex" become an understatement. You, as the designer, wouldn't be able to make sense of such a system, the player will simply not even try. That means you need to reduce the complexity of the system drastically, and that is why my first advice is even more relevant : a single coherent system is already more than enough complexity, having multiple non coherent systems working together is not conceivable. If you don't want to reduce the customization options, then you will need to reduce the complexity of the medium. That could mean making it a 2D game rather than a 3D game, that could mean making it turn based rather than real time, that could mean using grids, tiles or voxels rather than free hand movement.

Finally I will just give you my opinion on how I think it should work. I think it would be better to separate objects (particles) and attributes (the variables of those objects which define their current state). For example you have the player that is one object (or a group of objects) and life that is an attribute of that object rather than an object itself. So the player is an object and that object has 100hp. Interactions with other objects may change that variable, effectively changing the state of the object. For example the player takes damage and changes his state from "alive" to "dead" when his life reaches 0hp. Objects can have multiple states which change how that object interacts with other objects. Objects follow common laws, like gravity. When crafting spells, the player can "program" a succession of actions affecting objects in the game. The only action available is changing the values of an object's attributes (possibly changing its state if that object has multiple states). The position of an object in the world is an attribute of that object. That way you can make any spell you want using only different combinations and variations of that one mechanic. Teleportation is nothing more than changing an object's position from a position A to a position B, which is way simpler than the system you designed for teleportation which I don't actually understand. A fireball is moving a fire object from its position in the world to the hand of the player, then moving it along a straight line (or curved if fire objects are affected by gravity). You could treat objects like voxels, adding some complexity but allowing objects of the same type to fuse together to form a single object or on the contrary allowing an object to be split into smaller ones. That would add a second mechanic (changing attributes and fusing/splitting objects) but allow for basically every spell I can think of. Then it's only a matter of the medium and of how much customization you want to allow for each of those mechanics.

That's all I think and I'm running out of ink anyway.

It's very interesting from a design perspective and I like your general vision

Hi and thanks a lot for such detailed review!

First you want to make a game that is all about that customizable gameplay, but you are not designing the lore or the other features and mechanics to serve that gameplay. Instead you are trying to make that gameplay fit the model of a traditional rpg

Actually, I'm doing it for purpose – my goal is to make more-less "classic" RPG experience with new mechanics. There is no real reason for this, just I like RPG games and especially like classic-style RPGs, but almost all modern MMOs are going into different direction – very few customizations, limited player-vs-player interactions and so on.

But this abilities (while working on it, I've renamed original "skills" term to "abilities", while "skills" have a different meaning in my design – not strictly related to current mechanic), actually, not bound to any gameplay style. In terms of design, it could be used basically in any type of games, not only RPG.

However, as I said, my goal is to make more-less classical MMORPG, so that's why I'm talking not only about "mages", but also about other roles.

why do you have classes at all ?

I don't :) Player will be able to make/use any abilities (restricted by other game rules, of course, not to allow newbie players to create very powerful things).

When I'm talking about "warriors", "rogues", "archers" – it's not about classes, rather about different roles.

If you have played in Eve Online, you may know there are no classes or synthetic restrictions, any player could learn all available skills... But it will take about 18 years of real time, AFAIK. So, players should choose some way to progress to be somehow efficient in the game.

And in this terms, I don't like restriction to be only a mage for all players (even if there will be lot of ways to make each mage different). That's why I'm going to implement "classic" warrior/melee, archer/range and so on.

Rogues are a bit different from both "mages" and "physics", since in my opinion it's not about fights, rather about in-game lifestyle and sneaky gameplay; Actually, I didn't yet worked on this part, just keeping it in mind.

And, again, my goal is not to make pure sandbox in term of overall gameplay (sorry, if I have disappointed you).

About two different mechanics for abilities – you're right, at first I've tried to implement "classical" warrior role via the same "particles" system, but then realized here (thanks to Shaarigan) that "physical" abilities should work different way.

The best case would be to use full-body control, to make possible control every character's movement as in real life... but it's not yet invented :-)

So, I came up with such idea for a different abilities constructor, which will allow to "program" some movements and hits and then just use it with keyboard or/and mouse (or gamepad).

If you have an idea, how to implement "classic" physical abilities with the same "particles" system – I'll be happy to look for it.

The second thing you are doing wrong in my opinion is designing the spell crafting system from the "end" perspective

I see what you mean. And you're partially right – as I said, my goal is to implement "classic" RPG, so that's why I'm talking about "fireballs" and "portals".

You're right, I'm designing the system and using such things as a test-cases, to check if the system fits my goals or not.

But you're not right when talking that it allows to make "only slight variations" of classic abilities. In such case, I could choose a way which already used in some projects – e.g., where player has several "blocks" and could combine it in few ways and add few additional properties (from other blocks), as in LEGO.

Instead, my way will allows to create literally anything and those "fireballs" are just a basic example I've used to explain my system with comparison to pre-defined abilities.

and really you should call them "objects"

I'm not really sure what do you mean in this part. For now, "particles" (or "energies") are best term which exactly describes the things, while "object" is too broad for this, as I see.

Idea about attributes and sliders, as I see it from your text, not really fit my mechanic since it will be much more complex and a kind of programming-style for players, not casual at all. At least, will need to implement each of those attributes instead of making common rules for all (as in my case).

The third problem is complexity

This is the most complex problem, you're right. I'm thinking about how to implement such pretty complex system and at the same time not to ask player learn coding or learn complex UI things.

If talk about specific solutions, for now, I'm thinking about gestures-based constructor, where player could draw a form, move it and so on. Basically, similar to a simple graphic editor. But I don't really like this way, just can't design anything else which will be simple enough and still fit the system.

Well, about implementation – that's exactly what I'm stuck with, for now. Going to build several prototypes step-by-step as a proof-of-concept (I have some specific plans for it), but not yet sure how exactly implement it.

Sorry if I've missed anything from your post, just there are lot of different topics in it... :)

And thanks again for your thoughts, it's always good to discuss ideas.

If you want to make a traditional fantasy rpg, I don't think your object/particle system is necessary. Just look at the way you construct physical abilities, you ended up doing the "assembling pre-defined blocks" thing. The only way to have a system that can fully simulate all the different types of skills and gameplay that traditional rpgs have is to completely simulate the entire world, which is impossible to design and implement. If you want to have warriors and mage and archers, it would be a lot easier to simply implement those classes and allow for great customization using lots of predefined options. Right now you are doing that for physical abilities and then you are having a completely different approach to magic that defines how the entire world of your game is implemented.

• If you want high customization of traditional rpg skills, just design a very large amount of predefined customization options that allows players to craft most spells easily and that doesn't require an extremely complex implementation of the world.
• If you want the type of completely free and sandboxy skill crafting experience that you originally described, design the system as I depicted it in my first reply and let go of traditional archetypes.

I don't think you can have both. Even if you ignore the complexity and implementation and balance problems, it would end up being a completely free crafting experiences for mages only, that defines your entire world and how it works, with some add-ons on top to craft slight variations of all the traditional rpg skills not fitting that main model. I don't think it would be fun : a mage would be able to use the entire world to do basically everything while physical professions would only be able to chose which body part they wanna hit or how many arrows they wanna fire at once. The mage skill crafting would be "sandbox styled" while the other professions would not be. That is why you really should in my opinion go one way or the other and then commit to it. Game design is about compromise.

I talked about "objects" to make a link to programming because at some point you are gonna need to code all of this. "Particles" might be a confusing term to use because it usually refers to something completely different in video games. And "energy" doesn't really mean anything from a code perspective. I don't know if you know programming but to implement your system, you would use "objects" and those objects would have "attributes". It wouldn't be more complex or "programming-style" for the player because the player wouldn't see those attributes, he would only have access to predefined tools allowing him/her to modify those attributes in a certain way ("methods" to use the correct term once again). And I really don't see any way to implement your system differently.

For example the "position" attribute is one that all the objects in your game need to have otherwise the game wouldn't be able to know where to place those objects. And you wouldn't be able to move objects because you wouldn't be able to change their position in the game. Using different states for objects is also a much simpler way in my opinion to implement some of the mechanics you want. Life and death for example are easy to do using that system. Objects have an "hp" attribute and you can modify it. Having a separate object for something like "life", that really should be an attribute, actually makes your system incredibly more complex both from a code perspective and from the player's perspective.

Instead of having an enemy with a certain number of hp, you have an enemy object and a hp object somehow linked to that enemy object. That can't work, you need an attribute defining health points for objects which need health. Then you can add a type of object that can modify those health points, like a health potion for example. What you are describing sounds like objects that are alive carry around their lives as a physical object that is linked to them but not part of them. To damage an object in such system you would need to have an action that involves reducing health points affect an object which doesn't have health points and instead it deletes some of its life objects which are separate entities. It really is not viable. I guess you could treat health points as an item and use "health points objects" as attributes of your player/npc objects, it is perfectly doable code-wise, but that really is a convoluted and unnecessary way to implement something like that. If something can be thought of as a property of an object, then that needs to be an attribute of that object. Position is a perfect example, weight is another, if you want gravity, you need to define a weight property for your objects. You can't have rules without having objects to apply those rules to and attributes of those objects which define their existence in the game.

Regarding sliders, I don't understand why you say that they don't fit your mechanic either, because there are only two possible options to define a parameter : predefined settings or sliders. You can use a different interface for sliders, if that is what you mean, but the idea is the same : it's about giving the player the option to customize a parameter to a greater precision. Instead of having "large", "medium", and "small" fireball size options, you use a slider from 1 to 100 that allows for 100 different sizes of fireball.

You should really consider tech design and keep it in mind when designing a game because if you don't you will end up designing something that is impossible to implement. If you want your game to be more than an idea on paper, you need to understand how games work and what is possible to do. What you described so far is simply impossible, it's not even a matter of complexity or computing power, it's simply a matter of game logic and architecture. That is just not how it works. You need to start considering what medium you want your game to be in and what solutions exist for that particular medium. You can make your own game engine which I wouldn't recommend or use one that already exists. If you want your game to be a 3D rpg, look at game engines that are designed to make such games and look at tutorials to understand how they work even if it's just on a very basic level. Then you should have a better idea of how games work and how to design the mechanics you want for a video game. Right now it feels like you are trying to design a house without knowing anything about architecture so you end up designing a house with no load-bearing walls, no doors and the roof at the bottom. You even have entire rooms floating in the air. You can draw a house like that on paper, but it's not really a design plan, or a proof of concept : it's just a drawing.

I don't think it would be fun

Well there are no restrictions by classes – anyone could use anything. So, "warriors" could learn magic and make mixed abilities, if they want to.

But I think you're wrong about this case: probably, you (and me as well) prefer to play mages in such games. But lot of players do like more simple and straightforward gameplay.

I talked about "objects" to make a link to programming because at some point you are gonna need to code all of this

Of course, but I don't want to make the design to be "programmish" for players and for anyone. Implementation is different topic, here I'm talking about the design itself, not to make any confusions and not to add additional complexity to discussion...

And If I will describe the desing in programming terms – it will be "programmish" for players.

I understood what do you mean about objects and attributes, but it's completely different from my mechanic and will not allow to make fully-custom abilities (since will be required to implement all such attributes one-by-one instead of making common rules). In fact, probably, it will allow, but need to design it from scratch, as I said – it will be completely different design.

are only two possible options to define a parameter

I don't want to force players to "define a parameters". Again, it should not be a coding. I don't have yet any prototypes for the UI, but it should be as simple as possible. And for now the "graphic editor" view fits better than any other options I've thinking about.

Instead of having "large", "medium", and "small" fireball size options

Sorry, but it's not about my mechanics at all. It's about "LEGO-style" constructors.

In my case, player can't set size of a fireball, instead he can choose how much particles he will use for the fireball. Not with slider, rather with selecting an area/volume around him. And it could be not just a circle/sphere, but in best case it should be custom-shaped area/volume. I can't describe it more strictly because not yet worked on the UI closely.

About implementation – well, I almost don't have a gamedev experience, but I have 8 years other programming exp, so basically I'm understand what and how could be implemented. That's why I'm designing exact mechanics and logic instead of some literary text. Also there are prototyping part ahead, so, maybe, design will evolve one way or another to fit technical restrictions.

Again, implementation – is completely different topic, the design is not yet ready for this.

Anyway, thanks for the thought

I'm not saying people can't enjoy more simple and straightforward gameplay, I'm saying that people looking for this won't look for your game. The level of customization you want is neither simple nor straightforward and people who want that will look at other games. The people your game will attract will like it because of the extensive and sandboxy customization and those people will probably not care about limited mechanics if they have other options available. There is no reason why a player who has access to both limited physical skills and almost unlimited magical skills will want to use the former. You are basically giving the players a super cool super powerful gun and a shitty pistol and thinking that they will care about the pistol. That won't happen, especially in RPGs where people enjoy finding the best builds and especially in a multiplayer environment where competition is a huge motivation. If the pistol was just a less advanced version of the super cool super powerful gun, you could put it in, it would most likely be useless, but it wouldn't be costly. Unfortunately that is not the case and making the pistol here is making your design extremely complex because it uses a completely different system.

Regarding vocabulary, you are not making the design and the design documents for players, you are making them for yourself and for other game designers or programmers, so it only makes sense to use a vocabulary that makes sense to game designers and programmers, especially if you want to ask for their opinion and you want them to understand your design. Then you can coat that in lore-friendly, player-friendly vocabulary once it's done. Just make the distinction clear, it's not making things more complicated, on the contrary it makes your design a lot clearer and a lot easier to understand. Don't call objects "particles" in your design explanation, talk about objects and then add that in the game you will refer to those as "particles" or "elements".

I still don't think you understand the object/attribute thing. You keep talking about "having to do those one-by-one as opposed to making common rules", that makes no sense to me. All the object types in your game you will need to do one-by-one, if you make a fire object you will have to specify what are its attributes, what are the rules it follows, what makes that object different from a water object. You can make common rules like gravity, but those are just parameters shared by all your objects. In the end you still need to specify that a water object is heavier than an air object otherwise gravity doesn't quite make sense. You still need to give each object a specific model in the game and specific properties otherwise all your objects are identical. It's not something that is different from your mechanic, it's not something that is like your mechanic, it's just how games work. No matter the mechanic you are making you are going to need to do it that way and so your design should reflect that technical limitation. Unless you are planning on inventing a new coding method. If you don't believe me, try to explain how you can make a certain object in your game without using that system and you will see that it's impossible.

When I'm talking about defining a parameter I don't mean that the player should type in code. It can be a graphic interface, but it's still about defining parameters. You are just using a different interface. I feel like you think design should be completely separate from implementation and that merely mentioning anything related to coding is wrong. If the player is not defining parameters, there is no customization possible by definition. Obviously you want to make it more appealing than just a console and graphic UI are pretty much the standard, but that is irrelevant. Just say that you are allowing the player to define parameters through a graph editor like interface. Whether I'm using my hands or a fork to eat, I'm still eating. I basically talked about "eating" and you said "No, I don't want players to eat, I want them to eat with a fork".

I understand that "small", "medium" or "large" is not what you want which is why I said that you needed sliders or an equivalent, since sliders are the kind of tools allowing people to chose from a greater range of customization options. And I also understand that Lego-style constructors is not what you want which is why I'm asking you again : do you really want physical skills ? Your physical constructor is very much a lego-style one. If you really don't want that in your game, why are you pushing to have it in your game even though it's unnecessary ? Once again you should really focus on the magic sandbox spell crafting system and not try to fit everything in that system. "You can't set the size of the fireball but you can choose how much particles to use", you realize that is the exact same thing ? The only difference is the interface : instead of typing in 5 or setting a slider to 5, you are selecting 5 particles. Also how does that work ? You are not crafting the skills in real time so how do you handle the different situations ? Are you crafting a skill that can use a variable amount of particles and it's just about selecting them in real time in the environment ? Or are you crafting a skill that can only be used if there is the right amount of particles available at that moment ? In both cases you would need to set the parameter "number of particles" or "size and shape of the selecting tool". That is what sliders are for (or any equivalent tool that allows you to easily select a value from a large range).

There is no point at which tech design is irrelevant. The sooner you consider tech design, the easier it will be to design and implement all the features you want. It's the house metaphor again : if you design your house without loadbearing walls, it can't work, so you will need to change your design at some point to include loadbearing walls. If you decide to ignore that fact and design freely without having those considerations, you will end up scrapping most of the work you did and having wasted your time and starting again with tech design in mind this time.

a super cool super powerful gun and a shitty pistol

It's not true. Both systems will be more-less same powerful and efficient in the game. People like to play different roles. You can't say people won't play a "tank" class in a classic RPG just because tanks don't have powerful skills and can't make as much damage as mages/daggers. Or the same about support classes – they can't fight efficient by themselves, but people still play them. All players are different and will play different roles.

In addition, this mechanic is, definitely, one of the most unique part of my overall game design, but the game not only about this. I have lot of other interesting stuff, and this mechanic is not the goal itself, it's more like a tool for implementing interesting gameplay for different players.

I can only refer to Eve Online again, where you can fly a small frigate or enormous Titan, but it does not mean that playing "frigate" is less interesting. Just any type of ship has own purpose. And inside each type players could make a very different yet efficient equipment builds.

finding the best builds

This is exactly the reason why I've started to think about my mechanic! In terms of this system, my goal is to make almost every "build" efficient enough, just in different activities. And even for the same roles, I hope there will not be a single "top" build.

Regarding vocabulary...

That's why I've choose "particles" term – it's much more fit to the things I'm trying to explain. Not from a programmers point of view, but just from more-less pure logic. "Object" is a very wide term and explain nothing.

I still don't think you understand the object/attribute thing. You keep talking about "having to do those one-by-one as opposed to making common rules"

Well I can say that I'll post here an update if I made a working prototype for this abilities system. While it's pretty clear in my mind, I can't explain it good enough (I was never good in any explanations even in my native language).

I feel like you think design should be completely separate from implementation

Exactly. On this step - I'm working on the design itself, not on any implementation. While I'm thinking about "am I understand at least in common how to code it?", I'm not going to translate the design in some kind of pseudo-code, it does not help at all, just adds more unnecessary complexity here.

Whether I'm using my hands or a fork to eat, I'm still eating

Maybe I'm wrong or can't understand you correctly, but in my opinion your suggested objects/attributes mechanic is completely different from my. Not a generalized in any kind (as "eating" vs "eating with fork"), but completely different (as "eating" vs "breathing").

to chose from a greater range

Again, I don't want to make any range, no matter how wide it is.

Your physical constructor is very much a lego-style one

Because, as I see, it's good enough and I don't see a better solutions since we don't have a sci-fi virtual reality with full body control. And, as I already said, physical part is necessary for my game.

you realize that is the exact same thing

Nope, the different is that in your case player could set up exact ending attribute, while in my case he can only use some basic rules and, without experience, don't know what he get in the end. Of course, real player will know that "if I choose more particles, my fireball will be more powerful", but the point is at the heart of the approach. You have told me that I'm working on the design "from the end", but in this case your suggestion is to making abilities "from the end", based on desired effects.

You are not crafting the skills in real time

That's not quite true. Probably, player will be able to "cast" spells in real time. For example, if player doesn't have required ability and need to do something non-standard "right now" in a fight.

Regarding your particles, I'm just saying that they are objects with attributes, nothing more. I think I understand what you want to do, even though I don't quite understand how you want to do it and I don't agree on some decisions (I still think your would end up making a better game if you focused on your original system and designed a game around it).

Anyway I'm curious to see a prototype of this if you end up making one.

This kind of system has countless practical flaws. I will just enumerate some:

1. It's hard to design in full.

2. It's hard to code in full.

3. It's hard to grasp by players.

4. Skills will be hard to animate and present as icons.

5. It's very hard to balance individual skills, because everything depends on everything.

6. It's hard to add unique skills with unique effects which can't be derived from basic rules.

I don't see a single plus of such system. It only creates new problems without solving any old ones.