• Home
  • About
  • Games
  • Tools
  • Books
  • Contact

28

May

Configuration, part 2: mapping input keys

Posted by admin  Published in Torque Permalinks

In this tutorial I will explain how to remap input keys using an XML file and a configuration dialog box. First of all, here’s the config dialog. I assume you are familiar with the TGB GUI builder for this.

Most of the action will take place in the listbox under “Keyboard input”, wich is a GuiTextListCtrl object. When the dialog box is opened, the input configuration is read from the config file and put in the list. This is the config section for the keyboard input:

<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes” ?>
<KeyboardSettings>
<Leftkey>left</Leftkey>
<Rightkey>right</Rightkey>
<Upkey>up</Upkey>
<Downkey>down</Downkey>
<Subfire>lcontrol</Subfire>
<Shipfire>lalt</Shipfire>
</KeyboardSettings>

And this piece of TorqueScript will read the settings and put them in the dialog box:

function FillKeylist()
{
//Open config file
%Xml = new ScriptObject()
{
class = “XML”;
};
%Xml.beginRead($ConfigFile);
%Xml.readClassBegin(”KeyboardSettings”);
//Clear and fill list
KeyboardList.clear();
KeyboardList.addRow(0,”Left” TAB %Xml.readField(”Leftkey”),0);
KeyboardList.addRow(1,”Right” TAB %Xml.readField(”Rightkey”),1);
KeyboardList.addRow(2,”Up” TAB %Xml.readField(”Upkey”),2);
KeyboardList.addRow(3,”Down” TAB %Xml.readField(”Downkey”),3);
KeyboardList.addRow(4,”Anti-sub torpedo” TAB %Xml.readField(”Subfire”),4);
KeyboardList.addRow(5,”Anti-ship torpedo” TAB %Xml.readField(”Shipfire”),5);
%Xml.readClassEnd();
%Xml.delete();
}

So now we have a list of input keys, now we need a way to change these. For this, a new dialog box “RemapDialog” is created, wich is opened when the list is double clicked (put canvas.pushDialog(…) in the AltCommand field). The RemapDialog window is a small window wich holds a text label and, most important of all, a GuiInputCtrl object. This is as good as undocumented, so it took me a while to figure out how to use it. The key function here is the “onInputEvent” callback. This is executed whenever an input event takes place. Here’s the code for retrieving the key wich was pressed:

function RemapInput::onInputEvent(%this, %device, %action)
{
//Only respond to keyboard input
if (%device $= “keyboard”)
{
//Close dialog
canvas.popDialog(RemapDialog);
//Remap the keys
RemapInputkeys(%action);
}
}

The %device parameter is used to filter out keyboard input, so the event ignores mouse events. The %action parameter is the key that was pressed. This is a string value wich you can use for the “bindCmd” function. I won’t go into detail about the RemapInputKeys function. What this does is replacing the entry in the input key list and saving it to the configuration file, but those are topics that are well documented (check my previous tutorial for info on reading and writing XML files).
Perhaps I’ll write a small demo project that demonstrates this all, and make it available with the source code so you can experiment with it.

empty

19

May

Configuration, part 1: XML files

Posted by admin  Published in Torque Permalinks

I finally got a system up and running for setting and storing configuration settings. It wasn’t easy, since many of the functions I had to use weren’t exactly very well documented. Everything works now, so here’s a tutorial on how I did it. I’m gonna start with XML files, since that’s what I use to store the settings. I tried using a simple text file first but that was kinda tricky and not very stable; a small glitch could cause the entire game to go into an endless loop, freezing it. I’m not gonna explain what XML files are, there are plenty of websites already that do that. From now on, I’ll assume that you know what they are.
The XML file I used for my settings contains three sections: display, keyboard and joystick settings. Later on a highscore section will probably be added as well. Here’s what the file looks like:

<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes” ?>
<DisplaySettings>
<Width>1440</Width>
<Height>900</Height>
<Fullscreen></Fullscreen>
<Autosize></Autosize>
</DisplaySettings>
<KeyboardSettings>
<Leftkey>left</Leftkey>
<Rightkey>right</Rightkey>
<Upkey>up</Upkey>
<Downkey>down</Downkey>
<Subfire>lcontrol</Subfire>
<Shipfire>lalt</Shipfire>
</KeyboardSettings>
<JoystickSettings>
<Subfire>button0</Subfire>
<Shipfire>button1</Shipfire>
</JoystickSettings>

