UNCREATION - A new text mystery adventure!

[johannhowitzer]

I'm not exactly sure how encryption would be practical here.  If I encrypt the code, people would have to decrypt it anyway to use it.  If I encrypt things within the code, the code becomes massively harder to work with, multiplying the time to finish the game greatly.  If I package all the text outside the game code and encrypt it in an external file, same problem.  If I package pretty much the whole game's text and conditional logic into an $include file, even if I could encrypt that, people would just have the same complaint they do about the EXE file - there's a black box they can't know the inner workings of.

Basically any way I do this, it comes back around to the same problem.  I almost want to say text adventure games can't be made in QB64, then.  QB64 only makes EXE files.  Is there any way something made in QB64, without source provided, can ever be trusted by anyone?  Serious question.

[Petr]

I'm not exactly sure how encryption would be practical here.  If I encrypt the code, people would have to decrypt it anyway to use it.  If I encrypt things within the code, the code becomes massively harder to work with, multiplying the time to finish the game greatly.  If I package all the text outside the game code and encrypt it in an external file, same problem.  If I package pretty much the whole game's text and conditional logic into an $include file, even if I could encrypt that, people would just have the same complaint they do about the EXE file - there's a black box they can't know the inner workings of.

Basically any way I do this, it comes back around to the same problem.  I almost want to say text adventure games can't be made in QB64, then.  QB64 only makes EXE files.  Is there any way something made in QB64, without source provided, can ever be trusted by anyone?  Serious question.

Hello. Completely logical. If the person wants to play it, he will compile it straight away and not study the source code. But if someone studies it first before play it, he cheats himself in the game. So I would leave it up to each individual how they approach it.

[johannhowitzer]

Hello. Completely logical. If the person wants to play it, he will compile it straight away and not study the source code. But if someone studies it first before play it, he cheats himself in the game. So I would leave it up to each individual how they approach it.

Yes, that's completely reasonable and I agree with you... that is how I was thinking at first.  But after that, I realized another scenario is more likely - that someone will begin playing in earnest, but then get stuck for a bit, and realizing they can just dig through the code to find the way to make progress, give in to temptation.  That's the scenario that concerns me... not just because people might get less enjoyment from solving things, but also because I'd essentially be leaving temptation wide-open for people to reinforce a bad habit.

Another thing that occurred to me, after having posted this thread and thinking some more - some of the more satisfying solutions in this game actually wouldn't be evident from studying the code at all.  A large majority of the simpler stuff would be completely transparent on reading the code, but there are bigger puzzles in this game, where you have all the information already.  In those cases, cheating wouldn't tell you anything you didn't already know, since the challenge is putting the pieces together in the right way.

Anyway, I also realized it's not really important at this point.  This is just a taste, the first chapter.  After the game is finished, it would be a lot easier for me to retroactively encrypt everything.  And I've got some friends playing the game as well, so it's not like I'm missing out on testing at this point in development.  I think this is what I'll go with for now.

[mnrvovrfc]

Hello. Completely logical. If the person wants to play it, he will compile it straight away and not study the source code. But if someone studies it first before play it, he cheats himself in the game. So I would leave it up to each individual how they approach it.

Welcome back Petr.

[luke]

I discovered two things playing this:

1. Black on white is a surprisingly nice colour scheme for QB programs
   
2. I'm really bad at text adventures
   

One thing I would suggest is trying a variable-width font, maybe even just a basic Arial. It would make it quite a bit easier to read (though would lose some of the aesthetic, I suppose).

[mnrvovrfc]

One thing I would suggest is trying a variable-width font, maybe even just a basic Arial. It would make it quite a bit easier to read (though would lose some of the aesthetic, I suppose).

Agreed, but a font with good kerning.

[madscijr]

I had typed up some other stuff, but I realized it all really boiled down to one point: I'm not new here.  I've been around for years.  If you're very interested in playing this, I can send you the source code in a message, but posting it publicly would just be posting a walkthrough to my own game.

I'll message you, but also, it might be worth considering looking at ways to code the game so that the content and solutions are not plainly readable by looking at the source code. As an example, look at the old Scott Adams adventures, where everything is broken up & stored in arrays. You might write a utility program to convert between your original "source" logic and more obfuscated code that goes into the released program. Maybe you are doing some of this already, I won't know until I can see the source code. I'll let you know if I have any ideas!

[mnrvovrfc]

Might take it to one extreme like I noticed in one of M$ help files long ago: store every possible word to be used in alphabetical order. And then each paragraph would be an array of integers summoning the words, with special codes eg. for period to end a sentence. Maybe store the array in backwards order, every other time, every third time, shorud the words with a simple encryption for better security.

But only like ten people would try to attack any source code without playing the game in an honest try. Everybody else would be turned off or choose not to download. "Why is he so suspicious?" It takes courage what Luke said, because many people hate to lose anything remotely called "game".

