Data File Development Process: Difference between revisions

From HLKitWiki
Jump to navigationJump to search
No edit summary
 
(21 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:Basic Concepts and Terminology]]
{{context|Basic Concepts and Terminology}}
[Context: [[Home|HL Kit]] … [[Basic Concepts and Terminology]]]


==Overview==
==Overview==
Line 8: Line 7:
==Enable Data File Debugging==
==Enable Data File Debugging==


==Data File Compiler==
Before you do anything else, make sure that you've configured HL to enable all of the built-in data file development and debugging aids. By default, HL assumes that users are not creating their own data files, so assorted development facilities within the product are disabled. You need to make sure they are turned on so that you can put them to use.


==Compiling Data Files==
To enable these tools, go to the "Debug" menu within HL and make sure the "Enable Data File Debugging" option is checked. If it's not checked, click on it once to toggle the state.


==Using Quick-Reload==
==Data File Compiler==


==Review the Skeleton Files==
The HL engine includes a compiler that processes all of the data files you create. The benefits of a compiler are two-fold. First of all, the compiler allows HL to convert all of the disparate data files for a game system into a highly optimized version that can be used. This results in significant performance improvements and much lower memory requirements, thereby allowing HL to manage lots of information efficiently on even older, slower computers.


==Take Snapshots Regularly==
The second big advantage of a compiler is that the compilation process vets the data files that you've written. If there are errors in the data files, they can be caught in advance and reported to you, allowing you to fix them. Without a compiler, you wouldn't know if you had an error until you tried doing something that uncovered the error, thereby making it harder to verify that your data files work flawlessly.


==Creating the New Game System==
{{note}}Even though HL uses a compiler, there are some kinds of errors that the compiler simply cannot catch. The vast majority of errors will be caught by the compiler, but some will not. These errors will be trapped and reported as run-time errors, and they are discussed separately in the section on debugging data files.


==Compiling Data Files==


During the course of developing your data files, there will be times where you want to fully test that everything is working the way you want. There will also be times when you simply want to verify that your changes are valid and compile successfully. You can ask HL to re-compile your data files at any time by going to the "Debug" menu and triggering the "Compile Data Files" option. You'll be prompted to specify the game system to re-compile, after which you'll be shown any error messages that might be encountered during the compilation process.


As long as your files fail to compile, they will not load in the HL, so you should get in the habit of frequently re-compiling your data files. This will uncover problems quickly, since the error must exist in whatever changes you've made since the previous successful compile.


----------------------------------------------
As a convenient shortcut, you can use the <Ctrl-C> key combination to invoke a compile. This makes it easy to regularly verify that your data files are valid at each step along the way as you develop them. Please note that the <Ctrl-C> key combination will '''not''' work when the input focus is an edit portal, since the <Ctrl-C> is interpreted as a traditional "Copy" command within an edit portal.


Copy the Skeleton Files
==Using Quick-Reload==


Before you do anything, you need to setup your own copy of the Skeleton data files in a new folder for your game system. Hero Lab can do the basics for you automatically by going to the "Tools" menu and selecting the "Create New Game System" option. Provide the name of the game system and the folder to use, then let Hero Lab set everything up properly. After it's created, you can switch to the new game system to verify it.
Whenever you make changes to your data files, you'll need to load those changes into HL so that you can use and test them. The obvious way to do this is to go to the "File" menu and select "Switch Game System". However, this approach always shows you the release notes for the game system and potentially the "demo mode" warning, after which you'll be shown the "Configure Hero" form for a new character. After a few dozen times, this process gets really old.


Game System Details
To bypass this, HL includes the "Quick Reload" mechanism, which can be invoked by going to the "Debug" menu and selecting the "Quick Reload" option. This mechanism re-compiles the data files, if necessary, and then reloads them into HL, bypassing the extra steps. It also restores the current tab that is selected. As an added bonus, if you have a saved portfolio loaded, your portfolio is also reloaded. This makes it quick and easy to incrementally modify and test out behaviors associated with selected options.


Once the new copy of the Skeleton files is in place, the first step you should take is to modify the definition file for your game system. This entails opening the "definition.def" file and making appropriate changes to a few elements. The "game" element should be assigned appropriate values for each attribute to reflect the game system and its publisher. The "author" element should be assigned attribute values that identify you at the author. The "structure" element should already specify the appropriate default folder for the game system, but it's probably worth double-checking this detail. Once these changes have been made, verify everything is working properly by loading the new game system into Hero Lab.
==Take Snapshots Regularly==


Create the Game System
As you evolve your data files, you will be making significant changes. Even if you are careful, it's likely that you will end up causing everything to break at a few points along the way. When this happens, it can be invaluable to be able to see exactly what has been changed since the last time everything was working fine. In order to do this, you need to have a saved copy of when things were last working. Consequently, we '''strongly''' encourage you to make a complete copy of your data files at regular intervals, preferably at milestones where everything is working the way you want it. We refer to these copies as "snapshots".


The very first step is to create your new game system. Hero Lab can automatically setup a new game system for you, starting you out with a set of data files that you can adapt and build upon. Go to the "Tools" menu within Hero Lab and select the "Create New Game System" option. For this example, we specify the name of the game system as "Savage Worlds" and the folder to use as "savage". Once Hero Lab sets everything up properly, go to the "File" menu, select "Switch Game System", and enter your new game system.
The easiest way to take a snapshot is to use the [[Using the HLExport Tool|HLExport tool]] that is included with the Kit. This tool is designed to package up all of the data files for a game system into a single file that can be easily imported back into HL, and you'll be using this tool to distribute your data files once they're created. In the meantime, though, this tool can also be helpful during development. Using HLExport, you can readily take snapshots of your working data files and save them. If you need to refer back to an old snapshot, you can import the file back into HL and compare the files.  


Review the Skeleton Data Files
{{important}}If you use HLExport as outlined above and need to reload an old snapshot, be sure to import the files into a '''different''' directory from the data files you are developing. Otherwise, the old files you import will overwrite your recent changes!


The framework for your new game system is now setup. Since this framework provides all of the basics you'll need and must simply be fleshed out, we refer to this starting point as the Skeleton data files. Now would be an ideal time to review the manual that comes with the new game system, as it outlines numerous important details about the Skeleton data files and how best to evolve them into a full-fledged game system. As with any game system, you can access the manual by going to the "Help" menu and selecting the "Savage Worlds Manual" option.
Another simple technique is to make a copy of the entire directory contents for your game system. This allows you to do a direct file-to-file comparison of any file at any time, which can be quite handy at times. The only drawback of this approach is that it often requires more effort than the HLExport technique.


You should also take the time to review the contents of the data files themselves and get familiar with them, as you'll begin modifying and adapting them in just a moment.
In general, a combination of both techniques will often yield the best results.


==Skeleton Data Files==


Data File Compiler
To make it as easy as possible to get started writing data files for a new game system, the Kit includes a starting set of data files. These data files aren't just a hodgepodge of examples, though. They are a fully operational foundation that serves as a framework that you can adapt and build upon to create a solution for virtually any game system.


HL compiles the data files you create, allowing it to catch many errors and problems before the data files are even loaded. This section outlines facets of the compiler that are fundamental to writing your own data files.
Since this framework provides all of the basics you'll need and must simply be fleshed out, we refer to this starting point as the Skeleton data files. These data files are minimal in nature, but they offer a solid framework to start with, including a variety of built-in mechanisms that you will likely find yourself using for whatever game system you set out to implement.


Enable Data File Debugging
==Review the Sample Data Files==


Begin by making sure that you've configured Hero Lab to enable the debugging aids. By default, Hero Lab assumes that users are not editing their own data files, so various development facilities within the product are disabled. You need to make sure they are turned on. Go to the "Tools" menu and into the "Data File Debugging" submenu, where you need to turn on the "Enable Data File Debugging" option.
Before you start trying to develop your own data files, you should first spend a little bit of time familiarizing yourself with the Skeleton data files. Since they will form the starting point for your efforts, you'll benefit substantially by understanding how they work. You should also take the time to review the contents of the data files themselves and get familiar with them, as you'll begin modifying and adapting them.  


Compiling Data Files
You can see the Skeleton data files in action by looking at the "Authoring Kit Sample" game system that is installed with HL. If you take a look within the "sample" data file folder, you'll see all of the data files for the game system. Lots of useful insights into the sample data files will be found in the section [[Exploring the Sample Game System]].


During the course of developing your data files, there will be times where you want to fully test that everything is working properly. There will also be times when you simply want to verify that your changes are syntactically valid and compile successfully. You can ask Hero Lab to re-compile your data files at any time by going to the "Tools" menu and into the "Data File Debugging" submenu, where you can invoke the "Compile Data Files" option. You'll be prompted to specify the game system to re-compile, and you'll be shown any error messages that might be encountered during the compilation process.  
The only differences between the Sample game system and the Skeleton data files is that the Sample game system includes an assortment of attributes, skills, abilities, weapons, and whatnot. By including these objects, you can better see how everything works. In contrast, the Skeleton data files omit these objects, since you would otherwise have to delete them before you could begin adding all the material for your own game system.  


As long as your files fail to compile, they will not load in the Hero Lab, so you should get in the habit of frequently re-compiling your data files. This will uncover problems quickly, since the error must exist in whatever changes you've made since the previous successful compile.
Functionality, the two sets of data files are identical. The only difference is that the Sample game system includes a variety of things that you can actually play with.


As a shortcut, you can use the <Ctrl-C> key combination to invoke a compile. This makes it easy to regularly verify that your data files are valid at each step along the way as you develop them. Please note that the <Ctrl-C> key combination will not work when the input focus is a text edit portal (e.g. character name), since the <Ctrl-C> is interpreted as a traditional "Copy" command within a text edit portal.
==Study the Savage Worlds Example==


Using Quick-Reload
In addition to the Skeleton data files, a separate separate set of data files is provided that implements a reasonably sophisticated game system - the Savage Worlds system from Great White Games. The Kit documentation includes a detailed walk-through of how the Skeleton data files were adapted for that game system, guiding you through the entire evolutionary process. This offers a concrete example of how to approach your own project.


Whenever you make changes to your data files, you need to load those changes into Hero Lab so you can use and test them. The simplest way to do this is to go to the "File" menu and select "Switch Game System". However, this approach always shows you the release notes for the game system and potentially the "demo mode" warning, after which you'll be shown the "Configure" form for a new character. After a few dozen times, this gets really old.
When starting on the development of data files for a new game system on your own, you'll be starting out with the Skeleton data files and expanding upon them for your own purposes. It would be extremely helpful to first review how the Skeleton data files evolve into the Savage Worlds data files, as there will likely be many similarities with the evolutionary process for your game system. The [[Savage Worlds Walk-Through]] will also provide insight into how and when to address different steps in the development process that you can leverage within your own project.


So Hero Lab includes the "Quick Reload" mechanism, which can be invoked by going to the "Tools" menu and into the "Data File Debugging" submenu, where you can select the "Quick Reload" option. This mechanism re-compiles the data files, if necessary, and then reloads them into Hero Lab, bypassing the extra steps and restoring the current tab that is selected. As an added bonus, if you have a saved portfolio loaded, your portfolio is reloaded. This makes it quick and easy to incrementally modify and test out behaviors associated with selected options.
==Have a Plan==


Take Snapshots Regularly
When you set out to write your own data files, there is one detail that is more important than virtually anything else: have a plan. It is critical that you first do your homework and map out both how everything will work internally and how it will all work and behave. If you launch into writing your data files without a solid plan, you will almost certainly run into a substantial number of surprises and setbacks along the way. Heck, you'll likely have a fair number of those even if you '''do''' have a good plan in place.


As you evolve your data files, you will be making significant changes. If you aren't extremely careful, it's likely that you will end up causing everything to break at a few points along the way. When this happens, it can be invaluable to be able to see exactly what has been changed since the last time everything was working fine. In order to do this, you need to have a saved copy of when things were last working. So we strongly recommend that you take snapshots of your data files at regular intervals, preferably at milestones where everything is working the way you want it.
While surprises and setbacks won't stop you from ultimately creating your data files, they will almost certainly cause unnecessary delays and frustration. So you will fare best if you take the time upfront to develop your basic implementation strategy, map out all of the structural pieces you'll need, and design how everything should look and behave for the user.


The easiest way to take a snapshot is to use the "HLExport" tool that is included with the Authoring Kit. This tool is designed to package up all of the data files for a game system into a single file that can be imported back into Hero Lab. Using HLExport, you can readily take snapshots of your working data files and save them. If you need to refer back to one, you can import the file back into Hero Lab. However, be sure to import the files into a different directory from your data files, else the imported files will overwrite your recent changes.
From a structural perspective, identify all the major elements of the game system. Figure out what types of objects you'll need, then determine the components and compsets necessary. Anticipate the various game behaviors that you need to properly model and map those into the appropriate fields and tags. Sift through all the facets of the game and you'll likely uncover a lot of subtle details that you'll need to fully implement in your data files. It's amazing how many little details lurk within even the most simple game systems. When it comes time to write data files for the game, you'll need to deal with all of them, so it's much better to create a lengthy laundry list upfront so that you can plan for them and not get hit with lots of surprises along the way.


Another simple technique is to make a copy of the entire directory contents for your game system. This allows you to do a direct file-to-file comparison of any file at any time, which can be quite handy at times. The ideal technique is to use a source control system of some sort, although this is an approach that most users will not have access to. If you don't we recommend using a combination of the other two methods for best results.
For the visuals, figure out all the various pieces that the user needs to manage. An excellent place to start is the character sheet, but don't stop with that. There are often lots of little details that publishers don't include on the character and that would be a great benefit to support in your data files. Figure out how you're going to visually organize everything across and within the various tab panels. Draw sketches of each tab panel that show what pieces are involved on each. Assemble a road map for how everything will hang together and how the user will interact with it all.


Before writing any data files, it's critical that you first do your homework. If you launch into writing the data files without a good plan, you will likely run into a number of surprises and setbacks along the way. While such events won't stop you from successfully creating the data files, they will almost certainly cause unnecessary delays and frustration. So you will fare best if you take the time upfront to develop your basic implementation strategy, map out all of the basic building blocks you'll need, and design how everything should look and behave for the user.
Once you've got the above tasks complete, you're ready to start writing the data files for your game.


Implementation Strategy
==Creating the New Game System==
 
The first thing you need is to figure out how you are going to go about developing your data files. We've provided you with a solid starting point in the User Manual installed with the Skeleton data files. That manual outlines a proven methodology for creating the data files for a new game system. This document you are now reading leverages the outlined strategy for the Savage Worlds game system. You are welcome to come up with your own approach, as there is no "right" way to do it, although we recommend you start with the methodology we've presented and adapt it to suit your needs.
 
Building Blocks
 
?????????????????????????????????????????????????????????????????
 
components and compsets
 
entities
 
things
 
tag groups
 
phases and evaluation cycle
 
Look and Feel
 
?????????????????????????????????????????????????????????????????
 
visual layout and organization
 
interactive behavior - where to use tables, choosers, menus, etc.
 
add scans of original sketches
 
Visual Skins
 
?????????????????????????????????????????????????????????????????


colors
When you're ready to launch into developing your own data files, we've made it as easy as possible to get started. There are a vast number of details involved in getting a set of data files to a critical mass where you can successfully load them and experiment with them. There are a similarly large number of mechanisms that will be useful for just about any game system. The good news is that we've saved you the work of having to do all this, as the Kit includes the Skeleton data files that will let you hit the ground running.


fonts
Creating the framework for a new game system entails only a few mouse clicks. Go to the "Develop" menu and select the "Create New Game System" option. You'll be prompted to enter both the name of the game system and the name of the folder in which to place the data files. Once that's done, HL will set everything up properly for you. After creation, you can immediately switch to your new game system and set it in place, then you're off and running.


graphics - textures, buttons, icons
{{warning}}There are a number of critical implications with the choice of folder name. Please review the list below before selecting the folder.
*Saved portfolios are associated with a game system via the folder assigned. Changing the folder for a game system after the initial release of data files will result in all existing saved portfolios being rendered inaccessible.
*Until the release of your data files to others, you may freely change the folder name within the [[Structure Element (Data)|definition file]], although doing so will invalidate any portfolios you've created thus far.
*Make sure the folder name uniquely identifies the game system. When a user imports the data files, this folder is where the data files will be installed. If two or more game systems use the same folder name, they will overwrite each other.
*The folder name may consist only of alphanumeric characters (i.e. letters and digits). It may not contain any spaces or special characters other than the underscore ('_') and hyphen ('-').

Latest revision as of 09:46, 21 January 2009

Context: HL Kit &#133; Basic Concepts and Terminology 

Overview

Before you dive in and start writing your own data files, there are a number of important aspects to the overall development process that you should be familiar with. The topics below strive to relay some basic knowledge that will be incredibly helpful as you begin the authoring process.

Enable Data File Debugging

Before you do anything else, make sure that you've configured HL to enable all of the built-in data file development and debugging aids. By default, HL assumes that users are not creating their own data files, so assorted development facilities within the product are disabled. You need to make sure they are turned on so that you can put them to use.

To enable these tools, go to the "Debug" menu within HL and make sure the "Enable Data File Debugging" option is checked. If it's not checked, click on it once to toggle the state.

Data File Compiler

The HL engine includes a compiler that processes all of the data files you create. The benefits of a compiler are two-fold. First of all, the compiler allows HL to convert all of the disparate data files for a game system into a highly optimized version that can be used. This results in significant performance improvements and much lower memory requirements, thereby allowing HL to manage lots of information efficiently on even older, slower computers.

The second big advantage of a compiler is that the compilation process vets the data files that you've written. If there are errors in the data files, they can be caught in advance and reported to you, allowing you to fix them. Without a compiler, you wouldn't know if you had an error until you tried doing something that uncovered the error, thereby making it harder to verify that your data files work flawlessly.

NOTE! Even though HL uses a compiler, there are some kinds of errors that the compiler simply cannot catch. The vast majority of errors will be caught by the compiler, but some will not. These errors will be trapped and reported as run-time errors, and they are discussed separately in the section on debugging data files.

Compiling Data Files

During the course of developing your data files, there will be times where you want to fully test that everything is working the way you want. There will also be times when you simply want to verify that your changes are valid and compile successfully. You can ask HL to re-compile your data files at any time by going to the "Debug" menu and triggering the "Compile Data Files" option. You'll be prompted to specify the game system to re-compile, after which you'll be shown any error messages that might be encountered during the compilation process.

As long as your files fail to compile, they will not load in the HL, so you should get in the habit of frequently re-compiling your data files. This will uncover problems quickly, since the error must exist in whatever changes you've made since the previous successful compile.

As a convenient shortcut, you can use the <Ctrl-C> key combination to invoke a compile. This makes it easy to regularly verify that your data files are valid at each step along the way as you develop them. Please note that the <Ctrl-C> key combination will not work when the input focus is an edit portal, since the <Ctrl-C> is interpreted as a traditional "Copy" command within an edit portal.

Using Quick-Reload

Whenever you make changes to your data files, you'll need to load those changes into HL so that you can use and test them. The obvious way to do this is to go to the "File" menu and select "Switch Game System". However, this approach always shows you the release notes for the game system and potentially the "demo mode" warning, after which you'll be shown the "Configure Hero" form for a new character. After a few dozen times, this process gets really old.

To bypass this, HL includes the "Quick Reload" mechanism, which can be invoked by going to the "Debug" menu and selecting the "Quick Reload" option. This mechanism re-compiles the data files, if necessary, and then reloads them into HL, bypassing the extra steps. It also restores the current tab that is selected. As an added bonus, if you have a saved portfolio loaded, your portfolio is also reloaded. This makes it quick and easy to incrementally modify and test out behaviors associated with selected options.

Take Snapshots Regularly

As you evolve your data files, you will be making significant changes. Even if you are careful, it's likely that you will end up causing everything to break at a few points along the way. When this happens, it can be invaluable to be able to see exactly what has been changed since the last time everything was working fine. In order to do this, you need to have a saved copy of when things were last working. Consequently, we strongly encourage you to make a complete copy of your data files at regular intervals, preferably at milestones where everything is working the way you want it. We refer to these copies as "snapshots".

The easiest way to take a snapshot is to use the HLExport tool that is included with the Kit. This tool is designed to package up all of the data files for a game system into a single file that can be easily imported back into HL, and you'll be using this tool to distribute your data files once they're created. In the meantime, though, this tool can also be helpful during development. Using HLExport, you can readily take snapshots of your working data files and save them. If you need to refer back to an old snapshot, you can import the file back into HL and compare the files.

IMPORTANT! If you use HLExport as outlined above and need to reload an old snapshot, be sure to import the files into a different directory from the data files you are developing. Otherwise, the old files you import will overwrite your recent changes!

Another simple technique is to make a copy of the entire directory contents for your game system. This allows you to do a direct file-to-file comparison of any file at any time, which can be quite handy at times. The only drawback of this approach is that it often requires more effort than the HLExport technique.

In general, a combination of both techniques will often yield the best results.

Skeleton Data Files

To make it as easy as possible to get started writing data files for a new game system, the Kit includes a starting set of data files. These data files aren't just a hodgepodge of examples, though. They are a fully operational foundation that serves as a framework that you can adapt and build upon to create a solution for virtually any game system.

Since this framework provides all of the basics you'll need and must simply be fleshed out, we refer to this starting point as the Skeleton data files. These data files are minimal in nature, but they offer a solid framework to start with, including a variety of built-in mechanisms that you will likely find yourself using for whatever game system you set out to implement.

Review the Sample Data Files

Before you start trying to develop your own data files, you should first spend a little bit of time familiarizing yourself with the Skeleton data files. Since they will form the starting point for your efforts, you'll benefit substantially by understanding how they work. You should also take the time to review the contents of the data files themselves and get familiar with them, as you'll begin modifying and adapting them.

You can see the Skeleton data files in action by looking at the "Authoring Kit Sample" game system that is installed with HL. If you take a look within the "sample" data file folder, you'll see all of the data files for the game system. Lots of useful insights into the sample data files will be found in the section Exploring the Sample Game System.

The only differences between the Sample game system and the Skeleton data files is that the Sample game system includes an assortment of attributes, skills, abilities, weapons, and whatnot. By including these objects, you can better see how everything works. In contrast, the Skeleton data files omit these objects, since you would otherwise have to delete them before you could begin adding all the material for your own game system.

Functionality, the two sets of data files are identical. The only difference is that the Sample game system includes a variety of things that you can actually play with.

Study the Savage Worlds Example

In addition to the Skeleton data files, a separate separate set of data files is provided that implements a reasonably sophisticated game system - the Savage Worlds system from Great White Games. The Kit documentation includes a detailed walk-through of how the Skeleton data files were adapted for that game system, guiding you through the entire evolutionary process. This offers a concrete example of how to approach your own project.

When starting on the development of data files for a new game system on your own, you'll be starting out with the Skeleton data files and expanding upon them for your own purposes. It would be extremely helpful to first review how the Skeleton data files evolve into the Savage Worlds data files, as there will likely be many similarities with the evolutionary process for your game system. The Savage Worlds Walk-Through will also provide insight into how and when to address different steps in the development process that you can leverage within your own project.

Have a Plan

When you set out to write your own data files, there is one detail that is more important than virtually anything else: have a plan. It is critical that you first do your homework and map out both how everything will work internally and how it will all work and behave. If you launch into writing your data files without a solid plan, you will almost certainly run into a substantial number of surprises and setbacks along the way. Heck, you'll likely have a fair number of those even if you do have a good plan in place.

While surprises and setbacks won't stop you from ultimately creating your data files, they will almost certainly cause unnecessary delays and frustration. So you will fare best if you take the time upfront to develop your basic implementation strategy, map out all of the structural pieces you'll need, and design how everything should look and behave for the user.

From a structural perspective, identify all the major elements of the game system. Figure out what types of objects you'll need, then determine the components and compsets necessary. Anticipate the various game behaviors that you need to properly model and map those into the appropriate fields and tags. Sift through all the facets of the game and you'll likely uncover a lot of subtle details that you'll need to fully implement in your data files. It's amazing how many little details lurk within even the most simple game systems. When it comes time to write data files for the game, you'll need to deal with all of them, so it's much better to create a lengthy laundry list upfront so that you can plan for them and not get hit with lots of surprises along the way.

For the visuals, figure out all the various pieces that the user needs to manage. An excellent place to start is the character sheet, but don't stop with that. There are often lots of little details that publishers don't include on the character and that would be a great benefit to support in your data files. Figure out how you're going to visually organize everything across and within the various tab panels. Draw sketches of each tab panel that show what pieces are involved on each. Assemble a road map for how everything will hang together and how the user will interact with it all.

Once you've got the above tasks complete, you're ready to start writing the data files for your game.

Creating the New Game System

When you're ready to launch into developing your own data files, we've made it as easy as possible to get started. There are a vast number of details involved in getting a set of data files to a critical mass where you can successfully load them and experiment with them. There are a similarly large number of mechanisms that will be useful for just about any game system. The good news is that we've saved you the work of having to do all this, as the Kit includes the Skeleton data files that will let you hit the ground running.

Creating the framework for a new game system entails only a few mouse clicks. Go to the "Develop" menu and select the "Create New Game System" option. You'll be prompted to enter both the name of the game system and the name of the folder in which to place the data files. Once that's done, HL will set everything up properly for you. After creation, you can immediately switch to your new game system and set it in place, then you're off and running.

WARNING! There are a number of critical implications with the choice of folder name. Please review the list below before selecting the folder.

  • Saved portfolios are associated with a game system via the folder assigned. Changing the folder for a game system after the initial release of data files will result in all existing saved portfolios being rendered inaccessible.
  • Until the release of your data files to others, you may freely change the folder name within the definition file, although doing so will invalidate any portfolios you've created thus far.
  • Make sure the folder name uniquely identifies the game system. When a user imports the data files, this folder is where the data files will be installed. If two or more game systems use the same folder name, they will overwrite each other.
  • The folder name may consist only of alphanumeric characters (i.e. letters and digits). It may not contain any spaces or special characters other than the underscore ('_') and hyphen ('-').