RedPanda Development Blog

I daresay Tommy and I wrapped up the conversation editing interface.  But who knows?  That’s the trouble with GUI-related endeavors: the goals of the endeavor are rarely clearly defined.  People usually say something like, “I want a graphical interface.  It should look pretty.  And, above all, users shouldn’t have trouble using it.”  But the idea of “looking pretty” is clearly subjective; and the idea of “users not having trouble” is something that’s hard to measure.  So how do you know when you’re done making a user interface?  You don’t.  There’s always something more you can do.  You can always make the interface a little more intuitive.

Nonetheless, I’m declaring the Conversation Editing Cycle complete.  If we get tons of negative feedback from our artists and other users, then perhaps we’ll tweak things.  But I personally think the interface is pretty slick.

Onwards and upwards!  (Physics?)

I began creation of a login box, painstakingly positioning the pieces in their proper places, which NetBeans made rather difficult, but I prevailed! Though when we decide we need to add more components to it (as we inevitably will), I will have to do go through the process again.

[ A screen shot and some problems after the jump. ]

(more…)

The conversation editing interface has been mostly completed. Before I began today there were three main things that needed to be done:

1) The ability to edit a conversation’s initial evaluations (the evaluations that decide the very first statement.)

2) The ability to “jump” to any statement in order to edit it.

3) The ability to handle what insertion queries will be run when a statement is reached.
The first of these was easy. Since the initial evaluations are implemented as a Response (even though there’s nothing being responded too), I was able to use the currently existing EditResponse GUI.

The second was even easier. I just added a “Goto” button that takes a user to the statement whose label has been typed in a nearby text box. Of course, this requires a user to already know the label of the statement she wishes to go to. Carl’s tree-like navigation system would be much superior (from an HCI perspective.) But this should work for the time being.

The third is not yet complete. I have created the necessary GUI component for managing queries. And it opens properly when you click the button “Manage Queries” from a Statement editing screen. But not much of its logic is in place (except that it populates a list box with the queries attached to a Statement.)

Also, I’ve been thinking that NPCs will need to do more than simply insert things into tables. We’ll also want to be able to remove things. This requires altering the scripting language, the parser, and the code that makes the actual database calls. But all-in-all, I don’t think it will be too hard.

The entire implementation of in-game chat turned out not to be very difficult at all. The chat client and chat server were written by Matthew D. Hicks, the developer of Java Game Networking (the networking API that we use.) The only tricky part was to take the chat-related code (which was just a JGN test/example) and import it into our game.

Our server (NetworkBetterServer) now starts a ChatServer in a new thread. The chat server’s TCP (reliable) address will always be on a port number equal to NetworkBetterServer’s reliable port number plus one. And the chat server’s UDP (fast) address will always be on a port number equal to NetworkBetterServer’s fast port number plus one.

So if you type “./run NetworkBetterServer 9999″ you’ll get the following port assignments:

NetworkBetterServer TCP : 9999

NetworkBetterServer UDP : 9999 + 100

ChatServer TCP : 9999 + 1

ChatServer UDP : 9999 + 101

The client-side of things is slightly more complicated (although the port assignments are identical to the above.) We had to give the ChatClient access to our JMEDesktop in order to render the chat-related swing components in our game.

The only thing that remains to be done is to have ChatClient access the database in order to give the chatter a proper nickname. Right now the chatter’s name defaults to “test.”