ChatBlade How To Documentation
How To Add ChatBlade to a Game

Related ChatBlade Classes and functions:  
    CBSampleImplementation
    CBClientImplementation
    CBSlashCommands
    CBChatHandler
    SlashCommands.xml

 
Summary:  
  Jump to section   Compile the ChatBlade Sample applications to make sure ChatBlade is working.  
  Jump to section Add ChatBlade to the Game Project and configure compilation.    
  Jump to section Configure ChatBlade for either single word Character Names, or multiple word Character Names.  
  Jump to section Create an instance of CBChatHandler and call CBChatHandler::InitializeChat() once from the Game Client.  
  Jump to section Hook up a CBTextWindowData instance for each Chat Window or Chat Tab created.  
  Jump to section Assign Chat Channels to Monitor (listen to) for each initial Chat Window.  
  Jump to section Hook up a CBEditFieldData instance for each Chat related Edit Field used in the Game Client.  
  Jump to section Implement Chat History (Chat Repeat) in the GUI.  
  Jump to section When the Player enters a line of Chat text, call CBChatHandler::OnLineEntered() with the text.  
  Jump to section When a Chat Message is received over the Network, call CBChatHandler::OnIncomingChatMessage() with the Chat Message.  
  Jump to section Call CBChatHandler::OnCharacterLogout() if a Player logs out to a Character select screen.  
  Jump to section Implement the stub functions found in CBClientImplementation.  
  Jump to section Redraw a Chat Windows contents when CBClientImplementation::OnMessageAddedToTextWindow() is called.  
  Jump to section Hook ChatBlade up to the Games Networking code.  
  Jump to section Remove CBSampleImplementation and the sample Networking code from the Game Project once CBClientImplementation is complete.  
  Jump to section Create a real Chat Server and hook it up to the Games database.  Remove the Sample Chat Server.  
  Jump to section Create a way for Users to configure the initial Slash Command Interface.  
  Jump to section Create a way for Users to assign Chat Channels to Monitor for each Chat Window/Tab.  
  Jump to section Create a way for Users to set a Default Slash Command for each Edit Field.  
  Jump to section Implement the stub functions found in CBSlashCommands and add new functions according to Game design.  
  Jump to section Add in artificial in-game Languages (Elvish, Vulcan, etc.  ) according to Game design.  
  Jump to section Enable the User to Hyperlink items in Chat.  
  Jump to section Enable the Chat Windows to display Hyperlinked items.  
 

 
Details:  
 
Compile the ChatBlade Sample applications to make sure ChatBlade is working.  
     The first step in integrating ChatBlade into a Game is to make sure that ChatBlade is working.  
ChatBlade ships with sample programs and a Sample Chat Server.  
Compile the CBMFCTestClient and CBSampleChatServer applications and get them talking to each other.  
This should ensure that the Include directories are set correctly for compilation and the Compiler and ChatBlade are compatible.  
See How To Compile ChatBlade Sample Programs.   
 
Add ChatBlade to the Game Project and configure compilation.    
     ChatBlade ships as various C++ source files.  
These files should be added into the Game Client project for compilation and inclusion into the Game.  
Add these files to the Game project:  CBAliasList.cpp, CBChatFilter.cpp, CBChatHandler.cpp, CBChatMessage.cpp, CBChatSampleNetworkClient.cpp, CBClientImplementation.cpp, CBCommandMap.cpp, CBData.cpp, CBEditFieldData.cpp, CBIgnoreList.cpp, CBLanguageTable.cpp, CBNicknameList.cpp, CBSampleImplementation.cpp, CBSlashCommands.cpp, CBTextWindowData.cpp, and CBUtils.cpp.  
    Note:  CBSampleImplementation.cpp and CBChatSampleNetworkClient.cpp should eventually be removed once their functionality is implemented by the Game.  
