Blade Edge

Transposed from Gaiiden’s Scroll

Aye caramba, another marathon coding session. I’ve been at it since close to midnight, so I think I can safely log 5 hours tonight. I was hoping to get the Mini Conquest menu and the Game Settings menu working, but I’ve only managed to get the Mini Conquest menu done, though that was the bigger task of the two. Much bigger.

Before I get into the menu I should note that I updated the database. Here’s the new file. This isn’t a significant update, I made some minor changes to help improve the readability of my code. You’ll notice that now every record has the fields in the same order. This is because I now have enums defined in script

$TEXT_FIELD  = 0;
$VALUE_FIELD = 1;
$DATA_FIELD  = 2;
$DESC_FIELD  = 3;

I use these when accessing data from a TorqueDB record. Beforehand I would do

%tempData = TorqueDB.searchByInstanceWithClass("class name", "field", %fieldValue);
lblSomeLabel.setText(%tempData.contents[0]);
$gameData.data = %tempData.contents[2];

Now I do

%tempData = TorqueDB.searchByInstanceWithClass("class name", "field", %fieldValue);
lblSomeLabel.setText(%tempData.contents[$TEXT_FIELD]);
$gameData.data = %tempData.contents[$DATA_FIELD];

It’s a minor change but it greatly improves code readability. Now I can come back to it and not have to wonder which field I was extracting data from. Working the other way, I don’t have to remember the index number of each field when I’m programming it.

So onto the menu. I made a lot of improvements in code from the menus I built for our other title Blitz Blox (which I halted work on since it needs real-time networking and T2D currently only has support for turn-based networking. BB is a real-time game, GC is a turn-based game). There are three main areas to note.

No more disabled buttons

In the BB menus, when you reached the end of the available options for that menu item the button would disable itslef, and you’d have to click back using the other button (< and > buttons). This was rather tedious because for every button click I had to check whether I had hit the end, and then disable the button as well as check to see if the other button was disabled, and enable it once the user started clicking back the other way. In GC’s menus when you reach the end of the options it just simply wraps around to the beginning. You can click on just one arrow and cycle through the options as many times as you want, and then go back the other way with the other arrow. It’s also nicer just from a UI perpective, because now to get to the last option from the first one, you can just click once on the left arrow and be there rather than click 4 or 6 or more times on the right arrow to get there.

No more functions for each button

In BB’s menus, each button’s command field would point to an individual function, like targetScoreLeft(); and targetScoreRight(); I started doing this for GC but quickly came to my senses after the first button pair. Why have two functions when you can just have one? I think my decision to not disable buttons also led towards this insight, since it removed some code from each function and let me better see how to combine the two. Now each button pair has a single function with a parameter to determine which button was pressed

So here is a single function used by the buttons that cycle through the game music selection. The left button calls gameMusic($BUTTON_LEFT); and the right button calls gameMusic($BUTTON_RIGHT);. Here also at the end you can see the practical application of TorqueDB for GUI use, where I use it to update text labels.

eval() is my friend

Another thing that saved me an umpteen amount time and equal lines of code is the eval() function. This handy-dandy little feller takes a mix of variables and expressions and evealuates it as a single line of code. I dunno if that explains it all that well so here’s a fitting example

This is the function that changes the labels and values for each player controller. That’s right, this one function is called by eight buttons from four players. The left button from player 1 would call it playerController($BUTTON_LEFT, 1); whereas the right button from player 3 would call it playerController($BUTTON_RIGHT, 3);. This means I have three functions that control the player menu options instead of twelve. hell if I hadn’t decided to combine each button pair into a single function it would have been TWENTY-FOUR. Well holy crap, when you put it that way…

The one thing I didn’t do right… yet

Despite all my wonderful accomplishments for the night there is one thing I have yet to fix. If you’ll look back up at the gameMusic() function and check the code for where I wrap from one end to the other, you’ll notice I’m using static integers. *shudder*. I tried for half an hour to figure out how to get the size of a record so that I can dynamically check for the end of available options. So right now if I were to add a music track to the database I would have to edit this function to have it pick up that new entry. I’ll be posting a question about that on the GG boards before bed tho.

Coming up next

