Well now - what a simple but interesting question to tackle.
When reloading a level there are so many factors that need to be taken into account that the answer can go many ways.
If your level state contains a large list of assets it can be more practical to start from a clean slate when reloading a level back to a save/mission state as this maintains the ...
To clarify the existing answers against your question about consoles: they don't have enough memory to store both the starting state and current state for larger complex games.
A game could store the level and initial state separately so that just the state could be restreamed in, and this is very likely what many games do. Even streaming just that is ...
There is no such directory; %APPDATA% is Windows-specific. You'll have to abstract it yourself: create your own GetSaveGameDirectory function that returns an appropriate path on whatever operating system you're running on. You can typically make this determination at compile time with preprocessor checks against the appropriate macros in C (and it's ilk). I'...
I'm using this code on my game right now:
Simple and efficient.
It's a user dependent directory, which is perfectly fine for storing save files. I'm using it to download and store assets, though.
I disagree with much of Blue's answer, I do not believe there is a technical case for not resetting levels - I certainly never encountered one. Level loading is almost always slower than level resetting, in fact I find it difficult to conceive of an occasion when it wouldn't be. In most cases games could offer effectively instant level loading if the devs ...
On Windows, you can shove everything under an architecture directory:
You need 64-bit DLLs to go with the 64-bit .executable, you can't load 32-bit ones into a 64-bit process. The Windows DLL search order will check the .exe directory.
This does mean duplicating ...
With Sean and Blue's excellent answers regarding physical platform limitations and pro-con decisions, I'm going to expand a comment into a different approach:
Why You Should Probably Just Completely Reload The Level
So you've got your loadLevel() call working perfectly, yay! You stream in a level file information, and step through building the world based ...
To allow for large levels or seamless level game play, even with limited memory (memory is always too small, the question is if you hit the limit in RAM first, or on the graphics card) there is another strategy:
Only have the part of the level in memory, that the player needs currently or will need in a few seconds. Models, textures, sound samples, ... ...
When in doubt, always read the docs for the methods you're using:
Loads all assets in a folder or file at path in a
If path refers to a folder, all assets in the folder will be returned.
If path refers to a file, only that asset will be returned. The path
is relative to any Resources folder inside the Assets ...
On Linux, the only standardized path would be the XDG_DATA_HOME and XDG_CONFIG_HOME directories. Use the environmental variables with those names if they exist, otherwise default to $HOME/.local/share/<appname>/ for user-data (saves, progress, player profile) and $HOME/.config/<appname>/ for configuration. Deleting the latter directory should in ...
The games that have nothing but an .exe have compiled their executable with the assets inside. This is generally poor practice. By embedding your assets into the executable, they will stay loaded into memory while the program is running, even when not in use. For your scale and with modern machines this might not be much of an issue, but as the executable ...
First, to explain the problem you ran into trying to access file://:
Now, first ask yourself the question: Is it ...
Can we change a file's extension ("file.png" to "file.abc") and read it as if it had the same extension?
It depends on your framework. I don't know about libGDX, but some framework will open the file based on its extension, so renaming the file will not work. It's easily testable with a simple application.
How can I put multiple files into same file, ...
If you're writing to the local area (Where the app is stored) then don't use the external file type. The correct type to use is local as the local type will store it in the same folder as the app. The problem with external is that external reads from the root directory onward. So on Windows the external path would need to specify the drive and other such ...
The final solution I chose is very simple, and avoids any changes to existing code / path files:
In the main function, first make a call to chdir("../")
This will make static DLL loading work from the x32/ or x64/ folder, while all runtime data can be loaded as if the executable was in the main folder.
Such a method is even necessary if you have a DLL you ...
You can certainly do all of this by simply storing the move list for a game in a text file. That would be the simplest way to store the data, but at the expense of forcing you to build all of the query mechanisms yourself.
Something more structured like an XML or JSON file will probably make querying slightly easier (since you are on iOS, you may want to ...
I finally understand about Preferences. Here's the example and observe the comments. Take note that this is sample from my previous projects.
public class Temporary_Database
//TODO __________[ Field data ]__________
public Preferences pref_1;
public Preferences pref_2;
public String male_name;
public String female_name;
As Josh mentioned, don't hardcode paths - use the OS API to use the correct path:-)
The .love files are actually renamed .zip files. These zip files contain directory structures, so if your code refers to, say, "foo/bar.dat", your zip file has to have a "foo" directory with the "bar.dat" contained within.
See http://love2d.org/wiki/Game_Distribution for details.