Add the ChatBlade\Include directory to the directories the project should search in order to find Header files.  
Decide whether or not to use UNICODE for Chat.  UNICODE allows Chat to be in any current language, and Players can type in Mandarin, Korean, English, and Swedish simultaneously.  
UNICODE is a bit harder to debug, as each Character is typically 2 bytes rather than 1, but it is recommended that UNICODE be used in order for a game to have maximum market potential.  
In order to include UNICODE support, a Game project should define both UNICODE and _UNICODE as preprocessor definitions.  
The ChatBlade sample classes make use of some XML files to load up the Slash Command Interface, Bad Word Filter, and a sample Elvish Language.  Copy SlashCommands.xml, Filter.xml, and Elvish.xml into the directory of the compiled Game executable.  These files can be removed if the Game comes up with alternatives for loading their data.  
No Example provided.   
 
Configure ChatBlade for either single word Character Names, or multiple word Character Names.  
     ChatBlade supports Games which utilize both single word Character Names and multiple word Character Names which may have spaces in a Characters Name.  
If Game Design dictates that the Game should support multiple word Character Names then CB_CHARACTER_NAME_DELIMITER should be #defined as a comma (',') in CBConstants.h, otherwise it should be #defined as a space (' ').  
For multiple word Characters Names, Players can send a /tell to another Player by typing a comma after the name of the Player to /tell to and before the Text to tell.  
For single word Character Names a Player can just use a space or a comma after the Player Name when sending a /tell.  
Edit the #define of CB_CHARACTER_NAME_DELIMITER in CBConstants.h to support the choice of single word or multiple word Character Names, according to Game Design.  Just comment out one #define and uncomment the other.  
See How to Configure ChatBlade for multiple word Character Names.  
Sample Code:  
 
Create an instance of CBChatHandler and call CBChatHandler::InitializeChat() once from the Game Client.  
     A Game Client should create one instance of the CBChatHandler class upon startup, and should call CBChatHandler.InitializeChat() from that instance as quickly as possible.  
CBChatHandler.InitializeChat() sets a global pointer to the CBChatHandler instance which various portions of ChatBlade use to access members of the CBChatHandler instance.  It also loads up Slash Command Interface, Chat Filter, Language Tables, Alias List, Nickname List, and the Ignore List.  
CBChatHandler.InitializeChat() should be invoked before calling any other ChatBlade functions.  
Sample Code:  
 
Hook up a CBTextWindowData instance for each Chat Window or Chat Tab created.  
     ChatBlade stores the Chat Messages to display in an instance of CBTextWindowData.  
Each in-game Chat related Text Window or Chat Tab should have an instance of CBTextWindowData associated with it to keep track of the Chat Messages which should be displayed in that Text Window.  
In addition, CBTextWindowData also keeps track of which Chat Channels a Text Window should be Monitoring (displaying).  
ChatBlade mandates that each Text Window have a unique ID.  
Game Developers should call CBData::AddTextWindowData() whenever a new Chat Window is created.  This function creates an internal instance of CBTextWindowData that ChatBlade uses to keep track of the Chat Messages to display in the Chat Window as well as which Chat Channels to Monitor for that Window.  
When a new Chat Message is added or deleted from the Chat Window, the Chat Window is notified that its contents have changed.  The text should redrawn by obtaining information on the Chat Messages from its associated CBTextWindowData instance.  ChatBlade supplies various functions to facilitate this.  
ChatBlade shall call CBClientImplementation::OnMessageAddedToTextWindow() whenever a Chat Windows contents have changed.  The Game Developer should implement this function to notify the related Chat Window that it should redraw its contents.  
Initially a new Chat Window is not Monitoring any Chat Channels.  Chat Channels to Monitor should likely be added upon Chat Window creation.  
See How To Hook up a Text Window to ChatBlade.  
Sample Code:  
 
Assign Chat Channels to Monitor (listen to) for each initial Chat Window.  
     New Chat Windows initially are Monitoring no Chat Channels and shall receive no Chat Messages.  
Chat Channels to Monitor should be added to new Chat Windows.  
Individual Chat Channels to Monitor can be added by calling CBTextWindowData::AddChannelID(nTextWindowID, nChannelType) with the WindowID and the Chat Channel ID that indicate which Chat Channel the specified Chat Window should Monitor.  
Groups of related Chat Channels (all Combat Channels for instance) can be added simultaneously via various helper functions such as CBTextWindowData::AddAllCombatChannelIDs().  
When ChatBlade receives a Chat Message on a Chat Channel that the Chat Window is Monitoring, it shall add that Chat Message to the CBTextWindowData instance that is associated with the Chat Window and then call CBClientImplementation::OnMessageAddedToTextWindow() to inform the Game that the Chat Windows contents have changed.  
See How To Monitor various Chat Channels and How To Hook up a Text Window to ChatBlade.  
Sample Code:  
 
