Cubish Concepts

Ready to get geeky? Tough, I'm doing it anyway.

Cubish (pronounced kyoo-bish, not cub-bish) is conceived as a language for use in multiplayer Minecraft. The overall purpose of Cubish is to allow for quicker and more effective communication of Minecraft issues and concepts by means of the game's text chat functionality. As such, its focus is mainly its written form. It should also be usable verbally, both for out-of-game use and to make the concepts more easily learned by those tending to audible learning styles. That is, if they can hear it mentally as it's being read, it will be learned much more rapidly.

So here are the primary traits, in descending order of importance:
  1. Quick to type
  2. Easy for English-speakers to learn
  3. Able to be spoken

Please note that this language is designed for English speakers, so it may not be much of an improvement for someone speaking Spanish or Mandarin. Or it might be, I don't know. It may well be useful to Germans or Swedes, but trying to accommodate too many thought processes, especially some which are unlikely to ever encounter my little conlang, will only muddy things.

Obviously, there will be some tradeoffs in the above list of goals, since treating one as an ideal to be striven for will give all sorts of trouble to one or both of the others. After some thought, I decided that to achieve the primary traits I should use the following as guidelines:
1. Quick to type
  • Words must contain as few letters as is reasonable, while preserving the other primary traits.
  • When possible, the grammar should allow for using fewer words to convey enough meaning.
  • Special characters should be avoided, especially those which require key combinations.
  • Common Minecraft concepts that require multiple words in English should be able to be referred to very briefly.
  • Numbers are used exactly as in English.
  • Commonly used words are very short.
2. Easy to learn (for English-speakers)
  • Overall sentence structure should be similar to English.
  • Grammar should be simple as possible: no cases or unnecessary “word agreement” structures.
  • Grammar and spelling must be very regular.
  • Similarities may be built in between Cubish and English words of similar or same meanings.
3. Easy to speak
  • No unpronounceable letter combinations.
  • Avoid vague or hard to pronounce letter combinations when possible.
  • As above, numbers are simply the same as in English usage.

The last group, Easy To Speak, was also the easiest to do. Sonority will be the only likely quirk there, and if it sounds a bit blocky, well, that's sort of how the game itself is. Not a problem.

Quick To Type is the main goal, and balancing it with Easy To Learn will be the main challenge. Usability once learned is by far the higher priority, though. To that end, the guidelines for that primary trait are mostly about avoiding unnecessary keystrokes. Dodging special characters and, where possible, even the shift key, is a simple but important step toward high-speed typing. I plan to not even have a different pronunciation for numbers, which allows them to be very fast to type indeed, not to mention easily said aloud when spoken. On the other hand, common number-like ideas like "quarter stack" will have a single, short (or fairly short) word to convey the concept.

Along the same line of thought, there are some distinctly Minecraftian ideas which take several English words to express and which should be reduced to something far more efficient in Cubish. Almost everything regarding a crafting grid falls into this group. Several building, exploring and fighting concepts - and groups of concepts - also take up a lot more space in English, and more time to type, than would be ideal. Ad-hoc abbreviation hasn't solved the problem, when tried, and is actually a lousy way to communicate, since it tends to cause miscommunication. By contrast, building shortened versions (or modified shortened versions) of English words into Cubish would not only codify the shorter form into something agreed upon, it would also speed up the learning process. This whole reduction-of-keystrokes notion is, as you might have guessed, the real impetus behind the invention of Cubish to begin with.

It turns out that natural languages have a lot of redundancy built into them. Different verb forms for each subjective person, agreement of modifiers with the modified, varying declensions, syntactic markers that are redundant to lexical markers, etc. As I understand it, this happens because (a) spoken language is how it usually forms, and is dependent on the hearer hearing properly, and (b) talk is cheap: if you need to say more to get an idea across, it's usually no big deal. Of course, a great many languages (all the Romantic ones, I think) reduce some of this redundancy by things like dropping the subjective pronoun unless it's needed for clarity or emphasis. But it remains, even there, in the structure of the thing. Cubish will minimize redundancy as much as possible. This will allow for fewer keystrokes and faster learning of the language.

The other main method I'll use to keep things to a minimum of letters needed is making it a highly inflected language, with some agglutinative properties. The short form of what that means is this: a lot of meanings will be combined into a very few sounds, and affixes (prefixes, suffixes and even infixes) will be major players in that. If I can, I'll push it into being a polysynthetic language, which is sort of an extreme version of that. Though very tempted to ramble on this subject for a bit, I'll bore you with my observations and plans about it some other time. For now, just remember: many meanings overlayed into few letters. That's the goal.

For example, Cubish verbs carry the number and person of the subject in their inflection, just as, say, Italian does, and like Italian, the subject's pronoun is usually not used at all.

Another similarity to natural languages is that most commonly used words will be quite short.

The grammar itself will be very regular and predictable, with no irregular verbs or any such nonsense. In that, it will be absolutely unlike any natural language. In general structure, it'll be a lot like English, especially in the crucial subject-verb-object order. A couple of the other items I've listed under Easy To Learn I'm less certain of. For example, when you look at cases as essentially a prepositional phrase with the preposition simply tacked on to the phrase's noun (and modifiers such as adjectives often getting markers to indicate they're with the band), it's tempting to make every preposition part of the noun, which pretty much makes a pile of cases. That part will take some careful consideration. I'm probably going to include several verb moods, and make them prefixes for the verb, and the more I think about it, the more I suspect I'll choose to do the same for prepositions/cases and nouns.

As a couple of final notes for this overview: Punctuation will be handled exactly as in English. Most keyboards are designed to make that reasonably efficient, and there's little point making complication where none need exist. Also, clauses will be designated as they are in English. That is, dependent clauses may come before or after their independent clause, and in either case they are headed by their joining word.

It's funny how much thought goes into making something so that it is simple to use.