UNCREATION - A new text mystery adventure!

[SMcNeill]

Easy solution for preserving your source, and for making your EXE smaller -- compress your text data with _DEFLATE.  Turn it into hex code instead of 256-bit extended ASCII.  Embed that hex code into your BAS file.

Sure, somebody could reverse engineer the process (hex to ascii, _INFLATE to raw text), but from my experience, the coders who are good enough to do that aren't the ones who usually want/need the source for a walkthrough.  It protects the source from mildly curious eyes, and for most text adventures, that's the best you can ever hope for anyway.  After all, a run though any hex editor can fairly easily find and return all your embedded text from your EXE.  If someone *really* wants the contents, they're going to get them anyway.

[mnrvovrfc]

After all, a run though any hex editor can fairly easily find and return all your embedded text from your EXE.

AH I've forgotten about this!

Also use "strings.exe" program (part of MinGW and exists in many Linux "devel" toolkits). I could have downloaded the program showcased on this thread then used "strings.exe" on it on the terminal. Now let's see, is it worth playing?

• Yes = I lie to johannhowitzer that it was cool.
  
• No = I don't post anything on the forum and I don't even tell that I downloaded or ran the EXE file.
  

No I didn't actually do this LOL but this has been said about the EXE file provided so far. But my reason was different for not downloading it, as I've already maintained.

[johannhowitzer]

My apologies for not getting back to this yesterday, I had a RL crisis to handle.

A warning to anyone trying out the game!

As one of my friends tested the game, he stumbled over a joke that I put in, and I learned
it's just going to be very confusing for the player and serve as an unintentional red herring.
The first time you try to "get" something that doesn't exist, the game puts it in your inventory
anyway.  Which can be really amusing if you type something like "get flamethrower" on a whim
and the game says "You got the flamethrower."  No idea why it didn't occur to me that someone
would set this off when earnestly trying to get something that seems get-able but isn't.
My friend ended up with a fake key.  So I'm taking that joke out in the next version!


@luke:

I'd be open to trying a different font, or even letting the player choose their own font.
In the latter case, I'd have to implement automatic line breaks, right now I'm doing all line
breaks by hand.  Wouldn't be hard to do, it's a choice I may make later.  I haven't messed with
fonts very much in QB64, apart from my own pixelart font system.


@madscijr:

[Send source code]

For now, I'm writing everything in-line, as you can see in my text adventure tutorial video,
because it's so easy and allows me to focus on the writing and level design.  I do see some kind
of encryption as possible later, but with the game unfinished, it will really get in my way.


@mnrvovrfc

See above, your idea is one way to do encryption, yeah.  Cboyu hlad ne dvie fnidf oe real ii L nfse anncee.
(read every other letter)

"Everybody else would be turned off or choose not to download."

Really?  That wouldn't be my reaction at all, I think that might just be you.  And again, I have
to refer back to track record - all other projects I've posted have been via source code, this is
a special case and I can see people in this thread are appreciating that.

It's very clear by now that this kind of game does not interest you.  That's fine, and I know text
adventures can be a hard sell.  It's not even my main project, just a fun thing I'm doing on the side.
But I think people who are open to giving games like this a chance are going to experience
some cool moments along the way!  I have a lot of fun surprises in store, many of which
are yet to come in later chapters.


@madscijr:

"If someone is dead set on seeing the solution"

Yes, I agree, currently the solutions are in plain text, and what I'm concerned about isn't
someone who is dead set on seeing the solution, I'm concerned about someone who gets tempted
by frustration at being a bit stuck, gives in, and regrets it.  If the source code wasn't so
easy to read right now, I'd have already posted it.

Your idea of a text resource file was my first thought as well, with an encryption algorithm
in the middle to make opening the text file not be a spoiler.  I could choose any of a thousand
encryptions for this, and then all the code would still be present, just not the PRINT contents.
I'm also using abstraction constants which are a bit transparent, so I'd just replace those with
their values in-line as well - replace flag(i_sh_keyring) with flag(12), for example.

[madscijr]

As one of my friends tested the game, he stumbled over a joke that I put in, and I learned
it's just going to be very confusing for the player and serve as an unintentional red herring.
The first time you try to "get" something that doesn't exist, the game puts it in your inventory
anyway.  Which can be really amusing if you type something like "get flamethrower" on a whim
and the game says "You got the flamethrower."  No idea why it didn't occur to me that someone
would set this off when earnestly trying to get something that seems get-able but isn't.
My friend ended up with a fake key.  So I'm taking that joke out in the next version!

That's a neat & funny feature - don't remove it!
Instead, just add logic to only let that happen for items not mentioned in the game text.
That way, your "Easter egg" can continue to amuse without confusing the player.
Maybe add a constant like cEnableEasterEgg to be able to turn it off.

I'd be open to trying a different font, or even letting the player choose their own font.

I usually like having the option.
To be honest, for a BASIC text adventure, I'd just prefer the default QB64 font.
Keep it simple, and all that.

For now, I'm writing everything in-line, as you can see in my text adventure tutorial video,
because it's so easy and allows me to focus on the writing and level design.  I do see some kind
of encryption as possible later, but with the game unfinished, it will really get in my way.

Could you (re)mention the URL for your tutorial video? I must have missed it.

I totally understand about having content visible while you work on the game.
I think moving the content into a text file -as plain text- might be a good compromise, because it is easy to work with & change while developing, while at the same time, it's no longer in the code, so people can look at your code & make sure nothing malicious got injected during the download before they execute the program, without any spoilers of seeing the solution.

"If someone is dead set on seeing the solution"

Yes, I agree, currently the solutions are in plain text, and what I'm concerned about isn't
someone who is dead set on seeing the solution, I'm concerned about someone who gets tempted
by frustration at being a bit stuck, gives in, and regrets it. 

Don't be concerned about people who can't handle the temptation to read the solution. Just warn them with a disclaimer - and don't let your worries about people who would willingly spoil their own surprise make you compromise the simplicity of your code and thus make it harder for programmers to learn from. One of the greatest benefits and "features" of QB64 and open-source code is that it's accessible for people to examine and learn from. Once you start doing things like encrypting content (in a way that's difficult to decrypt), you start to lose that benefit, and your program becomes less useful to the segment of the audience whose real interest is in learning how your program works and adding some new tools to their belt (I think that describes most QB64PE users & people who like open source in general). 

If the source code wasn't so
easy to read right now, I'd have already posted it.

Your idea of a text resource file was my first thought as well,

I think just having the content in a separate text resource file would be a good simple way to help "protect" curious programmers from having the game's suprised spoiled. That way we can study your code without ever having to look at the content.

with an encryption algorithm
in the middle to make opening the text file not be a spoiler. I could choose any of a thousand
encryptions for this, and then all the code would still be present, just not the PRINT contents.

Ugh, don't use some real encryption algorithm - that's kind of against the principles of open source. I think you just need some simple method to obfuscate the text, like shifting each character to ASC(MyChar)+1, or inserting random letters every other character. Keep it simple and just write a simple utility to "encrypt" and "unencrypt" the resource file and set a "cEncryptedContent" constant in the program itself.

I'm also using abstraction constants which are a bit transparent, so I'd just replace those with
their values in-line as well - replace flag(i_sh_keyring) with flag(12), for example.

Keyrings and encryption... yuck! LoL

Just my own opinions! Or course it's your baby, so I'm not expecting you to follow my or anyone else's preferences. You should do what pleases you! :-)

I hope this helps.