Hook up a CBEditFieldData instance for each Chat related Edit Field used in the Game Client.  
     Each Chat related Edit Field in the GUI should have an associated instance of CBEditFieldData created for it.  
CBEditFieldData keeps track of an Edit Fields default Slash Command and its Chat History (Chat Repeat).  
Each Edit Field may have a different default Slash Command that gets used if no Slash Command is provided.  So one Edit field may be set to be /group while another is /say, and a third defaults to /auction.  
ChatBlade also allows users to repeat any text they have typed into an Edit Field.  This is known as Chat History.  Typically if a user hits the up or down arrows while an Edit Field has focus, the text of the Edit Field should change to previously typed in Chat.  
CBEditFieldData keeps track of both the default Slash Command and the Chat History of its associated GUI Edit Field.  
ChatBlade mandates that each Edit Field have a unique ID.  
Developers should call CBData::AddEditFieldData() whenever a Chat related Edit Field is created in the GUI.  This call creates an internal instance of CBEditFieldData that ChatBlade uses to keep track of the default Slash Command and the Chat History of that Edit Field.  
If an Edit Field is shared amongst multiple Chat Tabs, where one tab might be for Group Chat and another is Guild Chat, then the GUI should change the default Slash Command of the single Edit Field whenever the User changes to a new Tab.  
If the User wants to repeat previously entered Chat, the Game should replace the current text in the Edit Field with the text returned from CBEditFieldData::OnUpArrow() and CBEditFieldData::OnDownArrow().  
See How To Hook up an Edit Field to ChatBlade.  
Sample Code:  
 
Implement Chat History (Chat Repeat) in the GUI.  
     Chat History is the ability to allow Players to repeat lines of previously entered text.  
Typically a Game shall cycle through Chat Text the Player had previously entered whenever the up or down arrow keys are pressed while a Chat Edit Field has focus.  
ChatBlade has full support for Chat History and keeps track internally of where in the History a Player may be cycling.  
Game Developers should replace the text of an Edit Field with the text returned from CBEditFieldData::OnUpArrow() and CBEditFieldData::OnDownArrow() whenever the Player hits the up or down arrows while the Edit Field has focus.  
Any new text entered resets the internal History location and is added to the Chat History unless the text is identical to the last line of text entered into the Edit Field.  
See How To Hook up an Edit Field to ChatBlade.  
Sample Code:  
 
When the Player enters a line of Chat text, call CBChatHandler::OnLineEntered() with the text.  
     When a Player types in some Chat into an Edit Field the Game should call CBChatHandler::OnLineEntered() and pass it the text the Player typed in.  
ChatBlade shall then process the text and expand any Macros or Chat Aliases.  If a Nickname is used the Nickname shall be expanded to a full Character Name.  ChatBlade shall prepend the default Slash Command for the Edit Field to the text if no Slash Command is supplied.  
ChatBlade shall then route the text appropriately, typically invoking one of the functions of CBSlashCommands.  
Generally it is a very simple process:  When a Player enters some Chat Text, just pass the text to CBChatHandler::OnLineEntered() and let ChatBlade take care of the routing and processing.  
New text is added to an Edit Fields Chat History as long as it is not the same as the last line typed into that Edit Field.  
See How To Hook up an Edit Field to ChatBlade.  
Sample Code:  
 
When a Chat Message is received over the Network, call CBChatHandler::OnIncomingChatMessage() with the Chat Message.  
     When the Game receives a Chat Message from the Chat Server over the Network, the Game should call CBChatHandler::OnIncomingChatMessage() with the incoming Chat Message.  
