RedPanda Development Blog

So I’ve been thinking that it would be really cool if we could get our game (or even just a demo) to run from our website with Java Web Start.

I wrote a webstart test, that you can run from the server by clicking this link:

/jws/test.jnlp

I jar’d the game and added the necessary webstart stuff, but I wasn’t in the math lounge so I couldn’t actually connect. We need to see if we can get IT to forward the necessary ports to run our game from off campus. (Also, I wonder if that’s related to the problem I posted about previously?) You can try running the game through webstart with the following link, but it takes a few minutes to download the jar file and then all you actually get to see it the login box, but if you want to check it out, go ahead.

/jws/game.jnlp

I found another 3D MMORPG that runs via Java Web Start - Wurm Online. I checked it out, and it’s kind of neat. I didn’t play it for very long, but I think it’s cool that it uses JWS, and it looks relatively mature. If you’re planning on giving it a go, you need to register for an account on the site first. And it takes a while to download the first time.

Please ignore the many, many emails that may have recently been sent to you.  They were waiting in a queue until Bobby got our RedPanda server to properly send emails.

Stephen and I have designed a basic framework for giving models in our game the ability to act for themselves! This code can be found in the new game.ai package in the repository, and in the spikesAndTests package. If you want to check out an awesome die moving all on its own, run

java -Djava.library.path=../project/lib spikesAndTests.AISpike 3 9999

or with whatever parameters are relevant. (HINT! try rotating the die while it’s moving around.)

What has yet to be done is integrating the BrainManager (don’t laugh!) into our main code base and creating a wonderful user interface for assigning Wills to Brainables.

I’ve implemented the pseudo-drag and quasi-drop mentioned in my last update, and as an added bonus, compensated for parental rotation when moving objects (Julio’s Bounty 1.) Until I can figure out how Quaternions work, it’s implemented manually by taking the parent’s rotation around the y-axis and rotating the delta-translation of the child by the opposite of that amount. (Maybe Quaternion.inverse() will have the same effect?)

The ClickManagers probably need a little refactoring. I’ll see about that this weekend.

After much frustration, I’ve finally fixed the bug with the cursor color not being updated. (Actually reading the update method helped a great deal.) Reintroducing myself to ClickManager has made me wonder if we’re approaching the translation of Wickets in the right way. We refer to our current system as “drag and drop,” but the fact that the Wicket does not remain under the cursor as long as the mouse button is held down means that we have more of a “cattle prod” interface: if it’s not doing what you want, just poke it in the direction you want it to go. Implementing a true drag and drop is well beyond my knowledge of linear algebra, but I think we could alter our current system to achieve an effect similar to a true drag and drop.

(more…)

A couple of things –

Model Linking:

Stephen and I managed to write a proof of concept for linking models. We modified the FrontClient to create a Tree and attach a Die and Castle to it, which makes changing the scale / location / rotation of the tree changes the Die and Castle also, but the Die and Castle can be moved independently. I didn’t commit the FrontClient change, though, because it causes those models to be created where you start every time you log in, which clutters things quickly. I will (sometime soon) move those changes into a spikesAndTests.LinkingSpike class or something.

When moving the parent Wicket, all wickets independently move along the terrain. This is accomplished with some simple linear algebra in the Terrain.relocateOnSurface() method.

What remains to be done is: creating special messages for preserving the hierarchy of Nodes / Wickets in the scene graph and creating some sort of user interface for managing child / parent relationships in-game. This may be all there is to it!

Chat Client:

I added some code to the game.chat.ChatClient and game.Player classes to make the chat window display the name of the player who sent the message. This is done with a call to the static method Player.getNameFromId() which, intuitively enough, queries the database to find the name of a player based on their id.

The only two players in the database right now are Enoby (id=1) and Foucault (id=2), and if you try to start a FrontClient with any other id, it will crash, which is probably not desirable behaviour, but I haven’t taken care of that yet.

I also made the chat box closable, which is a temporary fix for the very obtrusive window. I think an easily hide-able (maybe with a hotkey) window along the bottom of the screen is in order. Thoughts?

Login Box:

I changed some code in the game.gui.LoginBox class, so now clicking on “login” from that window will not crash when it tries to start the game! I did this by placing the call to FrontClient.main() in its own thread before disposing of the swing window. Right now, the login box still starts a FrontClient with player_id=1 and port=8798, but I think it will now be a trivial matter to get the player name field to intelligently pick the correct id number. I’ll have to rework some of the GUI, but I intend to put a “new player” button on there, too, which won’t be hard to implement.

I’m not sure how we want to go about populating the drop-down box of server / port choices. Ideally, there would be some way redpanda could keep track of what ports were running instances of the game and it could let connecting clients know, but I don’t know if that’s possible (or at least not very difficult). Maybe for now a text file on redpanda that we keep relatively updated with what ports are active? We could populate the combo box with the names of the servers’ save files for a friendlier interface.

I don’t know how we want to do passwords. It would be really easy for us to just add a field in the database and an if / string.equals() statement in the LoginBox class, but that would be really insecure. Though I don’t know how important security actually is, especially at this stage.

So that’s that!

EDIT: It turns out that children of Wickets don’t move along the terrain properly if the parent Wicket is scaled. I’m not sure if this means that when the parent is scaled, the child object’s origin is moved in an unusual way, or what, but this could be quite frustrating…

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?)