Originally I didn't want to offer my "Wormer" source code but wanted to prove that I indeed came up with it almost nine years ago. Just check out the BMP's that came with it and the player already knows how the board is like. But it is his/her option to take away the fun that way which is the reason why he/she really doesn't enjoy anything.

[madscijr]

Might take it to one extreme like I noticed in one of M$ help files long ago: store every possible word to be used in alphabetical order. And then each paragraph would be an array of integers summoning the words, with special codes eg. for period to end a sentence.  Maybe store the array in backwards order, every other time, every third time, shorud the words with a simple encryption for better security.

Something like that, if they really really want to make it hard for someone to see the solution. 

This all makes it harder on the programmer, too. 

I think what Johann wants (correct me if I'm wrong) is for the source code to not be a spoiler, and ruin the game for someone looking at it. 

If someone is dead set on seeing the solution then let them, as long as the game solutions aren't visible in plain text. 

Simpler is better for the programmer, too, because they don't want to spend a lot of time "hiding" the solution in their code. They already have enough to worry about and do, like make sure the main game code works and the content and puzzles are fun with the right amount of challenge without being frustrating.

Now, for how to store the game text... For the array of words idea, I don't think the array has to be in alpha order. It's just replacing a word with a letter, sorting it won't make a difference. Instead of words, we could simply map each character to a different one. 

We can keep all the text in a resource (txt) file that the game uses, and make an "encode/decode" program to convert the file between "clear text" & "scrambled". 

Or we could keep the text in DATA statements and our utility can read the .BAS file and look for data statements (maybe just lines inbetween lines such as 
REM BEGIN CONTENT 
and 
REM END CONTENT
) and encode or decode all non-comma non-space characters in each line after "DATA ", 
and the output .BAS file is the same in every way except the DATA lines have encoded values. It might need to change a constant that you set at the top of the game which represents the game mode "clear text" or "encoded" for the content. 

This is just off the top of my head, completely different ideas might come to 
mind once I've looked at the actual program. Or maybe someone who has done this before knows something completely different. "And now for something completely different!" ?

[madscijr]

I think I was mostly deflated yesterday - this week was really rough, and I was excited to finally show this game, so to have it received thus... it didn't offend, it just took all the wind out of my sails, I guess.

We've all been there, especially after working so hard on a project! 
Last year I poured blood, sweat, and tears into a game I was really proud of, only to get a single reply, where the person basically said they can't play it because the keyboard controls are too complicated (even though the game works with game controllers too). Basically the person said my game was an interesting exercise for people to become more familiar with the keyboard, LoL. I got no actual feedback from anyone on the game itself. Talk about wind out of sails! 

You just have to keep trying! In my case, I moved on to another project but will eventually get around to "re-releasing" the game, maybe with some tweaks.

I can certainly understand people's reluctance with EXE files, but I'm struggling to think of a way to post source that doesn't give away every puzzle in the game.

It can be done! See our discussion above...

Hello. Completely logical. If the person wants to play it, he will compile it straight away and not study the source code.

But if someone studies it first before play it, he cheats himself in the game. So I would leave it up to each individual how they approach it.

That's all you can do! As a programmer (or the creator of anything), it's often the case that our control ends once our creating is in the audience's hands. You just have to let go, and hope they listen to whatever instructions you tell them!

Yes, that's completely reasonable and I agree with you... that is how I was thinking at first.  But after that, I realized another scenario is more likely - that someone will begin playing in earnest, but then get stuck for a bit, and realizing they can just dig through the code to find the way to make progress, give in to temptation.  That's the scenario that concerns me... not just because people might get less enjoyment from solving things, but also because I'd essentially be leaving temptation wide-open for people to reinforce a bad habit.

Maybe one approach is how Infocom approached this - by having a hint book, with help for different puzzles on separate pages (so they don't inadvertently see more than they need to).

Or have a hint feature in your game, where if the player is stuck, they can type the "help" command, and the game will provide a hint. Maybe you can vary the difficulty, where the first time they ask for a hint, the answer is vague. If they ask again, it can be a little more specific. Each time they ask, they would get more information. It's up to them whether they want to keep asking.

Another thing that occurred to me, after having posted this thread and thinking some more - some of the more satisfying solutions in this game actually wouldn't be evident from studying the code at all.  A large majority of the simpler stuff would be completely transparent on reading the code, but there are bigger puzzles in this game, where you have all the information already.  In those cases, cheating wouldn't tell you anything you didn't already know, since the challenge is putting the pieces together in the right way.

Anyway, I also realized it's not really important at this point.  This is just a taste, the first chapter.  After the game is finished, it would be a lot easier for me to retroactively encrypt everything.  And I've got some friends playing the game as well, so it's not like I'm missing out on testing at this point in development.  I think this is what I'll go with for now.

Sounds good. Whenever you can send the source code, I will give it a shot!