Jump to content

Release project [ preparing a package from an blanc template ]


Recommended Posts

Hello,...is somewhere detailed step-by-step instructions on how to prepare and release a finished project for Steam or itch.io ?....I did not find anything detailed in the documentation...Thanks guys!

Edited by Bishop
Link to comment
Share on other sites

itch.io, as far as I know, is nothing more than a download, create your account make a page for your product and you are good to go. @practicing01 has published on itch maybe he can help.

Steam is much more involved @Steve_Yorkshire and @greenfire27 have both published steam projects

So we do have users who have the knowledge, and I've pinged them so they will be annoyed with me now :p

Link to comment
Share on other sites

@Bloodknight Thanks for your time to help me......I have itch.io account....Steam ac. i don't have there it's obviously a bit more complicated .... but i rather think where and what i can delete in the project .... eg. an editor is not needed, etc........i always use a pre-compiled BLANC template .... so if i delete unnecessary folders and files it will be ok?.....then zip package for players?......or I must delete unnecessary folders and files and re-compile/build in the VS whole project?.....VS a Cmake things...for this i'm totally stubborn :-))

Link to comment
Share on other sites

I went through all the steps so I could explain it all to you, the question is more, if I'm motivated enough for that.

Well first you need to compile the game as a release build, then you need to remove everything from the game the final client should not be able to use, like your graphic settings like pref.cs and replace it with a good default one, then remove editor, shader cache etc, then you hsould have your game in one folder.

Then you take the folder and copy it to your PC somewhere else and test if it runs, or better to another persons PC, if everything runs fine, then you can release it on Steam.

To release it on Steam you better read the tutorials for it, when you registered and setup your account, you need to setup your store page and game repo, for the game repo you need to download a SteamCMD client or whatever and you put the game folder into there, then you run the client and it will update the folder to Steam, then you can press release in the Steam developer account for your game. The Steam client is basically like Git, a version control system.

You should have some friends and give them beta keys, so you can test it before you release it for real.

If you have more questions just ask or show me your game, then I can tell you what is wrong with it.

Link to comment
Share on other sites

@Duion Thanks very much.....pity that more detailed instructions are not in the documentation

...compared to Unity engine and Godot engine where it's basically easier ... eg in the Godot engine the final product for release is basically pressing one or two buttons.

Link to comment
Share on other sites

sorry I think I misunderstood the question originally.

There used to be a torque_shipping flag which set the build processes needed for actually shipping the game, don't know the details tbh but it was in part a more streamlined release build from what I recall.

the original toolbox had helpers and such likes for making installers and prepping the game for release, it might be worth looking at those in more detail, steam obviously has its own methods, but I suspect the streamlining of the project for release before installers works generically.

So really steps (some optional depending what you want to do) are :-

1) Check the shipping flag in the engine and recompile

2) remove cached files that you don't need to ship

3) remove the tools folder

4) set the compile to dso flag and remove the extra .cs files (iirc the main.cs still needs to be a .cs better check other opinions on that one)

5) Create a zip/installer (nsis or inno are still commonly used and updated)

6) profit!

Link to comment
Share on other sites

Way back in 3.5.1 ... your project/source/torqueConfig.h file should look like this:

So first up enable dso compiling flag, then run your project for the DSOs to compile, then disable the flag again.

Remove all cs and dae files, let your game read only the compiled files dso and cached.dts ( that way no one can see how bad your scripts are ;) or reuse your collada files)

Set the relevant flags for shipping, player etc.

As I remember, you have to add the player build flag above the debug flag to disable debug which in turn selects release build. Also manualy set shipping.

Also seem to remember that game/main.cs had to be included and NOT the dso of it. This might have been fixed since then as I did mention it to GG but that doesn't mean anything happened and I can't remember off the top of my head.


//Hi, and welcome to the Torque Config file.
//This file is a central reference for the various configuration flags that
//you'll be using when controlling what sort of a Torque build you have. In
//general, the information here is global for your entire codebase, applying
//not only to your game proper, but also to all of your tools.
/// What's the name of your application? Used in a variety of places.
#define TORQUE_APP_NAME            "Airship Dragoon"
/// What version of the application specific source code is this?
/// Version number is major * 1000 + minor * 100 + revision * 10.
#define TORQUE_APP_VERSION         1660
/// Human readable application version string.
/// Define me if you want to enable multithreading support.
/// Define me if you want to disable Torque memory manager.
/// Define me if you want to disable the virtual mount system.
/// Define me if you want to disable looking for the root of a given path
/// within a zip file.  This means that the zip file name itself must be
/// the root of the path.  Requires the virtual mount system to be active.
//Uncomment this define if you want to use the alternative zip support where you can 
//define your directories and files inside the zip just like you would on disk
//instead of the default zip support that treats the zip as an extra directory.
/// Define me if you don't want Torque to compile dso's
#define TORQUE_PLAYER//yorks add this and for player!
// Define me if this build is a tools build
#  define TORQUE_TOOLS
/// Define me if you want to enable the profiler.
///    See also the TORQUE_SHIPPING block below
/// Define me to enable debug mode; enables a great number of additional
/// sanity checks, as well as making AssertFatal and AssertWarn do something.
/// This is usually defined by the build target.
//#define TORQUE_DEBUG
/// Define me if this is a shipping build; if defined I will instruct Torque
/// to batten down some hatches and generally be more "final game" oriented.
/// Notably this disables a liberal resource manager file searching, and
/// console help strings.
#define TORQUE_SHIPPING//yorks on
/// Define me to enable a variety of network debugging aids.
///  - NetConnection packet logging.
///  - DebugChecksum guards to detect mismatched pack/unpacks.
///  - Detection of invalid destination ghosts.
/// Define me to enable detailed console logging of net moves.
/// Enable this define to change the default Net::MaxPacketDataSize
/// Do this at your own risk since it has the potential to cause packets
/// to be split up by old routers and Torque does not have a mechanism to
/// stitch split packets back together. Using this define can be very useful
/// in controlled network hardware environments (like a LAN) or for singleplayer
/// games (like BArricade and its large paths)
#define MAXPACKETSIZE 1500//yorks on
/// Modify me to enable metric gathering code in the renderers.
/// 0 does nothing; higher numbers enable higher levels of metric gathering.
/// Define me if you want to enable debug guards in the memory manager.
/// Debug guards are known values placed before and after every block of
/// allocated memory. They are checked periodically by Memory::validate(),
/// and if they are modified (indicating an access to memory the app doesn't
/// "own"), an error is flagged (ie, you'll see a crash in the memory
/// manager's validate code). Using this and a debugger, you can track down
/// memory corruption issues quickly.
/// Define me if you want to enable instanced-static behavior
/// Define me if you want to gather static-usage metrics
/// Define me if you want to enable debug guards on the FrameAllocator.
/// This is similar to the above memory manager guards, but applies only to the
/// fast FrameAllocator temporary pool memory allocations. The guards are only
/// checked when the FrameAllocator frees memory (when it's water mark changes).
/// This is most useful for detecting buffer overruns when using FrameTemp<> .
/// A buffer overrun in the FrameAllocator is unlikely to cause a crash, but may
/// still result in unexpected behavior, if other FrameTemp's are stomped.
/// This #define is used by the FrameAllocator to align starting addresses to
/// be byte aligned to this value. This is important on the 360 and possibly
/// on other platforms as well. Use this #define anywhere alignment is needed.
/// NOTE: Do not change this value per-platform unless you have a very good
/// reason for doing so. It has the potential to cause inconsistencies in 
/// memory which is allocated and expected to be contiguous.
///@ TODO: Make sure that everywhere this should be used, it is being used.
/// This #define should be set if the engine should use a 32-bit format for
/// 24-bit textures. The most notable case is converting RGB->RGBX for various
/// reasons.
// CodeReview: It may be worth determining this at run-time. Right now I just
// want to wrap code which forces the conversion from 24->32 in a common 
// #define so it is easily turned on/off for the problems we are encountering in
// the lighting. [5/11/2007 Pat]
/// This #define is used by the FrameAllocator to set the size of the frame.
/// It was previously set to 3MB but I've increased it to 16MB due to the
/// FrameAllocator being used as temporary storage for bitmaps in the D3D9
/// texture manager.
#define TORQUE_FRAME_SIZE     16 << 20
// Finally, we define some dependent #defines. This enables some subsidiary
// functionality to get automatically turned on in certain configurations.
      #define TORQUE_DEBUG_GUARD
      #define TORQUE_NET_STATS
   // Enables the C++ assert macros AssertFatal, AssertWarn, etc.
  // If it's not DEBUG, it's a RELEASE build, put appropriate things here.
    // TORQUE_SHIPPING flags here.
   // Enable the profiler by default, if we're not doing a shipping build.
   // Enable the TorqueScript assert() instruction if not shipping.
   // We also enable GFX debug events for use in Pix and other graphics
   // debugging tools.
#  define TORQUE_INSTANCE_EXCLUSION   "TorqueToolsTest"
#  define TORQUE_INSTANCE_EXCLUSION   "TorqueTest"
// This is the lighting system thats enabled by default when the scene graphs are created.
//#define DEFAULT_LIGHTING_SYSTEM "SynapseGaming Lighting Kit"
#define DEFAULT_LIGHTING_SYSTEM "Basic Lighting"
// Someday, it might make sense to do some pragma magic here so we error
// on inconsistent flags.
// The Xbox360 has it's own profiling tools, the Torque Profiler should not be used
#  endif
#endif // _TORQUECONFIG_H_


If you're using Steam you need to ship the steam_api.dll in your game folder and of course have the necessary links to #include and probably achievements and hookup stuff in app/mainLoop.cpp. Sure I wrote a tutorial on this somewhere. :?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...