Making a game playble on other computers

[Wolff]

So that's a thing I've never thought about. I made a couple of games/programs but now that I want to show it to someone I'm at loss.
How do I turn my game into a legit .exe file with maybe an installer if it's necessary?
It's written in c++ in VS, with couple of standard libraries and SFML. It also has some .txt and .jpg files.
I looked on google and youtube but never found a solid tutorial.
Thanks for all the help!

[FRex]

If you include all the needed dlls and your game files then you can just zip it up and give it to someone. If you really want to make an installer (why?) you can use Inno Setup, Nullsof Scriptable Install System or some other 'installer maker'.

[Wolff]

If I include like how? Do I just take the .exe file from my programs folder, put it in a new one, move every file from debug and other folders that my program oparates on and put it in the same folder zip it up and move to another computer it's going to work there?
I've heard about building the project not in a debug mode but in release mode but I'm not sure how that works and I dont want to screw anything up. Also what about libraries like SFML, doesnt the program need them?
I talked about an installer because I'd like it to be legit in a way, with a desktop shortcut which you could just run and the program would fetch everything it needs from another folder etc.
It's so weird, I havn't seen people talk about it like at all on forums.
Thanks for any and all input!

[Wolff]

FRex, form the small games that you've made (like snake), it's just the .dll files and the .exe file.
Is that all I'd need to do? Just go into the games folder, copy all .dll files there are and my .jpg and .txt files, zip it alongside with the .exe file and that's it? The release mode when building isn't necessary?

[gws923]

So, first of all I just want to explain the difference between debug mode and release mode.

If you have a class called "Player" and that class has a member value called jumpHeight and you never initialize that value, the debug compiler might say "Okay well I was never told what jumpHeight should be.  I'll make it 1." And your code runs fine.

Compiling in release mode, this doesn't happen.  Instead the compiler says "I was never told what jumpHeight should be so I'm not going to do anything."  This can cause your code to break or act completely different at runtime.

