Sunday, 6 September 2015

New Message

Yesterday I realized what to do with the Message class and messages. Previously I had passed AI id for messages, but replaced that with game object handle. That way the game object always triggers the message and selects the proper message pool with different versions of messages. Also, all visibility and other checks are in the Message class, so there is no need to check for example if the player is blind in other routines. Later messages can become more detailed depending on how far the action happens etc. but it requires more message pools.

For message pools I wrote a new class, not surprisingly named Message_Pool. It's another good example why you need to handle raw style data in a dedicated class rather than directly, because with class you can input as many similar sources as possible and then select them without using ifs or switch-case structures.

There were problems of course. I already knew I had to solve the passing of nouns and verbs to Message, because it was done for each actor first, before displaying the message. It works, but makes the game of course slower. To fix that I'm replacing direct calls with new functions that take the message id and the noun or whatever as parameters, then first check if the message itself exists and other visibility issues before copying and displaying the message. There is certainly some work to do before everything is fixed, but I had a good start in that.

The main message pool needs a clean up and the message data arranged better. It doesn't matter in what order the messages are so that's why "magic" id numbers for messages work here, they are not replaced etc.

It's not yet perfect and I'm anticipating some problems later. One of them is how individual npc names are displayed. The message data can have something like "The # hits you." but if the npc is someone you know then "The" has to be removed. It may be something simple like using another pool for "known" npcs with message data changed to "# hits you." The pool can be selected in the Message class using any kind of rule or condition, that's the nice thing about it.

Saturday, 5 September 2015


The message system of Kaduria is using a ID for each message that points to proper message buffer with versions for situations like blindness and also for other than player's messages. The message can be something like "%100The # is burnt out." where # is replaced by noun, in this case "torch" for example. This kind of system is quite nice, because it removes checks for blindess etc. in the routines that are calling messages.

It's not difficult to track messages IDs even it feels like a dumb idea to call Message(100); to display that message. The real problem with this approach is that the message list becomes large and more importantly the message data is detached from the "data type" classes. In this example I have I_Light_Item class just for items that emit light, like torches, lamps etc. This class has information about light items such as can it be re-filled with lamp oil. But it would be really useful to have also message data included in the class.

The problem at least for now is that message routines become "dumb", they need external data to determine if the message was triggered by the player and also information about blindness etc. This could be solved by some kind of generic routine that handles raw data, possibly even similar type of data to what the main message routine has.

Whatever the solution is I find messages one of the annoying parts of roguelike programming, as if there weren't plenty of them already.