So nobody has a problem with me programming an open-source & free StarMade in a JavaScript/C/Java-compatible Emulator with a community-submitted UI and block-textures if I name it "Lichbringer-GameEngine"?
What about the block-config's parameters or a re-textured Dave which I "reverse-engineered"?
Nobody has an issue with you creating a game that tries to achieve the same thing as StarMade. No one has a problem with people creating new games. Where there is an issue, is, if you reverse engineered StarMade, slightly altered a few things and started selling/offering it off as your own. Go ahead and make a StarMade clone if you wish, just don't use our assets to do it. There are games very similar to StarMade out there right now, if I were to start a new game, personally I wouldn't choose to do a StarMade clone, there are already so many games in development that are trying to achieve the same thing or variations of it.
You could do it with any game, if you wanted to create a game like Elder Scrolls but open source, you could. As long as you didn't go using their assets to do so.
If you do use our assets, like any other company, we'd take issue with it.
I'll give you some examples:
Modding StarMade and offering that content for free:
Good.
Creating your own game that tries to achieve the same things as StarMade, but does not use any of our assets:
Good.
Reverse engineering StarMade, using all our hard work and owned materials, passing it off as another game/making public:
Bad.
Advertising your own game as a StarMade 2 or open source StarMade:
Bad.
[doublepost=1491709612,1491707734][/doublepost]
Anyway Criss my point was the development team had ample chance to see this coming and could have easily prevented any of these issues. Did they?NO. So the assumption on users part it is part of the design or a tool you gave us is simply what is to be expected.
The simple answer to all of your questions and points is that sometimes we remove/modify things that are intended, at times we remove/modify things that are unintended. Whether they are intended or not is irrelevant here and plays no part in the decision making process. We might mention that it was unintended and here are the reasons why we don't think it should stay, but we don't remove things simply because we didn't think it would happen.
The two big reasons we remove "features" (intended or not) are performance and balance.
Here's a simple process of how this happens.
Does it cause performance issues? Yes > Can it be fixed easily? No. > Is it integral to StarMade gameplay? > No. > Removed/Modified.
Does it negatively impact other or all aspects of gameplay? Yes > Can it be balanced to work with current and future plans > No. > Removed/Modified.
Intention/expectation takes no part here.
Anyway Criss my point was the development team had ample chance to see this coming and could have easily prevented any of these issues. Did they?NO. So the assumption on users part it is part of the design or a tool you gave us is simply what is to be expected.
There are countless other ways to limit stuff rather than the methods you are using and can be not just more effect but add to the game at the same point. But the team seems to have hit a rut and seems to be relying on simply stop it or power limit it...
Sure, we don't always catch things, that's why we're in open alpha, our players are always going to catch the things we miss. We take their reports, suggestions and feedback seriously. The truth is StarMade is not balanced, we're very experimental, we're willing to take risks with adding and removing systems. We've done a lot of it since the very beginning, and you're going to keep seeing that until beta.
The point is that for the most part the team has a one track mind or mentality of dealing with users doing what they didn't expect. That is to simply try and squash it or suck the life out of it.
Not true at all. When docked reactors were first found (a very, very long time ago), we liked the creativity and the design expansion there. It wasn't intended as far as I remember. Docked reactors stayed for a long time; we didn't address them specifically because they seemed to add onto our system. Unfortunately, they were not performance friendly, there are a few things we could (and will still do) to address some of that, but there was always going to be a performance impact. Secondly, they were an illusion of choice and smart design. At a certain size, they were a necessity, we don't want an inelegant, performance heavy "feature" to stay in the game, so they were removed. Their existence was one of the bigger complaints about the game we receieved.
So, initially we did think docked reactors were a good thing. After seeing them being used and evaluated their impact, it was found that they were not adding as much to the game as they were taking away.
If we go by what you just said those things called exploits aren't actually exploits they are oversights on the development team so why make out like the user is the bad person for simply making use of it. It is like you are trying to pass the blame off on us for your teams failings.
Oversights, exploits, bad features, all the same. You can call it whatever you want, what we're not saying is that the users are "bad" for making use of it. Some server owners might think that (fair enough), we're glad that people are showing what they can do with the game and what the consequences for that are. If you were to utilise performance killing "features" with the knowledge that they will negatively affect everyone's experience (like is true for so many of the things we remove/modify), then yes, that is quite bad.