Command line vs. config file

General Discussions
#1

I need some method of telling my app to start up in either the scene editor mode (for creating scenes, scripting etc.) or in game mode which is the actual playable mode. Game mode also automatically switches on the game logic and loads an initial scene to start the game from.

So basically on startup i need a flag for editor or game mode, and an optional string for the scene file to load.

I was thinking of doing this via command line flags, similar to Quakes method of using command args to set a mod dir, the scene file defines the game type etc. to load. But while looking for info i found this http://java.sun.com/docs/books/tutorial/essential/attributes/cmdLineArgs.html which lists command args as ‘not pure java’. :o

Now i’ll likely need different command line settings for different games anyway (to load different plugin jars), but on the other hand i’ve already got a config file that could be used to get this info from (although its just a single config, so multiple games in a single dir could get annoying to keep changing it).

So, which looks more likely? Are command line args really that much of a liability for people with Macs and such? Or should i not worry about it and just use the command line since it gives me more flexibility?

#2

Why not provide a menu option, or if your design doesn’t support that then perhaps an initial dialog box allowing the user to choose? This could be used in addition to command line args to give the user an option. Changing the config file to switch modes would get annoying, methinks.

#3

Well the idea is that the end user doesn’t really care about these options, which is why i wanted to avoid any sort of GUI.

Editor/game switch: Only the actual level designer needs to run with the editor, so maybe it should default to game mode unless this is specified.

Scene filename: If you’re running an actual game, you need to start from some level, then you can take over from there. Again the gamer shouldn’t care, they just want to run the game. But each game would need a different scene file to start from… which makes it unsuitable for the config file i think…

#4

Set a system property on the command line, thats what I always do. Command line arguments arn’t “pure java” but system properties are.

I normally have a BootStrap class which detects the system property and calls the main in the appropriate class.

Kev

#5

Hmm… I’ve not used the system properties before, thats the same mechanism that lets you turn on accelerated rotations and such in J2D, yes? Any hints at where to look for examples?

I’ve actually got a basic command line working now, is there anything specific that system properties gain me?

Cheers

#6

Not really tbh. I suppose command line isn’t considered “pure java” because the VM doesn’t guarantee that it will have a command line.

However, it doesn’t guarantee that you can set properties somehow (at least I think it does). Your only gain would be the “pure java” stamp.

Setting system properties at command line looks like:

java -Dgame.mode=server MyMainClass

Accessing them looks like:

String mode = System.getProperty(“game.mode”);

Its about as complicated as it gets.

Kev

#7

[quote]Well the idea is that the end user doesn’t really care about these options, which is why i wanted to avoid any sort of GUI.

Editor/game switch: Only the actual level designer needs to run with the editor, so maybe it should default to game mode unless this is specified.
[/quote]
Where it’s just a matter of picking a different mode, I usually just make separate jar files for each app, and they only contain a single class, with a main method relevant for that mode of the app.

One of the benefits is that if the requirements of the main methods diverge, no problemo.

You just have to have a “main.jar” which is big and has everything in, and then tiny “editor.jar” and “game.jar” etc, each of which uses the manifest option that lets you include other jar files (n.b. massive flaw in the design of “java -jar” - it IGNORES any jar files referenced in the classpath (when is a classpath not a classpath? hmm…). So you have to use this instead.).

#8

A neat solution, this is similar to my expectation of using different batch files to launch different modes (with different command args), but more crossplatform :slight_smile:

Think i’ll stick with my command line version for now, and if need be I can add these wrapper jar files later on to set the correct parameters for the .main() method.

#9

I wrote an INI reading program which can read basic .ini files eg.


[MAIN]
argument1=true

[game]
startinglevel=1
lives=9

If you download my photo gallery program http://tanksoftware.com/gallmage/v2/ you can see the source (com/tanksoftware/io/*) The code’s open soruce (GPL - but I might change it to BSD in the future).

This is how I enable my programs to read/write settings.

Tell me if you are interested and I’ll clean it up a bit.

Will.

#10

[quote]Command line arguments arn’t “pure java”
[/quote]
Sure they are. main() must accept a String array for a reason. Not to mention the JVM itself accepts many command line args.

#11

Good point, I guess the question should be, who the hell wrote the section on java.sun.com…

Kev

#12

the value of “pure java” for games is mysterious… ;D

i’d certainly go with wrapper files:
its what the user expects; one file to click to start the game, another one to start editor/server/whatever.
you could also easily have all kind of params for debugging and testing.

#13

GUI-less java apps are pretty useless without arguments afterall…

I used to like executable jar’s but I find now that (most of the time) batch files / shell scripts are more versatile.

Will.

#14

[quote]GUI-less java apps are pretty useless without arguments afterall…

I used to like executable jar’s but I find now that (most of the time) batch files / shell scripts are more versatile.

Will.
[/quote]
FWLIW, I go out of my way to avoid java apps that faff about with shell scripts and the like. If I want a platform-dependent application, I’ll find a version that was written in C++.

I’m not claiming you can do everything with a JAR (although, in theory, you can, in practice it may be too much effort), but usually when I see shell scripts etc in place of executable JAR’s it’s programmer ignorance or a badly-designed app.

P.S. Linux kernel allows me to run java apps directly just by typing their names…so AFAICS I get no benefit from a shellscript invoked app?

<rant - in the hope of persuading people to use JAR’s>
It drives me up teh wall when sourceforge projects distribute a java app as a ZIP file !!! For [deity]'s sake! This is insane! All it means is that everyone has to unpack the damn thing before they can run it. In most cases, there’s a JAR file inside the ZIP file, and it’s not even got a manifest-MainClass…so you have to use some crappy shell script to run the JAR.

Supproting the same app cross-platform (as an administrator, or just as a user with multiple OS’s) is much harder when you have extra files for particular platforms.

And then the shellscript often doesn’t work anyway (due to variety of different shells people use, or plain broken scripts).

The world of JAR’s is beautiful (*) - entirely self-contained programs, all in one file, easy to manage, easy to backup, easy to copy. And it works on all platforms where the app runs. Even when an app uses multiple JAR’s, it’s really simple to administer - when I have to keep track of several files of different types, some of which may not show up because of hidden files settings etc, it’s a complete pain.

(*) = except that they don’t have any versioning support that doesn’t suck.

#15

woah, didn’t mean to start a religious war :wink:

I use linux too so platform independance is very high on my list. I also have nothing against executable jars - I think jars should be (why not?) but even when I do I’ll ship a .bat file along with them for windows users (some programs such as WinRAR actually steal the .jar file association from Java being one reason).

I think it is very over the top to say that a java program with a shell script is comparable to C++ in terms of portability. If the script doesn’t work you can always just open it and paste the java command directly into your shell. Users of these systems are hardly beginners.

On your other point (one single jar file for an application). What’s so bad about having to unzip a program into a directory? You expect everything to be in the single jar file? Take my app for example - when install it, there is a directory “conf” with some .ini files that the user can tweak. If I had them hidden in a .jar file nobody would ever see them. I think you are making a rather broad generalisation here. I couldn’t disagree more with your theory that All java programs should be a single jar. Some perhaps are suited to that but certainly not ALL.

Will.

#16

I’m thinking an operating system kernel is a bit more system dependent than a script.

And all the kernel really does is the equivalent of typing “java” for you. It doesn’t handle jars or classpath issues. It’s also a complete pain in the ass to set up (or at least it was about a year ago). I wisely decided typing 5 extra characters wouldn’t kill me.