ChatBlade shall then process the Chat Message and route it to any Chat Windows which are Monitoring the Chat Channel of the incoming Chat Message.  
ChatBlade takes care of if the Chat Message should be displayed or not (checks for Chat Messages from Players on the Ignore List, or from an opposing Faction).  
If the incoming Chat Message is a /tell, ChatBlade stores the Senders Character Name for use in /replying to the Chat Message.  
A Chat Message can be displayed on multiple Chat Windows if more than one Chat Window is Monitoring the same Chat Channel.  
See How to Hook ChatBlade up to a Games Networking Code.  
Sample Code:  
 
Call CBChatHandler::OnCharacterLogout() if a Player logs out to a Character select screen.  
     If a Player logs out their Character but does not fully exit the Game, a call to CBChatHandler::OnCharacterLogout() should be made to inform ChatBlade that the Game UI is likely gone.  
This function resets the AFK and DND flags as well as removing any Mood or Language settings.  
It also removes all CBTextWindowData and CBEditFieldData instances, enabling a new UI to be created.  
Game Developers should create new instances of CBTextWindowData and CBEditFieldData if the Player logs in with a new Character and a new UI.  
This function does not reset the /reply setting so a Player can still /reply to the last User to send them a /tell, even if they log in a new Character.  
Sample Code:  
 
Implement the stub functions found in CBClientImplementation.  
     ChatBlade includes 2 Classes which contain stub functions which should be implemented by the Game Developer:  CBClientImplementation and CBSlashCommands.  
Game Developers should edit the CBClientImplementation.cpp file and implement the stub functions found there to work with the Game Design.  
ChatBlade uses some of these functions to get data on the Players current Class, Level, and Race in order to support their specific Chat Channels (CB_CHANNEL_CLASS,  CB_CHANNEL_LEVEL, or CB_CHANNEL_RACE).  
ChatBlade calls functions in this Class in order to Load the Slash Command Interface, Bad Word Filter, Ignore List, and other settings upon game startup.  Much of this Data would likely come from the Game Database.  
ChatBlade calls CBClientImplementation::OnMessageAddedToTextWindow() whenever a new Chat Message is added to or removed from a Chat Window.  Developers should implement this function to Notify the corresponding GUI Chat Window that its contents have changed and it needs to be redrawn.  
ChatBlade calls stubs in this class in order to get a Players GroupID, GuildID, RaidID, or AllianceID in order that it may set the correct destination for Chat Messages.  
ChatBlade calls stubs in this class in order to determine the level of Intoxication so that Chat may be Intoxicated (made to look like drunken speech).  
ChatBlade calls a stub in this class in order to determine how proficient the Character is in a certain Language in order to know how drastic to alter Chat Messages that are sent in that Language or to determine if a Character is fluent enough to send Chat in the specified Language.  
ChatBlade calls stubs in this class so that the Game may Animate Chat, emit sound indicators for Chat Messages on certain Chat Channels, or display Chat Bubbles.  
ChatBlade uses members of this Class to determine if a Chat Message should be displayed (is of an opposing faction or is from a CSR representative).  
ChatBlade calls CBClientImplementation::SendChatMessage() in order to send a Chat Message over the wire to the Chat Server.  Developers should implement this function to talk with the Games networking code.  
Currently, most the stubs in CBClientImplementation pass through and call the corresponding functions in CBSampleImplementation.  Once each stub is implemented the pass though to CBSampleImplementation should be removed.  
Once all the stubs have been implemented CBSampleImplementation should be removed from the compilation.  
See CBSampleImplementation.cpp for examples.    
 
Redraw a Chat Windows contents when CBClientImplementation::OnMessageAddedToTextWindow() is called.  
     ChatBlade calls CBClientImplementation::OnMessageAddedToTextWindow() whenever a Chat Message is added to or removed from a Chat Window.  
It is envisioned that Game Developers shall implement this function to Notify the corresponding GUI Text Window that its message contents have changed and that it likely needs to redraw its text.  
ChatBlade passes in the WindowID of the GUI Window that has had a new message added (or all messages cleared).  
See the source code for CBMFCTestClient.cpp.  
Sample Code:  
 
Hook ChatBlade up to the Games Networking code.  
     Different Games shall have different Networking Code.  Some might use Networking Middleware, while other Games might write their own socket implementations.  