The name of the file is CustomConfig.xml. Now, before I start explaining how to read and write this file, here’s something very important, especially if you’re using Windows Vista: make sure you have the most recent version of Torque Game Builder! In Vista, the older version (before 1.6) won’t work. This is because of a security feature in Vista that doesn’t allow a program to write to files anywhere on the system (unless you save a document, of course). On XP, you could write to any directory, but on Vista you can only write to the application data directory, wich is hidden in the “Documents and Settings” directory. This article explains everything in detail. Old versions of Torque will attempt to write to the game directory, wich won’t work on Vista. Also, you’ll need to call the setCompanyAndProduct function as soon as possible in your game to make sure you’ll put the config file in a unique location.
Another thing to keep in mind is that while you won’t be able to write to the game directory, you are able to read from it. Torque will first look in the application data directory and if the file isn’t found there, it will go to the game directory. Why is this important? When you distribute the game, you don’t need to copy the config file to the application data directory. Instead, you can leave it in the game directory. The first time your game runs, it will read the settings from the file in the game directory. The first time the player changes one of the settings, it is written automatically to the application data directory.
Okay, enough about the Torque file system, and let’s start coding! Torque contains a class for reading and writing XML files: SimXMLDocument. Unfortunately, this class is mostly undocumented. Fortunately, however, there’s a wrapper class that does everything you need! This class is, conveniently, called “XML” and is located in the common/gameScripts directory of your game, in the file xml.cs. Here’s some sample code on how to use it. It reads the display settings from the file.

%Xml = new ScriptObject() {class = “XML”;};
%Xml.beginRead(ExpandFilename(”~/CustomConfig.xml”));
%Xml.readClassBegin(”DisplaySettings”);
%Width = %Xml.readField(”Width”);
%Height = %Xml.readField(”Height”);
%Fullscreen = %Xml.readField(”Fullscreen”);
%Autosize = %Xml.readField(”Autosize”);
%Xml.readClassEnd();
%Xml.delete();

Here’s how it works. Line 1 creates a ScriptObject instance and assigns the XML class to it. Line 2 opens the configuration file. The ExpandFilename function is necessary to turn the filename into a valid path; you don’t have to worry about the exact path, this happens automatically. Line 3 tells Torque to start reading the DisplaySettings section of the XML document. By sorting the config data into sections, you’ll first of all keep the file easy to read, and second it allows you to use values with the same names in different sections, wich could come in handy in large config files. Lines 4 to 7 read four different settings from the file. The last two lines stop reading the DisplaySettings section and then delete the XML object.
Writing to an XML file happens in more or less the same way. You create an XML object and open the file in the same way, and here’s how you write data:

%Xml.writeClassBegin(”DisplaySettings”);
%Xml.writeField(”Width”,%Width);
%Xml.writeField(”Height”,%Height);
%Xml.writeField(”Fullscreen”,%Fullscreen);
%Xml.writeField(”Autosize”,%Autosize);
%Xml.writeClassEnd();

Pretty much self-explaining. This method can be used to store all kinds of data in an XML-style format. I used it for configuration settings now, but it can also be used, for example, for custom level builders. The possibilities are unlimited.
In the next tutorial, I will explain how to remap input keys.

1

9

Feb

Naming conventions

Posted by admin  Published in Torque Permalinks

Without proper formatting and decent naming conventions, programming code can become incredibly confusing. And, of course, this is starting to happen to me all over again. A particularly annoying problem in Torque occurs when you use the same name for several things. It has happened a few times before that I used the same same for a sprite and a code class. You don’t get any error messages when you compile, but it can lead to very unpredictable behaviour. That’s why I decided to design a system for naming all the stuff that goes in a game. Not only will it prevent things like this from happening, it will also make it more obvious what a certian thing exactly is.
First of all, there are sprites and animations. For making everything a bit easier, I consider them the same thing. In Torque, a sprite is an image wich contains one or more frames. Even a sprite with multiple frames is still considered a static sprite. Only when you use a sprite with multiple frames to create an animation object, the animation will play. The naming convention I will use for sprites is this:

spr_*_(S,M,A)

What the hell does this mean? The name will always start with “spr_”, so I know it’s a sprite, followed by the name of the image file. After that, an S is placed for a static sprite (single or multiple frame), M for a multiple frame sprite that is used for an animation and A for an animation. Example: I have an image file named “player.png”, wich contains a set of frames for an animated player sprite. The sprite object will be named “spr_player_M”, and the animation object will be named “spr_player_A”.
Next, sounds. For me, there are two types of sounds: sound effects and background music. Similar approach here:

snd_*_(E,M)

That’s “snd_” for sound object, the name of the sound file and E or M for effect or music.
Finally, there’s a whole bunch of object types that use a more or less similar system. These are classes, particle effects, tilemaps and triggers. Here’s the naming convention for those:

class: cls_*
particle effect: pfx_*
tilemap: tmp_*
trigger: trg_*

So that’s my naming system in a nutshell. For local variables, it doesn’t really matter what you call them, since you only use them in a small piece of code. I’ll probably come up with more rules later, so updates will follow.

empty

23

Oct

Creating a resolution independent status panel

Posted by admin  Published in Torque Permalinks

The status panel I created for Wasabi Defense required a bit of coding for making it resolution independent. The problem with Torque is that the level builder and GUI builder use different coördinate systems. The level builder uses world coördinates. These aren’t affected by the screen resolution and have, by default, the origin placed in the center of the screen. The GUI builder, however, uses window coördinates. This means the origin is placed in the top left of the screen, and this system is pretty much the same system Windows uses for window coördinates and is not resolution independent. If you develop a game that allows players to adjust the resolution and aspect ratio of the screen, you need to do some coding to work around this problem.
First of all, the background panel image. The actual GUI you see on the screenshots is actually only the green text; the metal panel with the inset displays isn’t really a part of the GUI. It’s just a static sprite that’s part of the level, so it automatically adapts to the resolution and I don’t have to worry about that one. The GUI is just a set of text fields that floats on top of the panel. To adjust this to the resolution, we need to do two things: move it to the correct position and adjust the font size. This tutorials assumes you are familiar with the GUI builder and know how to make text fields and assign profiles to them.
Let’s start with positioning the text. In short, this means determining the world coördinates where you want the text field to appear and calculating the window coördinates for them. The text field in the screenshots is placed at -160,475 in world coördinates. This needs to be converted to window coördinates, like this:

%XPos = mFloor(getWord(sceneWindow2D.
getWindowPoint(-160,475),0));
%YPos = mFloor(getWord(sceneWindow2D.
getWindowPoint(-160,475),1));
%Pos = “0 0″;
%Pos = setWord(%Pos,0,%XPos);
%Pos = setWord(%Pos,1,%YPos);
MessageText.Position = %Pos;

The first two lines convert the world coördinates to window coördinates for the current resolution. Next, an empty string is initialized and the coördinates are stored in it. Finally, the position of the text field is adjusted. Step number two is adjusting the size of the field.

%Width = mFloor(getWord(sceneWindow2D.
getWindowPoint(160,475),0) -
getWord(sceneWindow2D.getWindowPoint(-160,475),0));

%Height = mFloor(getWord(sceneWindow2D.
getWindowPoint(160,515),1) -
getWord(sceneWindow2D.getWindowPoint(-160,475),1));

%Size = “0 0″;
%Size = setWord(%Size,0,%Width);
%Size = setWord(%Size,1,%Height);
MessageText.Extent = %Size;

Pretty much the same approach as setting the position. You calculate the window coördinates for the top left and bottom right position and subtract them to get the size in window coördinate units.
The final step is adjusting the font size. The way I did it is probably not the most efficient and elegant way, but it works perfectly. If anyone knows a better way to do this, and I’m sure there is one, please let me know. When I started creating the GUI, I used a design resolution of 1024×768 pixels and set the font size of the text field to 28 points. This means that rougly every 55 pixels of screen height corresponds to a font size point. I created a series of GUI profiles for each font size and then checked the screen height to figure out wich size I had to use. Here’s a sample of the code:

%Screenheight = getWord(sceneWindow2D.getWindowExtents(),3);
if (%Screenheight <= 2030) %TextObject.Profile = “GuiGreenCenter74″;
if (%Screenheight <= 1975) %TextObject.Profile = “GuiGreenCenter72″;
if (%Screenheight <= 1920) %TextObject.Profile = “GuiGreenCenter70″;
if (%Screenheight <= 1865) %TextObject.Profile = “GuiGreenCenter68″;
if (%Screenheight <= 1810) %TextObject.Profile = “GuiGreenCenter66″;
if (%Screenheight <= 1755) %TextObject.Profile = “GuiGreenCenter64″;
if (%Screenheight <= 1701) %TextObject.Profile = “GuiGreenCenter62″;
if (%Screenheight <= 1646) %TextObject.Profile = “GuiGreenCenter60″;
if (%Screenheight <= 1591) %TextObject.Profile = “GuiGreenCenter58″;
if (%Screenheight <= 1536) %TextObject.Profile = “GuiGreenCenter56″;
if (%Screenheight <= 1481) %TextObject.Profile = “GuiGreenCenter54″;
if (%Screenheight <= 1426) %TextObject.Profile = “GuiGreenCenter52″;
if (%Screenheight <= 1371) %TextObject.Profile = “GuiGreenCenter50″;
if (%Screenheight <= 1317) %TextObject.Profile = “GuiGreenCenter48″;
if (%Screenheight <= 1262) %TextObject.Profile = “GuiGreenCenter46″;
if (%Screenheight <= 1207) %TextObject.Profile = “GuiGreenCenter44″;
if (%Screenheight <= 1152) %TextObject.Profile = “GuiGreenCenter42″;
if (%Screenheight <= 1097) %TextObject.Profile = “GuiGreenCenter40″;
if (%Screenheight <= 1042) %TextObject.Profile = “GuiGreenCenter38″;
if (%Screenheight <= 987) %TextObject.Profile = “GuiGreenCenter36″;
if (%Screenheight <= 933) %TextObject.Profile = “GuiGreenCenter34″;
if (%Screenheight <= 878) %TextObject.Profile = “GuiGreenCenter32″;
if (%Screenheight <= 823) %TextObject.Profile = “GuiGreenCenter30″;
if (%Screenheight <= 768) %TextObject.Profile = “GuiGreenCenter28″;
if (%Screenheight <= 713) %TextObject.Profile = “GuiGreenCenter26″;
if (%Screenheight <= 658) %TextObject.Profile = “GuiGreenCenter24″;
if (%Screenheight <= 603) %TextObject.Profile = “GuiGreenCenter22″;

This will have to be repeated for every text field I have, and the panel will eventually have seven of them. Like I said, not the most elegant solution but it works. And it’s executed only once so it won’t slow down the game.

empty

2

Sep

Changing the application icon

Posted by admin  Published in Torque Permalinks

When you have made a game with Torque Game Builder and have built the package, you’ll notice that the executable file has the same icon as Torque Game Builder itself. If you want to change this, you will need the source code, wich comes with the professional version. Of course, it’s kinda silly to spend money on that if all you want to do is changing the icon (not to mention that you’ll also need Visual C++). Luckily, there are other ways to accomplish this.
The tool you will need for this is Resource Hacker. With this application, you can view and edit resources in executable files. Now, what are resources? Resources are data like cursors, string tables, menus, and of course, icons. The feature we will use here is replacing an icon in an executable. It’s very easy. You just open the .exe file in the program, select the icon you want to replace (in this case, there’s only one) and select “Replace Icon” from the “Action” menu. Now you can replace it with any .ico file. If you need a tool to create icons, just do a Google search; there are many thousands out there.

empty
Next Page »
  • feed
  • techorati
Videogame Biscuit at Blogged

Categories

  • Game Design (8)
  • Games (67)
    • Gridblaster (20)
    • Sub Commander (11)
    • Wasabi Defense (36)
  • Geek world (3)
  • Miscellanious (11)
  • Reviews (16)
    • Books (6)
    • Tools (10)
  • Tutorials (20)
    • Gimp (7)
    • Particles (5)
    • Torque (6)
    • Websites (2)

Archives

  • August 2008 (1)
  • July 2008 (7)
  • June 2008 (5)
  • May 2008 (6)
  • April 2008 (8)
  • March 2008 (8)
  • February 2008 (9)
  • January 2008 (11)
  • December 2007 (8)
  • November 2007 (4)
  • October 2007 (8)
  • September 2007 (9)
  • August 2007 (11)
  • July 2007 (12)
  • June 2007 (18)

Blogroll

  • 2D Boy
  • A digital Sailor’s Diary
  • Andrew Wooldridge dot com
  • Bottomless Pit Games
  • Game Focus
  • Game Matters
  • Game Producer
  • Gamedev Blog
  • Gamedev Mike
  • Gamedev Planet
  • Games From Within
  • Hex Studio
  • Indie Madness
  • Jacob Santos
  • Joshua Smyth
  • Lightworks Games
  • Lost Garden
  • Making Casual Games
  • Mr Phil makes games
  • Nerfbat
  • Psychochild’s Blog
  • Qatfish
  • Shotbeak Games
  • Starlit Sky Games
  • Steve Healy Games
  • Tales of the Rampant Coyote
  • Wiering Software

Recommended books

Meta

  • Log in
  • Main Entries Rss
  • Comments Rss
  • XFN Network
  • Wordpress

Sponsored by cheap web hosting || Swarovski Rhinestones || Funny Pictures

Videogame Biscuit is proudly powered by WordPress

Protected Under Creative Commons Licensed

Valid XHTML || Valid CSS || Feed me!