When it comes to creative stuff, the biggest problem really isn't coding or the creation or any such thing I think, but rather the creative process. Getting a good idea, and I mean a good idea, is often far more difficult than executing it.

We're always very appreciative of new ideas, especially if they're well-sketched in.

But game design and game building, even down to something as simple as adding or changing skills, is a creative process. There is a large subjective element in it, just as there is - say - fashion or writing. Sometimes a gut instinct about whether something works or not cannot easily be quantified or verbalised.

By and large, players have appreciated it when their ideas have been looked at and commented on, even if it has just been a simple 'no'. At least their ideas have been considered. And that pithy candour is infinitely preferable to weasel-words wrapped in faux-flattery or obfuscating vagueness. Sometimes it just comes down to "Estarra doesn't like this" and that is all the reason there is. There's no point wasting everyone's time trying to wrap that up.

Lusternia is a great game. And it is a great game because Estarra has an incredible talent for plot and atmosphere and continuity. Lusternia isn't developed by committee and that ensures a continued integrity which other games lack. The flip side is that our ideas are at the mercy of Estarra's creative tastes, but I think it's a small price to pay.

Design by committee is best avoided in gaming endeavors, no doubt about it. I'll take dictatorship over democracy any day when it comes to creative direction.

Even so, there are certain skill sets that look just fine on paper, aren't broken in a technical sense (everything does what it says on the tin), fit neatly into the theme they're designed for, and yet don't actually live up to the realities of their intended purpose. Tinkering music box enchantments are a perfect example of this, since they do not appeal to their one and only target audience.

I think what we want — and certainly what I want — is administrative acknowledgement that problematic skills and abilities are indeed problematic (or not; the important thing is a decision one way or the other), and at least some vague commitment to address those shortcomings whenever it's feasible to do so.

What we don't want is for a problem to go unacknowledged and unaddressed for years, while in the meantime several completely new projects are started, worked on, finished, implemented, and debugged. I would be rather aggravated if I sat in a dentist's waiting room for three hours, watching several subsequent clients arrive, receive their checkups, and leave, before I've even been called for my appointment.

In short, I believe the administration should decide whether or not a skill set or ability under complaint is problematic. If so, give the problem a place in the queue (a number in the waiting room, a place in line, etc.), and, when it's that problem's turn to be addressed, do so. Almost as importantly, if the administration decides the skill set or ability is not problematic, they should let that be known, too.

Hint, abandoned envoy reports for lacklustre skillsets which went missing a couple years ago.

To be fair, I learned from spending time with Shaddus and Jayden in the Cantors that even people who know what buttons to push in what order don't necessarily know how to improve a skillset reasonably. I know Shric was issued a special report for Starhymn, and while I haven't seen it, the opinions of people whose opinions I trust were generally negative. It was probably appropriate for the admin to ignore it, even though he probably went through a fair amount of trouble putting together his opinions. I know Vusilk was going to do good work with it, but that pesky real world pulled her away, putting it back into questionable hands, where the admin are entitled to, and should, continue to ignore poor ideas.

In regards to the Starhymn report, I have posted it for every Cantor to see to bounce ideas off of, as well as sought out the assistance of others for suggestions I make. Its not just me going forward doing whatever I want... So while my hands may be questionable. I know better than to just go forward all willy nilly.

Actually, I think this might be a pretty good solution. Treat the dreambody like another object instead of a player. Most of the mechanics seem to have already been implemented in other places already (you can hear and see things through ecology bonds for example).

I was kinda curious myself. I'm sure Roark has thought of and tried stuff like that, but I wondered why I dreambody couldn't be like a familiar with your stats, and then if the object is destroyed (i.e. killed) it just sends a slain flag to your character object.

Probably a lot of work to completely re-do dreambody as a separate object, but with how long it's been bug, might be worth it if he ever has the time. I'll leave him a message and ask him about it next time I catch him on envoys.

The issue isn't with the commands, and it's not exactly something you can fix with a separate object. Essentially, having two objects would only serve to complicate things, having to keep them somewhat in sync.

The real problem is having to adapt many of the general functions in the game for things like damage, communications, etc, to account for a person being in two places at once.

But... we can already do something similar with like Phantomspheres. It moves around, and you initiate skills through it. They only have to be in sync in so far as anything else that involves player/object interactions. We already know that the code can be set so that a player can only do certain actions, and we already know that a player can control an object. There's even already an example of object death == player consequences through the bonded familiar death which causes massive health loss.

Obviously I've never dug around the code, but I see examples of each mechanic in play in the game already. The player object essentially becomes a shrub (Can't move, can only input certain commands) and the dreambody is a created object that takes on player hp/mp/ego. I'm sure if it would fix the problem, having an ordering type system would even be fine, i.e. dreambody n, dreambody s, dreambody e. People would just have to create aliases, which is a lot better than a broken skill.

As I said before though, I'm sure Roark (And many others way more intelligent than myself) have thought of this and tried it. I'm just not understanding why it wouldn't work. You're not telling Rapture that there are two copies of the player, you're telling it that there's a player and an object controlled by the player. Just like a familiar, a custom pet, or a phantomshere.

And apparently he's been trying to for a long time and it's a rather difficult task. And I don't see why it couldn't be fixed with having the dreambody exist as a separate object instead of player in two locations if he felt like doing the work for it. The only difficult part of that I can think of would be adjusted attacks to hit the object dreambody vs player dreambody and to keep player health in sync. Pretty much all other mechanics involved have been show elsewhere already.