ChatBlade cannot know which Networking various Game Developers shall use.  
ChatBlade ships with sample Networking based upon Windows Sockets.  This code is just sample code and it is envisioned that it should be removed once ChatBlade is hooked up to a Games existing Networking Code.  
ChatBlade calls CBClientImplementation::SendChatMessage(CBChatMessage cbcmChatMessage) whenever a Chat Message needs to be sent over the wire to the Chat Server.  
Game Developers should implement CBClientImplementation::SendChatMessage() and have it talk to the Games Networking Code.  
For incoming messages from the Chat Server, the Networking Code should call CBChatHandler::OnIncomingChatMessage().  ChatBlade shall handle the processing from there.  
For security, it is recommended that all Chat Messages be encrypted when going over the wire.  
For security, it is also recommended that Game Clients only talk to the Chat Server, and never to each other in a peer-to-peer fashion.  If Players know the IPAddress of other Users they can flood them or attack them in various ways.  
See How to Hook up Networking to ChatBlade.   
 
Remove CBSampleImplementation and the sample Networking code from the Game Project once CBClientImplementation is complete.  
     Once all the stubs in CBClientImplementation have been implemented and ChatBlade is hooked up to the Games Networking Code, CBSampleImplementation and CBChatSampleNetworkClient should be removed from the Game.  
CBSampleImplementation just contains some sample functions that demonstrate how one may implement certain functionality.  It is not part of the core ChatBlade product and is for sample purposes only.  
CBChatSampleNetworkClient is a similar class.  It is only provided to give a rudimentary Sample Networking capability, designed to talk with the Sample Chat Server.  It is not part of the core ChatBlade product and should be removed once ChatBlade is hooked up to the Games Networking Code.  
When they are no longer needed, both classes should be removed from the Games compilation.  
This line in CBChatHandler.h should be removed:  
        CBSampleImplementation m_SampleImplementation;
Any code referencing CBChatHandler::m_SampleImplementation should be deleted.  
Sample Code:  
 
Create a real Chat Server and hook it up to the Games database.  Remove the Sample Chat Server.  
     In order for Chat to function in a Game, the Game Client shall need to talk to a Chat Server and have it propagate Chat Messages to other Players.  
The Chat Server shall need to talk to the Game Database in order to know which Players are in which Groups and Guilds.  
Since ChatBlade cannot know in advance the Schema of a Games Database, it is up to the Game Developer to create the Chat Server which talks to the Database and retrieves a list of Players who should receive a Chat Message.  
ChatBlade does ship with a Sample Chat Server written in Java.  It contains SQL pseudo-code demonstrating how one might lookup the recipients of a Chat Message.  
A Chat Server shall need to communicate via the Games Networking Code.  
ChatBlade has endeavored to allow for as simple of a Chat Server as possible.  Primarily, all a Chat Server needs to do is look at a Chat Message and use the Chat Messages Channel and Destination to come up with a list of recipients.  It then needs to forward the Chat Message to those recipients.  
A Chat Server should also report back to the Sender in case of errors (Players not online, etc.  ).  
See How to Design a Chat Server.   
 
Create a way for Users to configure the initial Slash Command Interface.  
     One of ChatBlades major innovations is the ability to allow the Player to configure the Slash Command Interface to their liking.  
Most MMORPGs have a hard-coded Slash Command Interface.  For Example, a game might have /g be hard-coded to Group Chat.  
Unfortunately there is no standardization and another MMORPG might have /p be the command to communicate with ones Group.  
This is a cause of frustration for the Player Base as many Players have played multiple MMORPGs.  It is unpleasant to switch to a new Slash Command Interface for each different game.  
ChatBlade remedies this problem by allowing Game Developers to let the User customize the initial Slash Command Interface.  If a User is used to /g being Group Chat then they can configure ChatBlade as they desire.  
ChatBlade ships with a Sample XML file, that contains the Slash Command Interface initially used by ChatBlade.  It is potentially User editable.  
Game Companies might want a more error proof method of allowing the User to customize the Slash Command Interface.  If so the Game Developer must create it.  ChatBlade has full support for such customization.  
A Game Developer might create a Dialog Box allowing the User to enter in the desired Slash Command and match it to its functionality.  So if the User was used to /t being the Group Chat command they could specify that /t initiates Group Chat in a GUI fashion.  
If the Developer does not want to put in the effort of creating a GUI Dialog for the Users, at a minimum the SlashCommands.XML file should be included in the Game distribution (and a mechanism for fixing it in case of corruption).  
See SlashCommands.XML 
 
