RedPanda Development Blog

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…