151–160 of 265 posts
Earlier quoted context omitted.
That's how people are going to cheat at your game.
Cheating is good, I remember having tons of fun with age of empires and sim city because I used cheat codes. If the player has fun, it's a nice feature! :D
On the game I'm currently working on, it's built very heavily around Lua. So for the save system, we simply fill a large Lua table, and then write that to disk, as Lua code. The 'save' file then simply becomes a Lua file that can be read directly into Lua. This is absolutely amazing for debugging purposes. Also you never have to worry about corrupt save files or anything of it's ilk. Development is easier, diagnosing…
You probably know this, but remember that storing user data as code is a place where you (general "you") have to think very carefully about security. Is there any way that arbitrary code in the file could compromise the user's system? If so, does the user know to treat these data files as executables? Is there any way someone untrusted could ever edit the file without the user's knowledge? Even in combination with ot…
But it's still code, so you can e.g. inject an infinite loop and the loader will hang. (You can protect against this, you can install a debug hook that gets called after every N instructions executed, and kill the loader.)
Earlier quoted context omitted.
That's how people are going to cheat at your game.
Hash the information and include the hash in the file. If the hash and the contents don't match when you try to load it, you can refuse it. If not loading things is important to you, mind.
On the game I'm currently working on, it's built very heavily around Lua. So for the save system, we simply fill a large Lua table, and then write that to disk, as Lua code. The 'save' file then simply becomes a Lua file that can be read directly into Lua. This is absolutely amazing for debugging purposes. Also you never have to worry about corrupt save files or anything of it's ilk. Development is easier, diagnosing…
You probably know this, but remember that storing user data as code is a place where you (general "you") have to think very carefully about security. Is there any way that arbitrary code in the file could compromise the user's system? If so, does the user know to treat these data files as executables? Is there any way someone untrusted could ever edit the file without the user's knowledge? Even in combination with ot…
1. http://stackoverflow.com/questions/1224708/how-can-i-create-...
2. http://stackoverflow.com/questions/4134114/capabilities-for-...
I find it easier to trust Lua than similar facilities in other programming languages because the kernel of the language has a relatively simple semantics, so the TCB of a sandbox is lower, and the source is easier to understand than most other languages.
Note that sandboxing in Lua 5.2 has a still simpler semantics than for Lua 5.1 - few other languages evolve in a way that makes the language easier to trust.
Why reinvent on-disk data formats when you can just make a file of protocol buffers? https://code.google.com/p/protobuf/
Earlier quoted context omitted.
The issues in the randyfay.com post are due to a misunderstanding when using git as a "centralized" repo like SVN. Git, by design, does not enforce a central repo even if you designate one logically. These issues can be completely avoided if you merge the right way: http://tech.novapost.fr/merging-the-right-way-en.html
Well, that confirms that the "obvious" workflow of "git pull" is dangerous. At least it explains all the spurious merges. Why on earth did it ship with this broken design? Why doesn't git pull do the right thing by default?
Why doesn't Windows do the right thing by default?
Oh, its because a different system behaves differently.
DVCS is fundamentally more complex than VCS.
xml haters!!! using other formats how can I define DTDs?
I just realized that Linus' posts are the only reason I ever go to Google Plus.
Earlier quoted context omitted.
The issues in the randyfay.com post are due to a misunderstanding when using git as a "centralized" repo like SVN. Git, by design, does not enforce a central repo even if you designate one logically. These issues can be completely avoided if you merge the right way: http://tech.novapost.fr/merging-the-right-way-en.html
Well, that confirms that the "obvious" workflow of "git pull" is dangerous. At least it explains all the spurious merges. Why on earth did it ship with this broken design? Why doesn't git pull do the right thing by default?
I guess maybe the reason git doesn't do this by default might be because the idea of rebasing early on (the "omg you're overwriting history in a RCS!!!!!") was a bit taboo and it's taken time for people to get used to the idea. Note that I'm just speculating about that, I did follow the git discussion early on and I know that people then (and still are to some degree) afraid of "rewriting history" (note that I quote that because I don't really see it that way).