Well like I said, I was hoping to get the Settings menu done as well but I still haven’t hit my stride programming in TorqueScript/T2D. I find myself referencing the documentation for both quite often still, but I’m getting better. So tomorrow I hope to get the Settings menu done. After that my next step will be planning out how to use T2D’s tile editor as a base for GC’s map editor and to start building maps I can use to play a game on.

Ah well, I suppose I can indulge myself with a few hours of sleep now. Till next time….

Oh yea I had told myself earlier that I was going to read other ppl’s journals tonight before posting mine but… yea… kinda too late for that so sorry 😛 Hope to catch up with some of you next time!

Transposed from Gaiiden’s Scroll

Sweet, a solid 5 hours of work and I’ve completed all the tasks I listed in my previous entry. The three bugs and the first three tasks took me only an hour to get through. I was right about the first bug – the code I was using to determine if the mouse had been clicked on the map was buggy. I was doing

%tile = $gameMap.map.getTileLayer($TILE_SYSTEMS_LAYER).pickTile(%worldPosition);
if(%tile)
	$gameMap.addPlanet(%tile, %type);

Therefore if %tile were to equal “0 0” or “0 1”, which is the first column of the map, the statement would evaluate to false. Henceforth

%tile = $gameMap.map.getTileLayer($TILE_SYSTEMS_LAYER).pickTile(%worldPosition);
if(%tile !$= "")
	$gameMap.addPlanet(%tile, %type);

This is the way it should be done to properly evaluate a bad return to %tile.

The second bug was also a stupid n00b mistake. When I went to store the ring count I did

setWord(%tileInfo, $TILE_INFO_RING_COUNT, %ringCount);

BZZZZZZTTTT!!! Wrong-o. I assumed that setWord would take %tileInfo and modify it within the function. Stupid me never realized that – hey, this is a local variable I’m passing in. How the hell is it supposed to be modified? It wasn’t until I looked it up in the docs and saw it used in an example that I slapped my head and groaned. Here’s the way it should be done

%tileInfo = setWord(%tileInfo, $TILE_INFO_RING_COUNT, %ringCount);

Simple fix, stupid bug. But such is the case with most bugs…

The third bug took a bit longer to track down than the other two but it was a simple fix as well. I was just passing the wrong variable to a function. That’s what you get when you name variables %type and %tileType and keep forgetting which is which.

After running through the first two tasks (as I thought, task #3 was solved with the bug fixes) working out how I was going to do the territory shading and implementing it took up the majority of my time today. I had already set up the map with a layer beneath the systems for setting shaded tiles, so it was just a matter of adding the tiles and the interface with which to do it. I managed to keep it all in a single function, GameMap::setTileTerritory. The sole purpose of this function is to add a shade of the proper color beneath a planet or special system. Here are the results:

Placing a planet on the map creates a territory shade beneath the planet as well as the 4 adjacent squares. This is what happens in -game, which is why the extra territories don’t have any systems automatically created for them

Here we’ve selected the empty system brush and filled in the territory. If we hadn’t done this, upon loading the map in the game those territories would have existed, but since no empty systems were created, they wouldn’t have been shown

Holding the Ctrl key you can left-click to add more territories of a selected planet color, or right-click to remove territories of any color. You can’t, however, remove a territory if a planet still occupies that system. The empty systems were also added manually, Ctrl-left-click only adds the shade, you’ll see why later

Pretty! Here’s a map with all 5 planets placed and their territories defined. Since there are only 4 players per game, any fifth planet is treated as a neutral player. Also, not all the tiles in the map need to be assigned a territory as they are here

Finally, here’s some special systems thrown on for some spice. Notice how the territory shade remains? Yes, players can control special systems in their territory, which is why Ctrl-click only adds and removes the shade.

Well, that does it for me today. My ToDo list for tomorrow:

1. Implement the Clear Map and Fill Map buttons
2. Implement brush shapes
3. Modify bottom editor panel – shrink it width-wise to remove all that empty space between Map Sizes and Map Name from some removed features
4. Remove the New Map button. New maps are now created by selecting a new map size
5. Implement map saves
6. Implement map loads
7. Implement help text

If I can get that all done tomorrow I will have finished the map editor!!

Until tomorrow…