[project1dev] Re: Project1 - SVN Update 754
- From: figarus@xxxxxxxxx
- To: project1dev@xxxxxxxxxxxxx
- Date: Mon, 24 May 2010 18:40:39 +0000
jump on it, it is fun!
On May 24, 2010 2:25pm, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:
lol...
honestly there is an "acheivement" band wagon going on in games right now.
should we jump on or ignore it? :P
On Mon, May 24, 2010 at 11:23 AM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
We could give an OCD award to players who win without taking any damage
On Sun, May 23, 2010 at 6:46 PM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
buildings are a dime a dozen and losing one isn't so detrimental that you
are going to say "oh shit better reload my save"
There's 6 per tile and there will be about 60 tiles in this map that you
can build on so thats 360 buildings.
I dont think anyone will feel motivated to have to take the route that
you are talking about, but someone (such as MONK from tv!) may be ocd
enough that they need a perfect score hehe
On Sun, May 23, 2010 at 6:32 PM, Nick Klotz roracsenshi@xxxxxxxxx> wrote:
If we don't keep building damage, who is to say somebody won't go, "oh
lets repair the buildings real quick", save/quit. BAM! Buildings are okay
again.
On Sat, May 22, 2010 at 4:30 PM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
ok cool
i bet we can handle keepin some global variables in sync to save that
stuff (:
On Sat, May 22, 2010 at 1:17 PM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
That's all we need. I'm cool with that. No need to keep monsters or
building damage.
On Sat, May 22, 2010 at 12:33 PM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
Hey Kent (and whoever else is interested)
I'm thinking for saved games maybe that we would only save...
* What houses you had built in your town and where they were
* Which monster spawners have been destroyed / sealed.
* Any "state" information about the area, such as if the boulder has been
destroyed in the 1st map, and whether you have already killed the bat
boss or not
Everything else would be lost in a save/load. so for instance when you
went into an area or loaded a saved game, there won't be any monsters
spawned yet, there wont be scorch marks on the terrain, there wont be
fires burning (if we add stuff like that) etc.
and im thinking too that when you go from one overworld area to another,
this is all the data that will be preserved too.
does that sound ok to you? Is there any other information that you think
we should be saving?
On Fri, May 21, 2010 at 8:43 PM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
Interesting. You are right its not that complicated when you break it down
On Fri, May 21, 2010 at 4:59 PM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
Josh may change things but here's how i envision it (and how i would do
it if i were writing it)
#1 - the version number
#2 - the hash of all the data stored
#3 - the "encrypted" data
The Version Number
so writing the version number is easy. we'll have an int to store the
version number so the first 4 bytes of a save file will be the version
number. This makes it so if the game wants to load a file and it knows it
uses version 5, but the file says it's version 3, it knows it's
incompatible. You'll be setting the current version number in the
Data_Save and Data_Load script commands.
The Hash
A hash is kind of like a CRC or checksum. Basically imagine that you
looked at every byte in a chunk of data and added it together and that
number it gave you at the end was 42. 42 would be a hash of all that
data. That is a really simple hash, we can use something more complex if
we want like MD5 or something else.
The data saved into the file is just name/value pairs where the value can
be a string or a number. When you set the global variable "PlayerHealth"
to 50, the name value pair is "PlayerHealth",50. So, we make a hash out
of all of the name value pairs and then write that to the file next. What
that does, is if someone tries to manually change a value in the file
(like by using a hex editor), the hash wont match and we'll know they
tampered with it.
They could also alter the hash to make it match, but they'd have to know
how the hash was calculated (which they can see by looking at the machine
code in the exe...) but while this isn't perfect security, it stops
99.999% of the people out there lol
The Data
Next up we need to write the data. we would just write all the name value
pairs into the file. If people open up the file, they would see variable
names like "PlayerHealth" and it would be really obvious that it was
interesting data they might want to try to change.
To further protect our save game files, i would use "xor" (exclusive or)
to xor all the bytes in the data against a constant. if you xor a number
by the same number twice, you get the original number back, so simple xor
is a good way to do poor mans encryption (:
So basically, we'd xor all the bytes in the file against 145 let's say.
That will jumble it all so that if people opened the file it would just
look like garbage. When the data is loaded, it'll be xor'd against 145
again so that it goes back to normal and we get our nice, readable
variable names back.
On Fri, May 21, 2010 at 4:43 PM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
I am totally interested. What more can you tell me
On Fri, May 21, 2010 at 1:28 PM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
i have some ideas, but im going to wait til the town stuff is more worked
out.
basically anything that needs to be saved / loaded has to live in a
global variable, but its ok if some specific data gets lost, such as
scorch marks on the terrain. Those guys don't need to persist across a
save/load :P
We can worry about that stuff later after we get it working, to make sure
things get saved and loaded correctly.
josh is going to work on the actual saving and loading of the global
vars, and the file is going to be not human readable (ie slightly
encrypted) and will be protected from tampering via a stored hash of the
data being compared to hashing the data after load (if they dont match
you know someone screwed with the file). more details available if you
are interested, it's not too complex stuff actually (even if it sounds
complicated)
On Fri, May 21, 2010 at 12:51 PM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
could be interesting. Do you have any save load plans? Is that going to
be something we work on soon or not until the end?
I do all of my saving in a csv format basically. Would you do something
similar or is there more organization that goes into it?
On Fri, May 21, 2010 at 10:25 AM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
cool deal (:
it's going to be interesting making sure our save / load stuff works
right with all the crazy data like how many enemies are alive and what
their positions are, which buildings are damaged or destroyed and all the
other stuff :P
might be a lil work hehe
On Fri, May 21, 2010 at 10:21 AM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
Yeah sounds right.
On Fri, May 21, 2010 at 10:18 AM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
i would just include it into the main menu code
then when they click "main game" (new game) it would call the
gamevars_clear function (that was defined in gamevars.lua). That function
would do a data_clearvars() to kill all global variables, then it would
have a data_createvar() for each global variable the game uses.
since those functions dont exist yet, i think gamevars_clear for now
should just set some starting value to each global variable used in the
game. Like it would set health to 100 or whatever the starting health is.
sound right to you?
On Fri, May 21, 2010 at 9:59 AM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
I think that would cover it. How would you implement gamevars.lua. Would
you just add an include for it in the config lua?
On Fri, May 21, 2010 at 9:08 AM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
cool deal.
I'm also thinking that...
#1 - We need a Data_ClearVars() function which will delete all global
variables. We would call this before loading a game or creating a new
game to make sure no values persisted from one game to another that
shouldn't be there.
#2 - We need a function Data_CreateVar which you have to do before you
can read or write to any variable. If you try to use a variable without
creating it, it will throw an error. I figure we should make a rule that
we are only allowed to use this function inside of gamevars.lua,
specifically in the Gamevars_Clear() function. This makes it so all
global game variables are declared in one space, and if we mis type a
variable name or try to use a variable that doesn't exist, it will throw
an error and we'll see it.
#3 - We'll need a Data_Save and Data_Load function for saving and loading
games, but i'm thinking those guys will take a save game name and a
version number. This way, if you do something to the scripts like add or
remove a global variable, and the save game data is no longer compatible
with the script, you can increment the version number so that Data_Load
will return failure if you try to load a save game of the wrong version
number.
I put these guys on the coding todo list
On Fri, May 21, 2010 at 8:35 AM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
Ok, yeah that makes sense.
On Fri, May 21, 2010 at 8:25 AM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
hrm how about making a file, something like "gamevars.lua" and when they
click "main game" on the main menu (which should be "new game" eventually
hehe) it calls some function from that file such as GameVars_Clear()
which initializes all the game vars to sane values?
On Fri, May 21, 2010 at 7:54 AM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
Think I should put the health variable in the ui.lua or what then? It
only made sense to me to put it in the config.lua
On Thu, May 20, 2010 at 9:44 PM, Alan Wolfe alan.wolfe@xxxxxxxxx> wrote:
oh... config.lua is a special case lua file, it doesnt have access to all
the functions that the other scripts have
the reason is, it runs that file before anything about the engine is set
up.
On Thu, May 20, 2010 at 9:41 PM, Kent Petersen kentkmp@xxxxxxxxx> wrote:
Bug? I don't think global variables are working. Check the config lua
On Thu, May 20, 2010 at 9:40 PM, Apache User
dhapache@xxxxxxxxxxxxxxxxxxx> wrote:
User:korgath
Message: I thought I checked in these files but it looks like I didn't so
I'm checking them in again. Sorry if I did once already
--tried creating global variable for life but it doesnt seem to work
--added life ui to main map (once again life value doesnt work)
--updated bat hold to pop out bats at a different rate
--fixed a type on bat
--fixed a typo on trollhut
U ActRaiser/Scripts/Enemies/OverWorld/Bat.lua
U ActRaiser/Scripts/Enemies/OverWorld/BatHole.lua
U ActRaiser/Scripts/Enemies/OverWorld/TrollHut.lua
U ActRaiser/Scripts/GameOverworld/UI.lua
U ActRaiser/Scripts/config.lua
==============================
Project 1 Dev mailing list
to unsubscribe, please send an email request to demofox@xxxxxxxxxxx
Project 1 website: http://project1.demofox.org
Project 1 SVN repository: http://pyotek.com/project1
Other related posts:
