Discussion on converting 1.1.3 projects to 1.5
by Stephen Zepp · in Torque Game Builder · 07/11/2007 (9:04 am) · 16 replies
I thought this was important enough to make it's own thread:
As most GG members are aware, we make every effort to be as backwards compatible as possible when we release a new upgrade to an existing product, but I need to make it clear that sometimes it's one of those "you can't get there from here easily" requirements.
Specifically, there are three major changes made in 1.5 that will make a transition from 1.1.3 to 1.5 (especially for existing projects that are "migrating" to the new release) anywhere from somewhat trivial to rather hard, depending on how your 1.1.3 project is designed.
--Torque Game Builder Editors and Torque Game Builder Game executables are now separated. This actually solves a host of workflow issues that have been reported repeatedly in the past, not the least of which is "stale vs new TorqueScript code" confusion. Basically, every time you go from the Level Builder to running your game level (normally with the "Play Level" button, but also with Torsion), it will now minimize the Level Builder application, and run a fresh version of the Game Builder application, using your most recently saved data.
This has two impacts as far as I've seen at least:
----You no longer use Torsion to run the level builder. The built in Torsion project file created when you create a new project runs the game executable directly (see Getting Torsion to run with 1.5 for more info)
----Gameplay that changes your levels (destroying objects, creating new objects, etc) no longer affects your saved level--when you end your game, the game application is closed down completely, and the level builder application is brought back to focus with the saved level as it existed before you executed your game.
--Torque Game Builder now uses fixed tick physics (the way TGE and TGE-A do). This was done for a host of reasons (physics accuracy being a big one), and could have a fundamental impact to how your game project runs.
Specifically, projects that were heavily dependent on manual physics implementations (based on ::onUpdateScene() or other techniques) may require anywhere from basic to extensive re-design to use tick based physics properly. It's a fundamentally different design between fixed tick based and variable tick based (which is basically what previous versions of TGB allowed), and again depending on your game design, the transition may require re-design of your game mechanics. Your mileage may very, and it's almost impossible to predict how a particular implementation may be affected, but realize that this is one of the key differences if your migrated project isn't working as you might expect.
(cont next post).
As most GG members are aware, we make every effort to be as backwards compatible as possible when we release a new upgrade to an existing product, but I need to make it clear that sometimes it's one of those "you can't get there from here easily" requirements.
Specifically, there are three major changes made in 1.5 that will make a transition from 1.1.3 to 1.5 (especially for existing projects that are "migrating" to the new release) anywhere from somewhat trivial to rather hard, depending on how your 1.1.3 project is designed.
--Torque Game Builder Editors and Torque Game Builder Game executables are now separated. This actually solves a host of workflow issues that have been reported repeatedly in the past, not the least of which is "stale vs new TorqueScript code" confusion. Basically, every time you go from the Level Builder to running your game level (normally with the "Play Level" button, but also with Torsion), it will now minimize the Level Builder application, and run a fresh version of the Game Builder application, using your most recently saved data.
This has two impacts as far as I've seen at least:
----You no longer use Torsion to run the level builder. The built in Torsion project file created when you create a new project runs the game executable directly (see Getting Torsion to run with 1.5 for more info)
----Gameplay that changes your levels (destroying objects, creating new objects, etc) no longer affects your saved level--when you end your game, the game application is closed down completely, and the level builder application is brought back to focus with the saved level as it existed before you executed your game.
--Torque Game Builder now uses fixed tick physics (the way TGE and TGE-A do). This was done for a host of reasons (physics accuracy being a big one), and could have a fundamental impact to how your game project runs.
Specifically, projects that were heavily dependent on manual physics implementations (based on ::onUpdateScene() or other techniques) may require anywhere from basic to extensive re-design to use tick based physics properly. It's a fundamentally different design between fixed tick based and variable tick based (which is basically what previous versions of TGB allowed), and again depending on your game design, the transition may require re-design of your game mechanics. Your mileage may very, and it's almost impossible to predict how a particular implementation may be affected, but realize that this is one of the key differences if your migrated project isn't working as you might expect.
(cont next post).
#2
07/11/2007 (10:45 am)
Thanks for taking the time to explain this Stephen. Users of TGB, I would be interested in hearing how transitioning from 113 to 150 goes for you in your projects.
#3
I would like to keep this one specific to the 3 topics discussed above, so we don't get a mega-thread (hundreds and hundreds of posts on mixed topics) created.
Thanks :)
07/11/2007 (5:47 pm)
As I mentioned above, please post specific migration related issues (such as dropping in projects) in new threads :)I would like to keep this one specific to the 3 topics discussed above, so we don't get a mega-thread (hundreds and hundreds of posts on mixed topics) created.
Thanks :)
#4
07/11/2007 (9:41 pm)
I definitely got a notable slowdown after converting to 1.5. What exactly is a "manual" physics implementation? I only use ::onUpdateScene() for the camera zoom/movement. Does the fact that I wrote my own ::onCollision() functions relate to the issue, or am I totally off-base? 
#5
07/12/2007 (2:51 am)
The main change is that most stuff now is done on a per tick base so if you do it on a per render base, you most likely do an "over processing"
#6
07/12/2007 (7:24 am)
I used Beta 3 for a bit. I found that after minimizing the editor to run the game I ended up with two executables, each trying to hog my processor. I have integrated video so I realize my performance was going to be poor. The way to fix it was to restore the editor and then minimize it again. Was this addressed in the release?
#7
To expand on this further, the major difference between a fixed tick and a variable tick is the number of ticks you will receive over a given period of time. If your code is "tweaked" (timing wise) to provide a certain feel of speed/flow of game at your (hypothetical) FPS of, say, 60, that means that you probably wrote your code with a hidden assumption of 60 ticks per second. With the new tick based system, you are going to get a fixed rate of 30 ticks per second, which, assuming you did in fact have the hidden assumption of tick rate, will give the appearance that you have a "notable slowdown".
This is the "fundamental design difference" I mention in my first post, and yes, we do understand it can be painful in some cases to re-design with fixed ticks in mind. The biggest advantage in a fixed tick system however is that regardless of the cpu or video card performance (within reasonable limits of course), your game play, when designed against a fixed tick system, is going to be much more consistent across different hardware, and even different operating systems.
07/12/2007 (9:43 am)
Quote:
The main change is that most stuff now is done on a per tick base so if you do it on a per render base, you most likely do an "over processing"
To expand on this further, the major difference between a fixed tick and a variable tick is the number of ticks you will receive over a given period of time. If your code is "tweaked" (timing wise) to provide a certain feel of speed/flow of game at your (hypothetical) FPS of, say, 60, that means that you probably wrote your code with a hidden assumption of 60 ticks per second. With the new tick based system, you are going to get a fixed rate of 30 ticks per second, which, assuming you did in fact have the hidden assumption of tick rate, will give the appearance that you have a "notable slowdown".
This is the "fundamental design difference" I mention in my first post, and yes, we do understand it can be painful in some cases to re-design with fixed ticks in mind. The biggest advantage in a fixed tick system however is that regardless of the cpu or video card performance (within reasonable limits of course), your game play, when designed against a fixed tick system, is going to be much more consistent across different hardware, and even different operating systems.
#8
07/12/2007 (5:46 pm)
Hmm... well that's possibly it, I'm not sure. I was a little vague using the term "slowdown." In reality, things are moving at the same rate in terms of pixels/second of an object moving across the screen. It's just now very choppy and the video quality is blurry. Odd indeed. But since it doesn't sound like this is a related problem, I'll open up a new thread if/when I decide to commit to 1.5. The new physics consistency sounds nice though.
#9
There is a longer thread on this kind of problems when porting 1.1.3 to 1.5 by benjamin grauer I think
07/13/2007 (1:13 am)
The choppy happens if you used movement commands an the like in the update callback for example.There is a longer thread on this kind of problems when porting 1.1.3 to 1.5 by benjamin grauer I think
#10
07/17/2007 (5:24 pm)
Am I missing something simple? How do I actually open my 1.1.3 project in 1.5? 
#11
Open TGB1.5 and create a new project with the same name as your 1.1.3 project, save it in my documents/my games/gamename and check the box for 'copy the .exe to the game folder'
Shut down TGB, then in explorer grab all the gamescripts from your 1.1.3 game and copy them to my documents/my games/ganename/game/gameScripts
Then copy all your data (images, audio, particles etc...) into the my documents/my games/gamename/game/data folders.
Next copy the script files in your 1.1.3 managed folder into my documents/my games/gamename/game/managed and edit the datablocks.cs - you will need to change the paths for your images to ~/data/images/imagename.jpg
I'm writing this from memory so I hope I haven't left anything out, but that's basically it for a simple game - that's all I had to do to get one of my 1.1.3 games across.
07/18/2007 (12:35 am)
Warthog:Open TGB1.5 and create a new project with the same name as your 1.1.3 project, save it in my documents/my games/gamename and check the box for 'copy the .exe to the game folder'
Shut down TGB, then in explorer grab all the gamescripts from your 1.1.3 game and copy them to my documents/my games/ganename/game/gameScripts
Then copy all your data (images, audio, particles etc...) into the my documents/my games/gamename/game/data folders.
Next copy the script files in your 1.1.3 managed folder into my documents/my games/gamename/game/managed and edit the datablocks.cs - you will need to change the paths for your images to ~/data/images/imagename.jpg
I'm writing this from memory so I hope I haven't left anything out, but that's basically it for a simple game - that's all I had to do to get one of my 1.1.3 games across.
#12
07/18/2007 (3:39 am)
It's almost it, though setting the folder in "documents/my games/" is not a necessity. Also it's simply all your mod folder that is needed t be copied over. And you need to rename the path not only in datablocks.cs, but in all your script, gui and t2d ^^'Quote:Create a new project under 1.5. Then, take your 1.3 mod folder, rename it "game" and put it in the new 1.5 project (replacing the "game" mod folder), within the game scripts you need to change the path names (mainly for datablocks.cs, do it before trying to run TGB because it would mess up your datablocks) since the mod folder is now named "game" in 1.5.
Beware if you do an extensive use of config datablocks (like me), you'll have to rewrite them in "game/gamescripts/datablocks.cs" in order to load them in the editor
#13
I found that this is probably the onUpdate function, correct? I would still like a little more information on how to use it, however.
07/19/2007 (5:53 pm)
I may not be understanding things correctly, but how might one make an event happen every tick (or every so many ticks)?I found that this is probably the onUpdate function, correct? I would still like a little more information on how to use it, however.
#14
07/19/2007 (6:08 pm)
Quote:we now allow for writing to any accessible disk/directoryDoes that me we can create and delete folders now?
#15
$player.enableUpdateCallback()
then you just need to fill in this function:
$player.onUpdate(%this)
{
// code here gets executed every tick (32 miliseconds).
}
07/19/2007 (9:42 pm)
Sean - first you enable the onupdate callback with$player.enableUpdateCallback()
then you just need to fill in this function:
$player.onUpdate(%this)
{
// code here gets executed every tick (32 miliseconds).
}
#16
To prevent the 'slowdown", I need to call the onUpdate() function for individual objects instead of calling "onUpdateScene()", right?
07/27/2007 (2:18 pm)
Just so I understand the tick situation.To prevent the 'slowdown", I need to call the onUpdate() function for individual objects instead of calling "onUpdateScene()", right?
Torque 3D Owner Stephen Zepp
--The final major change is how projects are saved, and where. TGB now allows you the flexibility of saving your work into a "working directory" that can be anywhere in any accessible drive/directory on your system, including removable drives (flash drives, etc). This has been a requested feature for a very long time, and on the surface it sounds obvious, but I feel it's important to understand why the original TGB architecture didn't allow for it, and the concerns you should be aware of now that it does:
The original core Torque technology did not allow any Torque executable to "be aware of" directories outside of it's root location for security purposes. Since the Torque executable was both an editor, and a game executable, and was expected to in some cases serve as an editor at the end user level, security was a big concern--we did not want to allow Torque projects to be able to arbitrarily write to anywhere on the hard drive--that would give hackers and untrusted users the ability to do wild and crazy things like over-writing system files, accessing data they probably shouldn't have access to, etc.
The market asked for the flexibility, and we understood the request and felt it was a good one, so we now allow for writing to any accessible disk/directory--but it's important for you to understand that if you aren't careful, and/or expose the ability for the end user to "mod" your game directly with TorqueScript, the onus is on you as the developer to ensure security. Nothing could be worse in my personal opinion than an unaware indie game developer releasing a game that can be then turned around into a hacking tool for the end users, so please be careful with what capabilities you let your end users have with your game.
If you have any questions about the topics above, please feel free to ask, but if you have specific migration questions, please create a different thread with a title that accurately describes your specific issue.
Enjoy TGB 1.5--a lot of effort has been made to make it the most powerful and flexible TGB ever!