Create a way for Users to assign Chat Channels to Monitor for each Chat Window/Tab.  
     Most MMORPGs allow the User to have multiple Chat Windows open at once.  Each Chat Window typically receives different messages.  
One Chat Window is typically devoted to Combat spam, while others may focus on Group Chat or Auction messages.  
ChatBlade supports an unlimited amount of Chat Windows listening in on various Chat Channels.  
Game Developers need to create a GUI mechanism to allow Players to choose which Chat Channels each Chat Window or Chat Tab shall Monitor.  
A Chat Windows related CBTextWindowData instance keeps track of which Chat Channels a Chat Window is Monitoring.  
A GUI Mechanism would hook into the CBTextWindowData instance and set the Monitoring of the correct Chat Channels the User selects.  
See How to Monitor various Chat Channels.  
 
Create a way for Users to set a Default Slash Command for each Edit Field.  
     Many MMORPGs allow for multiple Edit Fields in the GUI.  Typically the Edit Fields are located under Chat related Text Windows.  
ChatBlade allows each GUI Edit Field to have a different Default Slash Command.  
A Default Slash Command is the Slash Command used if no Slash Command is supplied by the User.  
One Edit Field may default to /say while another defaults to /group to send Chat Messages to the Players Group.  
A GUI mechanism is needed to allow the User to customize the Default Slash Command for each Edit Field.  
A Drop down list may be used, but a better option is to create an Edit area that contains the Default Slash Command.  This way the user can use Default Commands such as "/tell Irridia," and not be limited to just a drop down of Group/Guild/Say.  
ChatBlade stores the Default Slash Command for an Edit Field in its related CBEditFieldData instance.  Each GUI Edit Field that is related to Chat should have a Unique ID and an associated CBEditFieldData instance in ChatBlade.  
The GUI configuration of the Default Slash Command should hook into this instance and set the proper Default Command.  
See How to Hook up an Edit Field to ChatBlade.  
 
Implement the stub functions found in CBSlashCommands and add new functions according to Game design.  
     ChatBlade ships with 2 classes designed to be implemented primarily by Game Developers: CBSlashCommands and CBClientImplementation.  
CBSlashCommands contains over 150 stubs for common Slash Commands that Developers should likely implement.  Function stubs include things like CBSlashCommands::OnCommandFollow(), and CBSlashCommands::OnCommandGroupInvite().  
Each Slash Command action should have a function member in CBSlashCommands.  ChatBlade handles the routing and processing and invokes the appropriate function in response to Player entered Slash Commands.  
All members of CBSlashCommands are static, and an instance of the class does not need to be created.  (Static functions were used to obtain the function pointers to place into CBCommandMap instances).  
ChatBlade has implemented the Slash Commands that directly relate to Chat, such as OnCommandGroupChat(), OnCommandSay(), and OnCommandTell().  ChatBlade has partially implemented functions that relate to Chat but also may need additional functionality implemented by the Game Developer, such as OnCommandAFK(), and OnCommandNickname().  
It is envisioned that each Game shall have a different assortment of Slash Command functionality.  Some functions in CBSlashCommands shall not be needed, while other functions shall likely need to be added, according to Game Design.  The initial functions provided are just a suggestion of common MMORPG functionality.  
It is expected that CBSlashCommands shall be heavily modified for each Game.  
Game Developers should implement the stubs in CBSlashCommands which make sense for their Game, and add in new functions according to their unique Game Design.  
See How to add a new Slash Command.  
 
Add in artificial in-game Languages (Elvish, Vulcan, etc.  ) according to Game design.  
     ChatBlade allows Games to have artificial Language support for Fantasy/Sci-Fi Languages such as Elvish, Orcish, or Vulcan.  