If you don't really plan on "releasing" your game, it doesn't really matter.  Except that when you compile in debug, your program generally runs slower, and if you set up SFML correctly, the compiler will look for the debug versions of the libraries (which, I assume are bigger but I don't actually know that).

So if you just want to show it to your friends it's not a big deal.

That said, here's what you will need to give them. (I recommend copying these things instead of moving them)
The .exe file produced by your compiler.
All of the sfml .dll files (Assuming you didn't link the libraries statically.)
All of the .dll files of any other libraries you used (again, assuming you linked dynamically, not statically)
All folders containing all images, sounds, fonts, etc.  They should be in the same relative position to your .exe file as they were in your project folder.
Zip em up!

If you give this to your friend and they unzip the files and double click the .exe file, it should work.  If it complains about a missing .dll file, then you probably missed one.  And, if you set up your code correctly, it should complain about missing files like images and fonts (SFML will throw errors for missing files in any case).

It's actually not too complicated.  You seem like you think you're overthinking it.  You're not!

[Wolff]

Thank you so much!
One thing, when I tried to put them how they were in my projects folder (.exe in debug folder, rest of the files in a neighboring one) it didn't seem to find the .dll files, when I put everything into one folder it worked perfectly!
One last quick question, what advantage does compiling in release mode has over the debug one (just runs faster + won't initiate if your code isn't "complete" ?).
Oh and also, if I were to one day hopefully release a game, are there programs that make it hard to tamper with all the loose .txt and .jpg files, or do developers just code their own methods of securing these files into the game?
Thanks so much for your help!   

[FRex]

https://stackoverflow.com/questions/5101458/why-is-a-bad-practice-to-distribute-the-debug-version-of-the-application-in-net

Specific dlls and where to find them (other than anything you use like SFML dlls) depend on your specific compiler. With certain compilers and/or compiler setting there might be nothing (that's often called 'fully statically linked standalone executable' or similar and depends only on built in stuff in C:/Windows/). You need to be careful not to include wrong ones, like wrong architecture (32 bit vs 64 bit) and so on. Many commercial games made in VS include an installer of VS redistributable runtime instead and run it at first launch or something.

You can pack your files into zip or 7z or something and then load them using some library like PhysicsFS (be sure to get latest version from Mercurical, latest stable version is badly busted, you need to buil dit yourself either way). PhysicsFS is meant for this (gamedev) purpose and support many formats (but it's best to stick to zip or 7z).

This is only zipping up into a single file, if you want encryption you need something else (zip encryption works with PhysicsFS but is very bad/tedious to use in your code). Any encryption (even proper AES) you do will be eventually be broken by a determined hacker who finds where the key is in the exe or game files though (even commercial real games get pirated and DRM broken all the time) so you might just not bother or go with just a xor with some hardcoded key (this is horrible and unsecure encryption but it's easy and quick to do and you're just trying to demotivate the most common attacker anyway) and set it to all 0s during development to work on plain files and use 7z instead of zip and a different extension than .7z to try confuse/demotivate most people (just changing the extension without any encryption/scrambling of the contents will only makes the simplest hacker go away).

If you want to embed files into the exe there are a few way too. There are OS specific ways to do it (I know nothing about them), there is embedding them in the code as const char[] = { data-here } (there are tools to generate these files or you can write one yourself, it's like 20-30 lines of code) or another funny/easy way is to concatenate an archive onto an exe and then open it in the right way in your program. Or you can just not bother with it and have: your exe, your dlls, an archive file or few, and maybe some config and a save directory. That's not that much stuff to have (the archiving of all your game resources into a single file is your biggest win for decluttering and performance).

[Wolff]

That's super intersting!
So using xor would look like writing a program that would encrypt .txt file with a key, then use a similar function in the game that would decrypt it with the key and use it in the game? I wrote a similar thing some time ago.
I wonder if you can somehow use it on .jpg or .png files as well.
It's not like I want the game to be super solid, I just think that having everything out in the open might seem unproffesional even if the game isn't like a huge project. And it might tempt people to take a peek at the story/dialogues, or graphics that they havn't yet expirience in game.
Thanks for all the help!!

[gws923]

Thank you so much!
One thing, when I tried to put them how they were in my projects folder (.exe in debug folder, rest of the files in a neighboring one) it didn't seem to find the .dll files, when I put everything into one folder it worked perfectly!
One last quick question, what advantage does compiling in release mode has over the debug one (just runs faster + won't initiate if your code isn't "complete" ?).
Oh and also, if I were to one day hopefully release a game, are there programs that make it hard to tamper with all the loose .txt and .jpg files, or do developers just code their own methods of securing these files into the game?
Thanks so much for your help!   

Ah!  Well I'm glad you figured out the file structure.  I think my instructions were a little confusing now that I look back.  It does make sense that you wouldn't keep the .exe file in the /debug folder.  Glad you got it working!

Release mode just makes things more stable, smooth, and fast, generally.  In the first game I released using SFML I noticed a considerable difference between debug and release mode in terms of performance, (not necessarily due to SFML, in fact it probably wasn't due to SFML).

As for the last point, if you have data in a .txt file, you can try making them .dat files, etc. but.... it's probably not worth the effort.  I encrypted all of my data files for my first game and left myself wondering what the point was.  If your game is cool enough that people want to modify it, then you should probably let them

The only exception I can think of are things like Steam achievements or online play, in which case you'd need to store player information in accounts on a server instead of on their computer (way over my head).

[FRex]

It works in binary, it doesn't care about your file type but some formats will leak parts of your key and so on.

For example if someone knows you are xoring and then sees a .png file that is xored then he has a few bytes of your key since all png files have the same header.

So it's a horribly bad encryption in general (except when key is as long as the encrypted file and a one time used value, then that's unbreakable and all other unbreakable encryption algorithms can be reduced to this one too, it's called a one time pad then, it's mostly unpractical since you need to exchange these huge one time keys before use).

There are some other ways it leaks data too, but for just making a common attacked give up having such 'encryption' in a .7z file (since zip is way more common, literally every archive gui tool opens it, even windows explorer) with a different extension (so they don't know instantly it is 7z, although one look at hex editor will tell them that because it says 7z in the header) is enough.

I'd not bother with the xor part personally, just put them in any file with any extension, a dedicated hacker will grab your resources or key from ram, or disassemble your code, or spoil the history using YT. If someone is looking into game files to find dialogues or graphics he didn't see before then he clearly knows the risk so why stop him?

[Wolff]

Yea, I guess there's little to no point in encrypting files then. Also, form what I understood my old project from way back when was literally a xor encryption program hahah, I didn't get that because it's called completely different in my language, it was only able to encrypt .txt files though.
Thanks again for all the help, I've learned a lot!

[FRex]

Yes, I'd say there's little point and if you ever make some mistake in your code that does it that destroys one bit or byte once in a while then you'll spend lots of time trying to find out what's wrong.

But a well made (non-solid and with not too high of a compression ratio) zip or 7z still has a point since one archive is faster to read from than many small files, you can even preload entire archive into RAM which would made it crazy fast or make one file shadow another (for patches, user settings, mods etc.). It'll also be smaller for average end user not only due to compression but also since loose files on disk waste a bit of space due to block size. For development you can still use loose files (that's the point/use of a virtual file system like PHYSFS) and just pack them up when sending the game to people, your game code stays the same.

Just remember to grab latest PHYSFS code from Mercurial since latest stable source code is broken on latest Windows 10 (and badly - you get a failed init + no error message or code at all).