Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

Electron is certainly an option, albeit a somewhat inefficient one. A "dangerous" web-decker build could use custom JS extensions to possibly handle steam integrations, I guess?

The normal Decker executable can be given a startup deck or launched with command-line arguments (which could be supplied via a script or batch file). Anyone is welcome to re-distribute my Windows or MacOS executables for the purposes of shipping their decks. Using app.save[] to preserve state would work in this scenario, though you'd probably want your deck to include some way to reset your game or program to a factory default.

With more effort, you could build Decker from source and replace "/examples/decks/tour.deck" to make a Decker executable that always loaded your deck on startup without accessing any external files. A "dangerous" build of native-decker could use danger.read[]/danger.write[] to preserve state silently. Going this route would also make it possible to add in custom steam-specific interfaces, but you'd have to get your hands dirty writing C. Compiling Decker on Windows is a real pain and I do not wish to tutorialize or offer tech support for any aspect of the Windows development ecosystem.

Thank you!

Building from source for windows seems like a challenge. I'm on linux.

But, using a normal Decker executable seems like it would be pretty straight forward. Are there any downsides to that approach for targeting Windows and Mac? 

Like what would be the difference for the player's experience between a native decker that auto-loads a deck vs. Decker built from source with a different "tour.deck"? Does it net out to the same thing essentially?

A baked-in tour.deck vs. a startup deck is essentially the same from a user perspective. Startup decks were intended as a simple way to allow people to distribute decks along with a native runtime.