I don't think this tag provides any useful information, and we should remove it.
indie is a meta-tag, and describes more the context of the problem rather than the problem itself, which doesn't offer enough improved search-ability to warrant the consumption of an entire tag slot on a question.
Further, the overwhelming majority of questions asked on this ...
We certainly don't need a tag for hats.
Although cosmetics-customization could do the trick, seeing the scope of the answers, it's not only used for that as it could be used as trophies and/or visual achievement as well.
I propose that we rename game-specific tags to have a "-modding" suffix, so we'd have skyrim-modding and the like. We should rename mods to modding for uniformity, but otherwise leave it alone because it serves a useful purpose.
When we find questions that are double-tagged, we should remove the less-relevant tag.
Tags are for searching and filtering.
While there is some validity in the assertion that many questions are fundamentally algorithmic in nature and thus language-agnostic, in practice many users will want help tweaking a particular implementation in their preferred language.
Similarly, many answerers will prefer to demonstrate algorithms through example ...
Even though navigation-mesh is more wordy and describe more exactly what it is, users will not be confused by the term navmesh as it's very commonly used.
I suggest we make navigation-mesh a synonym of navmesh because navmesh is shorter to write, has no hyphen, and is sooo much cooler :P
The existing tag voxels seems to be mostly used this way, and it seems like a reasonable tag. The question is then whether we wish to avoid conflating “chunky voxels” like Minecraft with small detail-less ones like Voxatron.
I think we should get rid of 2d-physics.
I don't like the idea of "combined tags" like this, in general, as it just sets precedents for combining two concepts that are really orthogonal as far as the purpose of tags goes. Should we then have opengl-physics for doing physics using GPGPU techniques via OpenGL? Should we have d3d-xinput for a game that uses ...
No, we don't need the free tag.
In my opinion, this is a meta tag which does not inform at all about the topic of the question.
You can't be an expert in free.
The vast majority of the 24 questions with this tag are closed. This is associated to the fact that questions about 'free' stuff are most of the time off-topic/too broad for this site. (E.g. ...
This tag should not exist because it is primarily identifying a poor kind of question that is undesirable. If it is undesirable, the proper course of action would be to vote-to-close the question under an appropriate reason. Without the ability to vote to close, one can flag them for attention, or just not visit the question altogether.
Fact is, though, ...
I'd follow this rule:
If the question contains C# code, tag it C#
If the question lacks code, but asks about scripting a feature in (a recent or unspecified version of) Unity, tag it C#
If the question asks about solving non-scripting problems in Unity (eg scene setup, asset management), do not tag it C#
In the first two points, even if the C# language ...
location and position are stupid and should be removed.
I'm not so sure about transform though. I think there is a legitimate expectation that one could be an export on transformation, as that's basically linear algebra and it's a pretty reasonable "topic" for questions (for example, my favorite question from my computer graphics class: how do you transform ...
I suggest we make forces a tag synonym of physics because...
... the concept of forces being a subset of physics
... half of the questions tagged with forces are also tagged with physics
... someone is rarely expert in forces, they're more often expert in physics.
This makes it more of a meta tag, in my humble opinion.
class has about 17 uses as of this writing, but I agree it's not particularly useful. In all 17 cases it seems to either add no value, or seems like a more conceptually-specific tag could replace it.
I'd be in favor of nuking it.
We should call it software-engineering; fundamentally the scope of the tag is similar to that of the Software Engineering SE: methods and practices of building software (games, specifically), including the theoretical.
I am of the opinion that these tags should be blacklisted.
You would not be able to use the tags by themselves to adequately tag a question, unless the question was only specific to general context. Such context would probably be to broad for our scope.
To more accurately use the tags, you would have to also use the more specific tag to provide context, in ...
I don't think this is necessary.
The original Xbox is called the Xbox. That is what it is.
People visiting this site, should at least have enough domain-specific knowledge to understand that the two systems are different.
I don't really think any of these are particularly helpful as-is. I'd propose removing all of them.
The few cases where I can think, offhand, that these tags might even potentially apply (rasterization, collision detection and response, and so on) have better, more appropriate tags available already... or we should make appropriate tags (for example, circle-...
I think update is not clear enough and should be deleted.
However, while doing so, the questions tagged with update regarding the topic game update loop pattern could be tagged with game-loop instead, while those with the topic deploy game software updates to players could be retagged with deployment. I feel the other two topics you've covered are using ...
One thing I've been thinking we should do is merge it into a more specific tag to provide clearer guidance. Especially if we adopt Law SE's policy on specific-advice legal questions, inspection reveals that the majority of our law-related stuff concerns intellectual property. Copyright and trademark, most often.
We could remap legal to intellectual-property ...
My stance would be "no," the artifacts tag isn't useful in either it's current form or any more-generalized form. In both cases the tag is describing what is being observed in the question, not the problem attempting to be solved in the question.
Even when localized specifically to rendering artifacts, it's very possible for two artifacts to be caused by ...
I think we should merge and create synonyms to point c++11 to c++, and similarly for the other standards versions (c++14 and c++17).
I am generally against versioned tags, except in the rare scenarios where it makes a huge difference (differences between D3D 9 and future versions, differences between D3D 12 and earlier versions, for example).
I don't see any reason to do anything about the blender tag; Blender questions are on-topic here, just like Max or Maya questions.
Just because the Blender StackExchange site exists does not mean we automatically consider questions involving Blender off-topic.
It's possible that a user might be better served by having asked their Blender-related question ...
I think microtransactions and IAP are two different concepts:
microtransactions deals with the business model
iap deals with an implementation of the business model.
You can very well create a game that has no in-app-purchase but has microtransactions (what if you need to go on the website of the MMO to do the transaction), and you can have in-app ...
Yes, experience should be blacklisted. The name is not specific enough about how it should be used, and even if it were to be used for "experience points", it would be too specific and could be covered by the other tags you mentioned, or by game-design if appropriate.
I'm not so sure we should get rid of it. Inventory related code and design problems are unique to games, and this tag provides scope and discoverability to that unique problem domain.
I do think it's possible to have expertise in implementing these kinds of systems and designs, so I don't think we should get rid of it.
This is probably opposite the stance ...
I think we should merge these five tags down to just two:
entity-component-system for questions about ECS architecture & approaches.
merge entity-system into this.
component-based for questions about components without a strict separation from both entities & systems (eg. Unity's original GameObject & Component approach, or applications of the ...