Jump to content

  • Log In with Google      Sign In   
  • Create Account


File input/output in C++ Question


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
13 replies to this topic

#1 mikenovemberoscar   Members   -  Reputation: 215

Like
0Likes
Like

Posted 02 January 2013 - 01:44 PM

Hi all,

 

I am making a game in Visual C++ 2010, and I want to have my levels stored as text files generated by my level editor.

 

I know how to make it so the compiled finished executables can read files from a fixed path (C:/etc/etc), and a rough idea of how to make it read files relative to the executable itself.

 

But how do I make it so I can include a level file (in my Visual C++ solution) which is read by the program at runtime (using file streams) - but will be packaged with the executable when compiled and finished and invisible to the users?

 

 

Thanks in advance,

 

mikenovemberoscar



Sponsor:

#2 Álvaro   Crossbones+   -  Reputation: 12365

Like
0Likes
Like

Posted 02 January 2013 - 01:52 PM

I am not sure what functions you are using for file access, but they typically specify the name of the file as a `char const *'. You should probably use `std::string' for most things, and when it is time to call the function that expects a `char const *' you can use `my_string.c_str()'.

#3 lride   Members   -  Reputation: 633

Like
1Likes
Like

Posted 02 January 2013 - 02:18 PM

The program will look for the file in the executable's directory.

You can't really make your level files invisible, but you can hide them by packing all your level files in a "level" folder and placing the folder in your executable's directory.

Then you can load the levels like

 

loadLevel("level/level1.txt");

loadLevel("level/level2.txt");


Edited by lride, 02 January 2013 - 02:21 PM.

An invisible text.

#4 rip-off   Moderators   -  Reputation: 7963

Like
0Likes
Like

Posted 02 January 2013 - 04:02 PM

If you aren't using files, you don't need to use file streams. If you are bundling your data into the executable, it is at some level merely memory that you are reading. I believe there are APIs for reading resources in Windows for example, but I don't have any experience with them so I will say no more.

 

One option is to use something like physfs and bundle all the resources for your game into a second file. So you end up with two files, your "game.exe" and your "game.data" (or whatever you want to call it). The data file is actually some kind of ZIP archive containing the same directory layout you use during development.



#5 SiCrane   Moderators   -  Reputation: 9490

Like
0Likes
Like

Posted 02 January 2013 - 04:32 PM

If you go the Windows resources route, the relevant loading functions are FindResource(), LoadResource() and LockResource(). In many cases you'll also want to use SizeofResource().

That said, I prefer using a renamed zip file with PhysFS.

#6 mikenovemberoscar   Members   -  Reputation: 215

Like
0Likes
Like

Posted 03 January 2013 - 06:02 AM

Okay thanks all,

If you are bundling your data into the executable, it is at some level merely memory that you are reading
Yeah this one.

I can include header files and use them in my game, but they aren't invisible to the end user?
Can I do the same thing with level files? I like the idea of resource files (.rez if i remember correctly?) but most professional games nowadays can be run with just the executable, or am I missing something?

Sorry I'm kind of new to Windows.

Edited by mikenovemberoscar, 03 January 2013 - 06:03 AM.


#7 Bacterius   Crossbones+   -  Reputation: 8285

Like
0Likes
Like

Posted 03 January 2013 - 07:04 AM

Can I do the same thing with level files? I like the idea of resource files (.rez if i remember correctly?) but most professional games nowadays can be run with just the executable, or am I missing something?

Resources are embedded inside the executable, so I suppose yes. That said, I don't know many AAA games that can be run with just an executable, usually they have a data folder containing tons of data. If the game packed everything inside a single .exe, that file would be absurdly large and it would make patching rather difficult.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#8 mikenovemberoscar   Members   -  Reputation: 215

Like
0Likes
Like

Posted 03 January 2013 - 08:18 AM

Ah I see... I examined my games and I realise they're all shortcuts. But can't resource files be read and modified by the user?



#9 Bacterius   Crossbones+   -  Reputation: 8285

Like
0Likes
Like

Posted 03 January 2013 - 08:46 AM

Ah I see... I examined my games and I realise they're all shortcuts. But can't resource files be read and modified by the user?

 

Yes, they can, just like everything else on their computer. There is no good rationale to actively prevent the user from modifying data files, at least in a single player game. If the player wants to mess with the data files (perhaps to edit textures or change stats) you should let him. It's not like it's harming anyone, and it adds replay value to the game in the form of unofficial modding.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#10 mikenovemberoscar   Members   -  Reputation: 215

Like
0Likes
Like

Posted 03 January 2013 - 08:58 AM

Well I see your point, but what if my game was multiplayer? Just write the files in a binary format and hope for the best?



#11 Bacterius   Crossbones+   -  Reputation: 8285

Like
0Likes
Like

Posted 03 January 2013 - 09:04 AM

Well I see your point, but what if my game was multiplayer? Just write the files in a binary format and hope for the best?

 

There is not much you can do against a determined attacker. Whatever is on his computer can be read and modified by design. You cannot prevent that short of keeping assets away from the user and rendering the game on dedicated servers, delivering the results via the internet (see OnLive) which is really overkill. And even then he might still be able to recover the assets to some extent (e.g. stare at a wall and screenshot the texture on his computer). It's just not a 100% solvable problem in practice.

 

To be honest, just packing all your assets in a zip file and renaming the extension will discourage 99.9% of people out there from snooping into your assets. That's probably good enough unless you have an AAA game in the works.

 

Basically, you are attempting to solve the DRM problem, which in short is "how do I make sure someone cannot copy X while still having access to it" which is fundamentally flawed in the abstract computer realm, because while it is difficult to replicate a physical object, all information in the form of bits (i.e. everything on a computer) can by definition be copied.


Edited by Bacterius, 03 January 2013 - 09:07 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#12 mikenovemberoscar   Members   -  Reputation: 215

Like
1Likes
Like

Posted 03 January 2013 - 09:22 AM

Woah. I can see what you mean now Bacterius, and yeah I'll probably do what you said with the zip file. Thats an interesting point with the DRM problem.

 

Thanks very much for taking time to share your knowledge :)

 

mikenovemberoscar



#13 Shannon Barber   Moderators   -  Reputation: 1361

Like
0Likes
Like

Posted 04 January 2013 - 12:15 AM

Well I see your point, but what if my game was multiplayer? Just write the files in a binary format and hope for the best?

 

If it's that important, you send the client a 'seed' value, hash the file with it, and send the results to the server.

Only the server knows the correct result to the challenge and since the seed value keeps changing they can't just send you the correct result from last time you asked.

And that's the start of cryptography...


- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

#14 Bacterius   Crossbones+   -  Reputation: 8285

Like
0Likes
Like

Posted 04 January 2013 - 12:19 AM

Well I see your point, but what if my game was multiplayer? Just write the files in a binary format and hope for the best?

 

If it's that important, you send the client a 'seed' value, hash the file with it, and send the results to the server.

Only the server knows the correct result to the challenge and since the seed value keeps changing they can't just send you the correct result from last time you asked.

And that's the start of cryptography...

 

That would not help, the pirate would just keep the original assets stashed somewhere, hash them for verification, then go back to using the altered ones.

 

Cryptography does not help, it solves an entirely different problem.


Edited by Bacterius, 04 January 2013 - 12:21 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS