Bishop Posted July 11, 2020 Share Posted July 11, 2020 (edited) 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 July 12, 2020 by Bishop Quote Link to comment Share on other sites More sharing options...
Bloodknight Posted July 11, 2020 Share Posted July 11, 2020 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 projectsSo we do have users who have the knowledge, and I've pinged them so they will be annoyed with me now :p Quote Link to comment Share on other sites More sharing options...
Bishop Posted July 12, 2020 Author Share Posted July 12, 2020 @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 :-)) Quote Link to comment Share on other sites More sharing options...
Duion Posted July 13, 2020 Share Posted July 13, 2020 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. Quote Link to comment Share on other sites More sharing options...
Bishop Posted July 14, 2020 Author Share Posted July 14, 2020 @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. Quote Link to comment Share on other sites More sharing options...
Bloodknight Posted July 14, 2020 Share Posted July 14, 2020 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 recompile2) remove cached files that you don't need to ship3) remove the tools folder4) 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! Quote Link to comment Share on other sites More sharing options...
Steve_Yorkshire Posted July 15, 2020 Share Posted July 15, 2020 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. #ifndef _TORQUECONFIG_H_ #define _TORQUECONFIG_H_ //----------------------------------------------------------------------------- //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 TORQUE_APP_VERSION_STRING "1.6.6" /// Define me if you want to enable multithreading support. #ifndef TORQUE_MULTITHREAD #define TORQUE_MULTITHREAD #endif /// Define me if you want to disable Torque memory manager. #ifndef TORQUE_DISABLE_MEMORY_MANAGER #define TORQUE_DISABLE_MEMORY_MANAGER #endif /// Define me if you want to disable the virtual mount system. //#define TORQUE_DISABLE_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. //#define TORQUE_DISABLE_FIND_ROOT_WITHIN_ZIP //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 TORQUE_ZIP_DISK_LAYOUT /// Define me if you don't want Torque to compile dso's //#define TORQUE_NO_DSO_GENERATION #define TORQUE_PLAYER//yorks add this and for player! // Define me if this build is a tools build #ifndef TORQUE_PLAYER # define TORQUE_TOOLS #else # undef TORQUE_TOOLS #endif /// Define me if you want to enable the profiler. /// See also the TORQUE_SHIPPING block below //#define TORQUE_ENABLE_PROFILER /// 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 TORQUE_DEBUG_NET /// Define me to enable detailed console logging of net moves. //#define TORQUE_DEBUG_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 TORQUE_GATHER_METRICS 0 /// 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 TORQUE_DEBUG_GUARD /// Define me if you want to enable instanced-static behavior //#define TORQUE_ENABLE_THREAD_STATICS /// Define me if you want to gather static-usage metrics //#define TORQUE_ENABLE_THREAD_STATIC_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. //#define FRAMEALLOCATOR_DEBUG_GUARD /// 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. #define TORQUE_BYTE_ALIGNMENT 4 /// 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] //#define TORQUE_FORCE_24_BIT_TO_32_BIT_TEXTURES /// 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. #ifdef TORQUE_DEBUG #define TORQUE_GATHER_METRICS 0 #define TORQUE_ENABLE_PROFILE_PATH #ifndef TORQUE_DEBUG_GUARD #define TORQUE_DEBUG_GUARD #endif #ifndef TORQUE_NET_STATS #define TORQUE_NET_STATS #endif // Enables the C++ assert macros AssertFatal, AssertWarn, etc. #define TORQUE_ENABLE_ASSERTS #endif #ifdef TORQUE_RELEASE // If it's not DEBUG, it's a RELEASE build, put appropriate things here. #endif #ifdef TORQUE_SHIPPING // TORQUE_SHIPPING flags here. #else // Enable the profiler by default, if we're not doing a shipping build. #define TORQUE_ENABLE_PROFILER // Enable the TorqueScript assert() instruction if not shipping. #define TORQUE_ENABLE_SCRIPTASSERTS // We also enable GFX debug events for use in Pix and other graphics // debugging tools. #define TORQUE_ENABLE_GFXDEBUGEVENTS #endif #ifdef TORQUE_TOOLS # define TORQUE_INSTANCE_EXCLUSION "TorqueToolsTest" #else # define TORQUE_INSTANCE_EXCLUSION "TorqueTest" #endif // 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 #ifdef TORQUE_OS_XENON # ifdef TORQUE_ENABLE_PROFILER # undef TORQUE_ENABLE_PROFILER # endif # # ifdef TORQUE_ENABLE_PROFILE_PATH # undef TORQUE_ENABLE_PROFILE_PATH #endif #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. :? Quote Link to comment Share on other sites More sharing options...
Bishop Posted July 17, 2020 Author Share Posted July 17, 2020 Wow!....guys thanks very much, I appreciate that for the very valuable answers...i'll get to it ... I'm switching from windows 7 to linux mint 20 - Cinnamon this week...so hopefully it will be fine on linux :-) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.