Post #99,881
5/2/03 11:38:35 AM
|
Some points to consider:
1) XML is for data that needs to be human-readable/writable. 2) Do the files need to be "secure", to prevent people from tampering with their own games. 3) Python has a built-in binary object save format (see the 'pickle' and 'shelve' modules). No need to invent your own if you go binary.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #99,885
5/2/03 11:50:50 AM
|
The data needs to be human readable/writeable.
The philosophy is to write a decent "base" for strategy games, then toss it out there for people to play with, and see what they come up with.
Besides, as history has shown us, save file hacking tends to be very easy even if the author tries to encrypt it. IMO, if somebody wants to hack their data file, that's their problem, not mine.
If I can figure out multiplayer, it will be a server/client setup - this will avoid the "trusted" issue, by putting the "trust" in the hands of the person running the server.
After 9/11, Bush made two statements: 1. "Terrorists hate America because America is a land of freedom and opportunity." 2. "We intend to attack the root causes of terrorism."
Sounds like everything is going according to plan.
|
Post #99,886
5/2/03 11:56:23 AM
|
Use XML then.
XML is a steaming pile of cack when it is used for the wrong reasons.
Here, you have 1) structured data that 2) needs to be human-friendly.
Of course, the alternative is a database, but if you want people to be able to pass their files around that becomes a bit problematic.
Python has fairly good XML support. If this were Objective C I'd point you in the direction of ObjC property files. But it isn't. So I won't. :-)
Now, you could play with incorporating ObjC into your Python, or the other way around...
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #99,888
5/2/03 12:04:44 PM
|
Damn, it's a reeses commercial!
"You got Python in my ObjectiveC!" && "You got ObjectiveC in my Python!"
Muah.
Don't know much about ObjectiveC - how cross-platform is it?
After 9/11, Bush made two statements: 1. "Terrorists hate America because America is a land of freedom and opportunity." 2. "We intend to attack the root causes of terrorism."
Sounds like everything is going according to plan.
|
Post #99,890
5/2/03 12:12:10 PM
|
Anywhere you can run gcc - with a caveat:
Objective C is as easy to learn as Python. It has C and C-- beat nine ways from Sunday, too. I plan on using ObjC for any personal C-family programming I need to do in the future.
Now, the caveat: in order for ObjC to be truly useful, you need to install the GNUstep libraries. This gives you collection classes, string classes, etc. I do not know how cross-platform GNUstep is, but I'm sure that's easy to check.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #99,932
5/2/03 2:11:56 PM
|
Re: Anywhere you can run gcc - with a caveat:
Amazing how right Todd always is, ain't it?
-drl
|
Post #99,945
5/2/03 3:21:46 PM
8/21/07 6:23:40 AM
|
PyObjC
There is a python bridge to ObjectiveC so you can have your cake and still get fat.
[link|http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html|http://www.macdevcen...1/pyobjc_one.html]
But if you can use ObjectiveC then I'd recommend FScript for your scripting environment.
[link|http://www.fscript.org|http://www.fscript.org]
I have a lovely fscript/clips/Objective C bridge for doing expert systems using Objective C objects as facts and fscripts as rule actions.
If you are going to do a serialization format then I recommend PLists (ObjectiveC style property lists). The parser is *very* easy to write (compared to dealing with xml parsers). I have one you can have in Java - porting it should be easy. A PList element is a dictionary, list, or string.
{ key1 = value1; key2 = value2; } // this is a dictionary ( one, two, three ) // this is a list a string is either a token (letters, underbars, and numbers with no spaces or punctuation) or it is quoted and follows C-style escaping conventions (ie \\n is newline, \\t is tab).
You can combine these in any combination. Example
{ CDCollection = ( { artist = Prince; title = 1999; tracks = (); }, { artist = "Thomas Dolby"; title = "Aliens Ate My Buick"; tracks = ( "Key to her Ferrari", Airhead, "Hot Sauce", "Budapest by Blimp"); }, { artist = Eurithmics; title = 1984; tracks = (); }); Owner = "Todd Blanchard"; }
With a little extension (found in ObjectiveC and in my java lib) you can use keyvalue coding to do extractions. For instance:
[dict valueForKeyPath: @"CDCollection.artist"]
Will return a list of artists. This is amazingly handy for binding complex data locations to GUI elements.
So there's a lot to like about PLists as a serialization format. They are readable and you can read/write them in one statement.
I steer clear of XML whenever possible.
"Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
|
Post #99,952
5/2/03 3:57:03 PM
|
plist parsers...
I didn't think you needed to write a parser for that... just use the NSData dataWithContentsOfFile: method.
PyObjC looks very cool... one less thing that I need to write now. ;-) I can't tell from the website whether it's OS-X only or not.
I'd have the same question about f-script. The advantage of using Python is that the knowledge has wide application.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #99,955
5/2/03 4:08:47 PM
8/21/07 6:23:49 AM
|
Re: plist parsers...
Right, you don't need to write a parser if you're using ObjectiveC - its baked in. But if you're using Java, or Python sans ObjC, you will need to write one (well, for Java you can use mine). I don't have one in Python though.
FScript is basically smalltalk scripting using ObjectiveC objects. It does math with NSNumbers and supports Blocks (something we miss very much in ObjectiveC).
So you can do something like:
myNSArray do: [:ea | ea doSomethingCool].
Its just smalltalk scripting though - it has no support for making new classes. OTOH, you can pass around FScript Blocks - which are arbitrary code. If you're doing ObjectiveC and you need to provide user scripting, FScript is the bomb.
There's been a nifty hack called FScriptAnywhere that will fiddle an application's framework list to pull in FScript and put an FScript menu item on the menubar. There's also a GUI object inspector/navigator that you can use to dig around in a program. So you can monkey with objects in other people's applications and add new menu commands. Its pretty cool.
"Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
|
Post #99,912
5/2/03 1:04:55 PM
|
First co-op project?
The philosophy is to write a decent "base" for strategy games, then toss it out there for people to play with, and see what they come up with.
Then you need to write an abstract StorageManager class, and provide at least one concrete instantiation of that class in the form of your choice: XML, pickles, what-have-you. In Python, you can write abstract classes by def'ing the methods, and just using 'pass' for their content. def aMethod(foo): pass
Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
|
Post #99,917
5/2/03 1:13:51 PM
|
(Which will be great when I grok WTF that means... ;-) )
|
Post #100,183
5/3/03 11:08:40 PM
|
It basically means
..that you write a parent class from which the actual storage mechanisms will inherit. IOW, you write an interface and set that in stone. Then you write a tool which implements that interface, whether that be XML, flat-file, database, what-have-you. If someone else wants to implement the same set of operations with a pickle storage mechanism, they are welcome to do so. The rest of your program only needs to know that, when it's time to save state to disk, it calls childclass.saveGame() or equivalents. Since each possible way-of-saving uses the same interface (i.e. - the same set of methods and properties, which they inherit and override from the parent class), the rest of your program doesn't need to care which storage mechanism is used. This is a common design pattern, and allows you to:
1) Write the rest of your program without forcing it to "know" how data is stored, 2) Have multiple storage mechanisms in the same application, 3) Solicit multiple mechanisms from multiple programmers, at various times in the project lifecycle (even after it's released), 4) Write temporary classes which allow you to test the functionality of other parts of the app before you've finished coding the storage mechanism, 5) I could go on and on. I'll stop now.
In the design of an application, whenever you ask yourself, "which way should I implement this?", the first answer that comes to your mind should be, "all ways". Then you can pare down from there. :)
Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
|
Post #100,213
5/4/03 8:54:45 AM
|
On the other hand...
"Do the simplest thing that works."
If you end up with more framework code than instance code, you've wasted your time. If you end up with only one way of saving things because it's sufficient, then you've wasted your time. If you get all the way through your framework implementation, and then when it's time to do a second instance implementation you discover that your frameork is too inflexible to add a second instance easily, then you've wasted your time.
I don't usually generalize something until the second or third time I do the same kind of functionality.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #100,215
5/4/03 9:01:59 AM
|
On the gripping hand:
If the interface will be simple enough to get right the first time, go ahead and build it.
Here's an article on the factory pattern:
[link|http://www.developer.com/tech/article.php/626161|http://www.developer...rticle.php/626161]
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #100,237
5/4/03 12:32:34 PM
|
True
I don't usually generalize something until the second or third time I do the same kind of functionality. I usually don't either, especially for new territory. But I've abstracted state-saving mechanisms often enough that it's now second-nature, and I can't imagine doing a project without it. :) Thanks for the link on the factory pattern.
Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
|