VIEWS: 0 PAGES: 6 POSTED ON: 11/1/2011
GUI Improvements By Zhan Zhizheng (gsoc_Zhan on nexus, gsoc_zzz on IRC), 2011 Personal Details Name: Zhan Zhizheng Email: firstname.lastname@example.org Location: China, Beijing University: Graduate student University of Chinese Academy of Sciences (Institute of Software, Chinese Academy of Sciences) Mayor: HCI (Human and Computer Interaction) C++ experience: 5+ years Experience on game developing: one year developing experience on a 3D storytelling game designed for children (using OGRE & CEGUI). Cell Phone: +8615110214250 Abstract Planeshift GUI system is implemented in the PAWS which is mainly based on Crystal Space’s iGraphics2D/iGraphics3D to draw all kinds of widgets. In PAWS, pawsmanager is a singleton to manage the entire GUI library. With the help of pawsMainWidget, pawsmanager could load configurable GUI interface from xml document of in CS’s virtual file system. The main goal of GUI improvement is to make Planeshift’s current GUI interface more configurable, more powerful, and user friendly. In order to achieve this goal, I am going to do following improvements: 1. Improve the Help system. Add capability to incorporate pictures/3d objects. Make it more configurable and context sensitive. 2. Improve chat window The problem with chat window now is that it needs restarting the system to perform changes in settings. Configurable tabs at runtime is going to be added into chat window. 3. Images in books Enable books to show text as well as images. 4. Color selector When we change color settings, we should assign numeric value manually. There is already a color input widget in plane shift. But there are still things to do such as adding this widget places need it, adding limitation support to color input widget to make it better. 5. Duplicate pawsWidget by copy constructor Currently, all paws widgets are load from xml files. Even if we want to duplicate a paws widget, xml parsing is also a must. That is inefficient. By adding copy construction methods to the base paws widget classes, we won’t need to parse xml any more. 6. Rendering widget by RTT It may be a little expensive to render windows by using RTT. But Planeshift will also benefit if we use it at the right place such rendering the paws sketch window. The first step for this idea is to enable drawing windows by RTT. The second step is to make the way of rendering windows configurable. 7. Improve crafting book Right now, the crafting books are full of texts that show all kinds of steps to complete crafting tasks. There are so many different crafting techniques that make the crafting books unreadable. So this idea is about to organize these crafting step list in a recipe-like way. From this recipe, players can quickly understand what they need, what to do first, and then what’s next, etc. By making these improvements, it is certain that Planeshift will get a more configurable and powerful GUI system. Implementation ideas 1. Improve the Help system. Right now, Help system is based pawshelp class to load help information from XML document files. The help information is then organized to show in the helptree widget which is a pawsSimpleTrees class. There is a helptext widget at the right side of the help window. The helptext widget is a pawsMultiLineTextBox class to show help content in a multiple lined style. When a node of the helptree is clicked, the helptext widget will display the node's corresponding help content.(See Figure 1) pawsWidget pawsControlledWindow pawsControllWindow Register WindowClose WindowOpen pawsHelp pawsChatWindow helptree pawsSimpleTrees helptext pawsMultiLineTextBox Figure 1 Some classes relationship In Planeshift, we have a class named pawsImageDrawable which is an implementation of the iPawsImage interface. By using the interface's Draw method, we could draw an image onto a frame with assigned size and position. Based on these two points above, a pawsDocumentViewBox could be implemented to display content with texts as well as pictures. Rough ideas are as following: Design a kind of XML definition which could incorporate text content and pictures. For example: <HelpDoc> <Title ...> <Text>....</Text> <Picture file=”example.png” … /> <Text>...text content continue...</Text> …..... </Title> </HelpDoc> In pawsDocumentViewBox, for those <Text> nodes, it can generally deal with them as pawsMultiLineTextBox does except for each <Text> node's first line and last line because it needs to determine these lines start X position and Y position inside a frame based on pictures' sizes before and after a <Text> node. This pawsDocumentViewBox could be implemented as a derived class of the pawsMultiLineTextBox. In this way, we could rarely modify the original code to realize displaying pictures in Help system. In order to incorporate 3D object into help system, I have a very basic idea: using RTT technique. 2. Improve the chat window. When chat tabs configuration is changed, the chat window widget's definition file name is still the old one even if the system has already stored the new settings into “chat.xml” under the “planeshift/options/” directory which stores user data. For example, if we change configuration to full style, the <chatwidget> node's value in “planeshift/options/chat.xml” is then changed to “chat.xml” which means the system will load the full chat window at the next time. And at the right time, the chat window’s definition file is still “chat_basic.xml”. So the chat window won't change to full style even if it reloads. To solve this problem, following things could be done: (I have written some code to test the idea. Here is a simple demo: http://v.youku.com/v_show/id_XMjU1MDg5NjQ4.html) The system still stores user’s configuration for chat widget in “planeshift/options/chat.xml”. But we have the third choice for <chatWidget> node’s value besides chat.xml and chat_basic.xml. That’s to say, the system produces another GUI definition file for chat widget based on user’s choices. For example, this automatically produced file could be named “chat_user.xml”. If user cancels the basic chat widget style and choose “Chat”, ”NPC”, “Auction”, “Alliance”, then system will copy tab GUI definitions of these four tabs into “chat_user.xml”. And in “planeshift/options/chat.xml”, system will set the value for <chatWidget> to “chat_user.xml”. In order to enable change tab items at runtime, the system needs to reload the chat window after all configurations are saved properly. By calling chat window’s SetFileName method which is derived from the basic pawsWidget class, system could then reload chat window to change the chat tab items at runtime. If users don’t change the tabs configuration, the system still use the chat_basic.xml to draw the chat window. If users change the configuration from other styles back to basic style, the chat_basic.xml could be still used to draw the chat window. There are many parts of plane shift referencing the chat window object. A notification schema could be implemented to ensure those parts could get the message to renew their handles for the chat window object after the chat window is reloaded. 3. Images in books If the first idea is implemented properly, then the pawsDocumentViewBox could be also used by pawsBookReadingWindow to display images in books. 4. Color selector Add the current color input widget to places need it. Improve the color input widget to support limitations of changes for color’s value. 5. Duplicate pawsWidget by copy constructor Normally, a paws widget is constructed by parsing xml definition file, loading all of its attributes, loading the frame size and style (with/without border, etc.), loading all of its children widgets, loading all script events, etc. In order to duplicate paws widget by copy constructor, following things could be done: In pawsWidget class, a copy construction function should be add to copy the existing widget’s attributes, script events array, title, border, enter, close, context menu widgets and back ground image. And then using this copy construction function to construct children widgets. For other classes in libpaws, copy construction function should be added to correctly copy all the essential information to the new one if the default copy construction don’t work properly. 6. Rendering widget by RTT A simple way to implement rendering windows through RTT is as following: (Also, a corresponding simple demo is implemented. Here goes the video: http://v.youku.com/v_show/id_XMjU1NjY4Mzc2.html) In pawsWidget class, when the draw method is called, check the widget’s render to texture switch. If the switch is turned off, let the switch hold the value of its parent’s switch. This is to ensure a widget’s children draw itself the same way as its parent. That is to say, if a widget use RTT to render, then all of its children render themselves using RTT. Initialize a blank texture the same size as the widget’s size if render to texture switch is turned on. Then tell the iGraphics3D to render to this blank texture. Draw the widget as what the direct drawing method do. Save the result to the texture and turn off RTT. Finally, draw the texture at the same place with the same size of the widget. Add a function to enable turning the RTT switch on and off. Right now, this idea is too basic that many parts of the widget’s content could not be rendered properly. Some details are waiting to be checked to make the idea better. 7. Improve crafting book In Plane Shift, a crafting book’s content is originated from the game server. During the startup session, the server’s cache manager will preload all the craft messages based on several tables that store all kinds of item combination relations, transformation relations, patterns and processes to do transformations. The server will send player’s client with crafting content by referencing player’s character’s skill level. And the client will show the crafting messages in the client’s craft window finally. To make the crafting book readable, it is mainly a task of the server side. Here is the basic implementation plans for this idea: The server processes all the craft messages in a XML way. It sends craft messages to the client as the current way. In the client side, the craft window parsed the xml messages and turn them into recipe-like text. The messages could be roughly defined as following: <Crafting pattern=”pattern description”> <NeedItems>a list of items that is needed</NeedItems> <Combination> <Prerequisites>prerequisite items</Prerequisites> <Output>output item</Output> <Description>description about this combination</Description> </Combination> …… <Transformation> <Prerequisites>prerequisite items</Prerequisites> <Output>output item</Output> <Description>description about this combination</Description> <Process>process to do this transformation</Process> </Transformation> …… </Crafting Tech> In this way, the client could parsed a recipe of crafting some specific object. Considering the problem of network transfer, xml structured message may not a good choice. A more efficient but also structured message could be easily designed to achieve the same goal. Proposal timeline Before April 25 To familiarize myself to the PAWS library, its main architecture and how to use this library to implement all kinds of windows in Planeshift. To study how to use Crystal Space 3D rendering engine, especially those details about rendering 2D objects on viewport. April 25 – May 23 (Before official coding time) To doing some test coding stuff to further understand the usage of PAWS as well as CS. To discuss the details about my ideas with my future mentor to archive a final agreement. Based on the final agreement, I will be clear about all goals. Then I will see how to implement and do some documents work for those implementation details to further discuss with my mentor. May 23 – June 18 (Official coding period starts) Start coding on improving help system by adding capability of showing pictures in the right window of the help widget. To implement the context sensitive help feature and make it configurable. Start to do coding works on improving chat window by testing to add tabs at runtime. June 18 – July 5 Finish the work on improving chat window, and test the whole work to ensure it can work properly. Start to code on adding capability of incorporate pictures in books. July 6 – July 15 (Mid-term) Finish the work on books widget and do some test work to ensure it could show pictures as well as text properly. Incorporate the current color input widget in to the system configuration window. Improve the current color input widget. Submit mid-term evaluation. July 16– July 31 Finish all my work on the GUI improvements and do bug fixing work and test. Implement to duplicate widgets by copy construction function. Start to implement the idea of using RTT to render windows and make it configurable. August 1 – August 15 Improve crafting books Redundant time for some unpredictable stuff to do. If it is possible, I could do some work on those ideas not mentioned by this proposal under GUI improvements project. Submit final evaluation.
Pages to are hidden for
"Gsoc_Zhan_Proposal_v4.2"Please download to view full document