Skilling Items

If you start a new game design, there is always the same old question: will it be class based or skill based. If it is class based, then players usually select their class at the start. They level in the class using class equipment doing class specific quest lines. Finally they end up at the level cap being the best skilled and equipped tank, damage dealer, or healer. But a priest always remains a priest. It won't ever be able to use plate armor. This would make the priest uber. The class system makes balancing easier.

An open skill system on the other hand allows anyone to be anything provided the player invests the time. I can choose an area effect damage dealer career specializing in smart bombs and cruise missiles. A year later the same character can be a maxed out healer by pushing repair drones around while the battle rages. Given the time, you can be anything and a combination of it. This makes balancing more difficult. Still, there are means to overcome the problems.

Skill based systems work well. They offer more freedom to players. Freedom is the right to choose, and the burden. Skill systems often appear complex to newbies, because there are so many options. A class system might be easier, because the career path is clear.

So, that's that.

Recently I read a player complaining, that he had to sell his sword and get a new one in order to progress. He asked why the sword does not grow and get better so, that he could keep it while leveling up. The sword could get more rune sockets and other upgrades over time. It could have a name like a pet and grow with the character.

This is a great idea.

What about omitting the character leveling at all. We could skill and level the items only. Skilling items would combine class and skill systems. No need to choose a class, because you are choosing an item. The item has a type, which works like a character class. So the simplicity of a class system is built in. On the other hand you are free to choose items. You can train items (like pets) and skill items to high levels. You can get very good items of any type, given time and money. This is very much like a skill system where you can specialize in anything you want, only that you have specialized items. Still the character counts. If items are bound to the character (e.g. on pickup), then the player is bound to the character. Only this character can use a specific item. The skilled item is perceived as a part of the character. It defines the character class and at the same time it is exchangable for another item with a different specialization. Transferable items may even be used to transfer skills between characters. Sword sharper might be a profession much like a beast master. In other words: everything is a pet, even your sword. There is no difference between feeding the pet with expensive food and sharpening the sword regularly with an expensive grindstone. Both will perform badly if you do not care.

The item skilling system lets us even adjust the death penalty. Death penalty is a hot topic in game design like the skill/class question. If the death penalty is too low, then people risk to much and never really feel the danger. In recent games death is a minor inconvenience, a waste of a few minutes at most. Some game theories say, that the best games in terms of immersion have permanent death. But being set back by months or years because of a lost fight is a major annoyance and not suitable for the mainstream. The truth probably lies somewhere in between. If the pirates attack, then you should feel you heart beat, because you have much to loose. If you finally loose, then not everything should be lost. The publisher of the game is afraid, that you switch to another game instead of starting over from square one. The truth is probably somewhere in between.

If items (pets, robots, drones) fight and if they loose a fight, then they might be lost. This might be a severe loss, because the item has been skilled and was expensive in terms of time and/or money. Still the loss might not be fatal, because the owner might be able to save the upgrades. Maybe it's not only the sword that was upgraded, but the plugged rune. Maybe the owner can save the rune, but looses the sword. The really important (skilled and named) item might be not the sword itself, but the forge. Maybe the forge has upgrades and produces high-end swords. Swords need expensive resources, but after all they are consumables. The forge with all it's upgrades might be the important item. Maybe even the forge is a consumable. It's expensive, but the real value is in the forge's tools. You could loose swords regularly. If someone attacks the forge, you could loose the forge (ouch, the forge ought to be protected, maybe in a guarded industrial park). But if you can save some tools before the forge blows up, then you can plug them into a new forge to produce the same high-end swords as the old forge.

With items, the death penalty can be adjusted easily. An early design decision is not required. No cementries, where you re-appear, no cover story with clones and such, to make the death penalty reasonable. The true beauty of an item skilling system is that the game designer can defer decisions. This makes game design more flexible and error tolerant without drastic changes.

_happy_designing()

Windows Unicode

Der Windows Kernel ist komplett Unicode, und zwar immer 2 Byte, nämlich "unsigned short". Das hat die Portierung von ASCII zu Unicode und paralleles Programmieren von ASCII und Unicode Programmen erleichtert. Man programmiert alles in C++ Macros mit TCHAR als Datentyp und der Compiler macht entweder ASCII (char) oder Unicode (WCHAR).

Soweit so gut. Aber wenn man plattformübergreifend programmieren will, also das gleiche auch auf Mac/Linux kompiliert, kann man TCHAR nicht verwenden. Auf Unix gibt es nur UTF-8. Viele Open Source Libraries sind auch nur in UTF-8, manche in ASCII, aber fast keine in Windows Unicode.

Ich sage: WCHAR war ein Fehler. Sie hätten den Kernel in UTF-8 machen sollen. WCHAR ist nicht wesentlich schneller als UTF-8, ausser, wenn man in langen Texten einen Buchstaben sucht, aber wann macht man das schon und wenn kann man es auch bei UTF-8 effizient hinbekommen. Es ist auch nicht wirklich richtig einfach zwischen ASCII und Unicode umzuschalten. Die "Einfachheit" von TCHAR erkauft man durch viele C++ Macros, viel Disziplin beim Programmieren und doppeltes Testing.

Ich programmiere jedenfalls auch auf Windows in UTF-8. Die Stringklase macht UTF-8. Wenn man das WinAPI bedient, dann wird in Windows Unicode gewandelt. Erstaunlicherweise hält mich jeder gestandene Windows Programierer für verrückt, manche sogar für unfähig, unerfahren, nixblickend. Alle meinen es echt gut und wollen mir erklären, wie man auf Windows "richtig" programmiert: WCHAR für interne Verarbeitung und UTF-8 für Datenaustausch, ich weiss. Ständig konvertieren soll toll sein? Warum nicht immer UTF-8 und nie konvertieren, dabei auch noch mit anderen Plattformen und Libraries kompatibel sein?

Ein deutliches Indiz dass was faul ist, ist dass der NT Kernel ursprünglich auf genau 2 Byte pro Buchstabe festgelegt war. Das nennt sich dann UCS-2. Später hat man das umdefiniert zu UTF-16, was soviel heisst wie: ein Buchstabe hat 2 oder 4 Byte. Damit entfällt die feste Länge und praktisch der gesamte TCHAR Mechansimus ist ad absurdum geführt. UTF-16 ist für UCS-2 genau das gleiche wir UTF-8 für ASCII. Wenn man von UCS-2 auf UTF-16 wechselt, dann hätte man auch gleich von ASCII auf UTF-8 wechseln können ohne den unglaublich aufwendigen Umweg über WCHAR.

Ich weiss was alle denken, was richtig wäre auf Windows, aber ich glaube trotzdem dass da jemand anders mal einen dicken Denkfehler gemacht hat und alle Windows Programierer machen seit 15 Jahren mit.

_happy_coding()