Scripting for Single Player and Multiplayer (plus GUI Fun)

So it's been roughly a week since my first post, and I've been making a lot of progress working with TGB. As you might remember, I've been working on a game that's along the lines of a turn-based tactical strategy game, and last week I was able to put together most of the components that go into making a very simple game in the genre. This week, I've been working on two other components that I felt were going to be the trickiest parts: Integrating network multiplay, and using the GUI editor.

I'll start with the networking, as it was a feature that I thought was going to take a week to do, but I ended up finishing in less than two nights. I had a bit of trouble initially with trying to figure out how to use the same scripts for both the single player and multiplayer sections of the game. However, I was able to come up with a solution that I think works extremely well, at least for my needs.

First, I decided to keep all of the single player scripts in tact without adding in any specific multiplayer functionality. I admit that I did have to reorganize some of the original scripts (like moving some pieces into functions so I could easily override it), but on the whole, the original scripts work just like they used to. In fact, I'm actually able to switch back and forth between multiplayer and single player through a menu in the game.

So with that in mind, I decided I would make client-specific versions of the scripts, which would have most of their functionality kept in the original single-player focused scripts. As an example, I had a script class named Unit that stored all of the functionality for each of the units in the game (what happens when they're clicked on, determining where they can move or who they can attack, etc). Then in the "client" folder, I created a script class called ClientUnit.

In the TGB editor, I created a new multiplayer-focused level, and kept it essentially the same as the single player level, only I changed the classes of the objects to use their client-specific classes, with the superclass pointing to the original class.

Then in the client scripts, I simply override specific functions that need to send information to the server before continuing. For example, I have an AttemptSelectUnit function in the Unit class that determines if a particular unit can be selected, and what happens if it can be selected. In the ClientUnit class, I override this function to send a command to the server requesting permission to be selected. The client is then set into a sort of waiting mode (basically just a boolean that is checked before anymore commands are sent to the server). Once the server has determined that the selection is okay, it then sends its confirmation back to the client. Then the client continues calling functions just like it did before in the single player game.

As for the server, all of the server commands just check the local client's version of the game. I know the checkers tutorial had a different method of doing this (keeping a sort of server copy of the game state separate from the client), but I figured that since the server is all-knowing and the enforcer of truth, it would just make sense to have its local client be the version that it compares against. Because of this, I didn't have to make server-specific versions of any classes. I only needed to create a few server commands.

Once it was time to test out the game (after fixing a few bugs), everything seems to be working smoothly. All that I've explained here may be common knowledge to a lot of you TGB veterans here, but I figured I would post my experiences for anyone else who might be scratching their head on how to pull off having single and multiplayer coexist.

Additionally, I also took a stab at working with the GUI editor. There's not really a lot of documentation on the GUI editor, and so it took a bit of time to determine exactly what I needed. When the player moves a unit, I wanted to have a small menu pop up denoting what the unit can do at that tile (i.e., attack another unit, capture something, or just stand their ground). There are a lot of GUI list controls, pop up boxes, buttons, and every other imaginable thing in TGB. But what I really wanted was a dynamic list of buttons that would be populated by only the buttons that could be used at the time.

Enter GuiStackControl, my new favorite GUI control. You can basically add your buttons to the GuiStackControl (using AddGuiControl), and they'll automatically stack on top of each other (vertically or horizontally, depending on the options you set in the editor). Once you have a GuiStackControl set up, it's basically up to you to just add and remove whatever controls you need to make your list.

For the buttons themselves, they're pretty standard stuff. I wanted a small graphic next to the name of the command on top of a bitmap background. To accomplish this, I create a bitmap button, then create two controls that are children of the button: A simple bitmap control, and a text control. I position the two controls where I want them on the button, and then give them the modeless dialog profile (so I can click through them to the button below).

So while the GUI stuff in TGB is fairly complex, it's extremely powerful and can probably do most everything you need. My suggestion is to just play around with things. I decided to try out the GuiStackControl because the text list control was derived from it (and the text list was the closest to what I needed). Turns out it was exactly what I needed.

That's all for now. I'm starting on the really fun part, which is trying to come up with compelling, and original gameplay based off of this starting template. I've already been playing around with a few things, and I'm pleased to say things are going very well.

So until next time, here's a few screens of the GuiStackControl in action. (P.S.: Sorry about the length of this one.)


Two commands, based on what the unit can do at this tile.


One command, because the unit can't really do much here.