Languages can add flavor to a Game.  
To implement a Language, primarily the Game Developer needs to fill up an instance of CBLanguageTable with words which sound appropriate to the in-game Language.  
Developers should also implement CBClientImplementation::GetLanguageKnowledgeLevel() to tell ChatBlade how well a Character understands a target Language.  
ChatBlade takes care of translating Chat Messages received in an artificial Language.  If a Character understands a Language 50% then about half the words of a Chat Message coming in in that Language shall be replaced with words from the artificial Language.  
Characters that know a Language 100% may change their default Chat Language to the Language they are fluent in.  
New Elf Characters may be given 100% fluency in Elvish, for instance.  
It is very easy to add artificial Languages to ChatBlade.  Mainly just come up with a list of words which sound like they are representative of the Language.  
ChatBlade ensures that each real word always matches the same artificial Language word.  
A Sample Elvish.XML file is provided, as well as sample code which loads it into ChatBlade: CBSampleImplementation::LoadLanguageTables().  
See How to Add an in-game Language to ChatBlade.  
 
Enable the User to Hyperlink items in Chat.  
     Most MMOGs allow the Hyperlinking of items in Chat.  
ChatBlade has full underlying support for item Hyperlinking.  
Item Hyperlinking allows Users to click on items in a text window, and pull up the stats of the item.  
This is an excellent feature that saves Users lots of effort.  
But supporting this feature shall mean significant work needs to be done enhancing any Chat Windows and Chat related Edit Fields.  
ChatBlade represents Hyperlinked items using an href type code.  
    href=IB38472C<Sword of Thunder>  is an example of how ChatBlade expects Hyperlinks to be stored by default.  
    The IB38472C might be an ItemID of the linked item in the Game Database.  
    The part in brackets, <Sword of Thunder>, would be the name of the Hyperlinked item.  Only the text in the brackets should be displayed to the User in a Chat Window or Edit Field.  
Users need a way to Hyperlink items in Chat.  The preferable way is to allow Users to drag and drop items from their inventory, to a Chat Edit Field.  Alternatively, users might be able to double click an item to Hyperlink or paste a Hyperlink in other fashions, but Dragging and Dropping into Chat is the most intuitive.  Game Developers must implement a way to let Players Hyperlink Items into Chat Text.  
Chat Edit Fields shall need to be modified to retain the entire "href=IB38472C<Sword of Thunder>" text but only display to the User the "Sword of Thunder" portion.  
Chat Edit Fields shall need to be modified to disallow editing of the Hyperlink.  The User should not be able to modify the "Sword of Thunder" text or any portion of the Hyperlink.  If the User has focus on the Edit Field and arrows back to make changes to the text, the cursor should skip over the Hyperlink.  
Hyperlinks need to be displayed differently from other Chat Text, preferably in an alternate color.  Users need to know what the Hyperlink portion of the text is, so they may click on it and bring up the items stats.  Italics or Underlining might also be used, but alternate colored text for Hyperlinks is preferred.  
Edit fields need to support multiple Hyperlinks interspersed with regular Chat Text.  
    For Example:  
        /auction href=IB38472D<Sword of Lightning> 20000 gold or trade for href=IC32987F<Book of Agility>
    Which would display in the Edit Field as:
        /auction Sword of Lightning 20000 gold or trade for Book of Agility
ChatBlade supports Hyperlinks in all Chat Messages.  CBChatMessage breaks the Hyperlink portions of Chat Text into their own fields in the CBChatMessage instance.  
ChatBlade ensures that Hyperlinks are not modified by Intoxicated speech or in-game Languages like Elvish.  
Significant work needs to done to the GUI Edit Fields and GUI to enable Users to Hyperlink items.  
No Sample Code provided.   
 
Enable the Chat Windows to display Hyperlinked items.  
     In addition to allowing Users to Hyperlink items in an Edit Field, the GUI Text Windows must be altered to support displaying and clicking upon Hyperlinked items.  
A Text window should only show the text portions of Hyperlinked items and should hide, but retain the "href=12E81D" codes.  
So while the Chat Text may be:  
    href=IB38472D<Sword of Lightning> 20000 gold or trade for href=IC32987F<Book of Agility>
the Text Window should only show:  
    [auction] Vanadia: Sword of Lightning 20000 gold or trade for Book of Agility
