Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Command line vs. config file  (Read 2900 times)
0 Members and 1 Guest are viewing this topic.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Posted 2003-10-12 15:39:22 »

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'.  Shocked

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?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #1 - Posted 2003-10-12 15:47:14 »

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.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #2 - Posted 2003-10-12 15:58:26 »

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..

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2003-10-12 17:28:04 »

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

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #4 - Posted 2003-10-12 19:02:41 »

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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2003-10-12 19:57:01 »

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

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2003-10-12 23:10:47 »

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.


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.).

malloc will be first against the wall when the revolution comes...
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #7 - Posted 2003-10-13 00:10:51 »

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 Smiley

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #8 - Posted 2003-10-13 04:49:08 »

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

1  
2  
3  
4  
5  
6  
[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.

Offline tortoise

Junior Member




<3 Shmups


« Reply #9 - Posted 2003-10-13 07:22:55 »

Quote
Command line arguments arn't "pure java"


Sure they are. main() must accept a String array for a reason. Not to mention the JVM itself accepts many command line args.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #10 - Posted 2003-10-13 07:50:41 »

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

Kev

Offline Smoke

Senior Newbie




games rock!


« Reply #11 - Posted 2003-10-13 12:23:05 »

the value of "pure java" for games  is mysterious... Grin

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.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #12 - Posted 2003-10-13 12:53:31 »

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.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #13 - Posted 2003-10-13 13:35:48 »

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.


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.
</rant>

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

malloc will be first against the wall when the revolution comes...
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #14 - Posted 2003-10-15 00:28:44 »

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.

Offline tortoise

Junior Member




<3 Shmups


« Reply #15 - Posted 2003-10-15 00:37:30 »

Quote

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?


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.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (18 views)
2014-07-29 18:09:19

Riven (13 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (30 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (41 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (29 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!