Differences

This shows you the differences between the selected revision and the current
version of the page.


wmebook:ch11 2007/12/10 20:51 wmebook:ch11 2008/01/10 14:21 current
Line 1: Line 1:
======  11. Packages and packaging system ====== ======  11. Packages and packaging system ======
-We've already briefly experience packages at work when we tried to compile packages in the Project Manager (key F7) //(id you haven't tried it yet, do it NOW!)// Back then everything our game produced was a folder with 3 files - data.dcp, game.exe, and settings.exe. While both exe files are from wme engine itself, data.dcp is the actual game. +We've already briefly experienced packages at work when we tried to compile packages in the Project Manager (key F7) //(id you haven't tried it yet, do it NOW!)// Back then everything our game produced was a folder with 3 files - data.dcp, game.exe, and settings.exe. While both exe files are from wme engine itself, data.dcp is the actual game.
We've already touched a subject of referrencing files for our game without the **data** so instead of //data\scenes\Circle\Circle.scene// we've simply written **scenes\Circle\Circle.scene**. This is because WME looks into contents of **ALL** packages as if they were copied into one big virtual directory. Well it's not exactly that, because you can set priority to packages too, but let's start from the begining. We've already touched a subject of referrencing files for our game without the **data** so instead of //data\scenes\Circle\Circle.scene// we've simply written **scenes\Circle\Circle.scene**. This is because WME looks into contents of **ALL** packages as if they were copied into one big virtual directory. Well it's not exactly that, because you can set priority to packages too, but let's start from the begining.
Line 19: Line 19:
There are 4 great uses: There are 4 great uses:
-  - Order. By splitting your files into packages it's much easier to orientate where is what. +  - **Order**. By splitting your files into packages it's much easier to orientate where is what. 
-  - Distribution. Code package is usually much smaller then gfx or voiceovers / sounds / music / video. If split separately you don't need to send all the time around the huge ammount of data. +  - **Distribution**. Code package is usually much smaller then gfx or voiceovers / sounds / music / video. If split separately you don't need to send all the time around the huge ammount of data. 
-  - Localization. By changing language specific contents you can very fast localize the game into any language overwriting only the necessary contents. +  - **Localization**. By changing language specific contents you can very fast localize the game into any language overwriting only the necessary contents. 
-  - Patches. Excellent support for bug correcting. You send around only changed files and not huge packages.+  - **Patches**. Excellent support for bug correcting. You send around only changed files and not huge packages.
We know that the first two are easily done by simply splitting the contents into more folders, but how does one go with creating patches? The "virtual directory" would just take the first of files referrenced by name (thus we must keep our filenames unique! //data\hello.ogg// and //audio\hello.ogg// would result into game bug!) We know that the first two are easily done by simply splitting the contents into more folders, but how does one go with creating patches? The "virtual directory" would just take the first of files referrenced by name (thus we must keep our filenames unique! //data\hello.ogg// and //audio\hello.ogg// would result into game bug!)
Line 30: Line 30:
{{wmebook:ch11_2.jpg|}} {{wmebook:ch11_2.jpg|}}
-The priority is a number and higher number you issue, the bigger priority will be set.+The priority is a number and higher number you issue, the bigger priority will be set. Let's test it in action. Create in the top level structure a folder called **patch**. Promote it to package and set its priority to 1. Then create inside this folder structure: **scenes\Street\scr\** and copy inside the **scene_init.script** from the Street folder.  
 + 
 +Open the file in the patch folder and modify the last condition there to read: 
 + 
 +<code script> 
 +if(!StateStreet.Visited) 
 +
 +  StateStreet.Visited = true; 
 + Game.PlayMusicChannel(1,"music\voyages.ogg",true); 
 + Game.SetMusicChannelVolume(1,50); 
 + Game.MusicCrossfade(0,1,6000); 
 +  
 + actor.Talk("Finally there!"); // this is new line 
 +
 +</code> 
 + 
 +Run the game and you'll see that the new line already is in action. Very cool isn't it? Imagine that through package structure you can replace any script, graphic or sound you like. It sounds too good to be true and actually is. There's a big catch and this catch are saved games. Saved games contains the actual version of running scripts (thus attached to scene and game) so they don't get affected by the patch. While scripts attached to Scene are easily reattachable by leaving the room and returning back, global scripts are not influenced for the savegames and developers have to probably in the on "LoadGame" event try to solve it somehow. As it's a very complicated matter and affects a main design issues I'll leave it out of this book's scope. It'll sure help to have some global reattach scripts method.  
 + 
 +Last news is a good news. In the latest WME version it's possible to compile individual package. Imagine you have 2MB big package of scripts and 2GB big package of resources. You don't need to compile everything now, simply right click the package in question and choose **Compile this package** to update the package in question. This clearly simplifies and speeds up the work and it's a main reason for splitting your resources into various packages. 
 
wmebook/ch11.1197316294.txt.gz · Last modified: 2007/12/10 20:51 by metamorphium
Recent changes RSS feed Creative Commons License Driven by DokuWiki