In addition the Hyperlinks need to be able to be clicked upon by the end User.  Clicking on "Sword of Lightning" in the Text Window should pull up a dialog box displaying the stats for the Database item with an ID of "IB38472D".  
ChatBlade includes various functions which return the Chat Text with coded Hyperlinks or with the Hyperlink codes stripped out but the Hyperlink Text retained.  See CBChatMessage::GetChatStringWithHyperlinks() and CBChatMessage::GetChatString().  
If the Game utilizes Chat Bubbles then CBChatMessage::GetChatBubbleString() may be used.  Hyperlink tags are not included in the returned text for Chat Bubbles, nor is the initial Channel name or Character Name.  
Significant work shall need to be done in the Chat Window in order to enable the display of Hyperlinks (in an alternate color preferably) and the ability to click the Hyperlinks, even as they scroll up Chat Window.  
No Sample Code provided.  
 
    
 

 

Code Samples:  

Configuring ChatBlade to handle multi-word  or single word Character Names.  
Edit the #Define in CBConstants.h
//  For single word Character Names
#define CB_CHARACTER_NAME_DELIMITER _T(' ')
     //  For multi-word Character Names
#define CB_CHARACTER_NAME_DELIMITER _T(',')
 
Creating an instance of CBChatHandler and starting up ChatBlade.  
     CBChatHandler cbchChatHandler;
cbchChatHandler.InitializeChat();
 
Hooking up a GUI Text Window with a WindowID of 1 to ChatBlade.  
     CBData::AddTextWindowData(1);
 
Adding some Chat Channels to Monitor to a Text Window with an ID of 2.  
     CBData::mTextWindowDataMap[2].AddAllCombatChannelIDs();
CBTextWindowData::AddChannelID(2, CB_CHANNEL_TELL);
CBTextWindowData::AddChannelID(2, CB_CHANNEL_GROUP);
 
Hooking up a GUI Edit Field with an ID of 1 to ChatBlade.  
     CBData::AddEditFieldData(1);
 
Implementing Chat History for an Edit Field with an ID of 1.  
//  In response to an Up Arrow Key Up notification when the Edit Field has focus
SetWindowText(CBEditFieldData::OnUpArrow(1));  //  Assuming the GUI Edit Field has a similar command
//  In response to a Down Arrow Key Up notification when the Edit Field has focus
     SetWindowText(CBEditFieldData::OnDownArrow(1);  //  Assuming the GUI Edit Field has a similar command
 
Passing a line of Player entered Text to ChatBlade from an Edit Field with an ID of 1.  
     CBData::pChatHandler->OnLineEntered(sChatLine, 1);
 
Passing a Chat Message received over the wire to ChatBlade.  
     CBData::pChatHandler->OnIncomingChatMessage(cbChatMessage);
 
Resetting some ChatBlade code when a Character logs their Character out to a Character Select screen.  
     cbchChatHandler.OnCharacterLogout();
 
Redrawing a Text Windows contents when it has been notified of a new or cleared Chat Message.  
     int CDevelopersGUITextWindow::OnTextChanged()
     {
CBChatMessage cbChatMessageCopy;
CBSTRING sCompleteTextString;
CBSTRING sTempString;
 
if(CBTextWindowData::GetLastChatMessage(nTextWindowID, cbChatMessageCopy) == CB_ERROR_DOES_NOT_EXIST)
  {
  //  There are no Chat Messages
  sCompleteTextString = CB_EMPTY_STRING;
  }
else
   {
//  Get the Chat Text from our newest Chat Message
cbChatMessageCopy.GetChatString(sTempString);
//  Get the previous text that is currently in the Text Window
GetWindowText(sCompleteTextString);  //  Assuming the GUI Text Window has a similar function
//  Add the latest line
sCompleteTextString += sTempString;
}
//  Set the new Window text
SetWindowText(sCompleteTextString);  //  Assuming the GUI Text Window has such a function
return(CB_SUCCESS);
}
 
Removing the CBSampleImplementation from CBChatHandler.h.  Add the comment:  
     //  CBSampleImplementation m_SampleImplementation;
 
    
 
    
 
    
 
    
 
    
 
    
 
    
 
    
 
    
    
 

 

 

 

 

 

 
 
 
 
ChatBlade Copyright Flex Dolphynn