• Advertisement
Sign in to follow this  

Unity Silent Expectations : The Command Line

This topic is 4216 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well that was a weird title. :) Anyway, it wasn't long ago when I suddenly realised I've been doing all this programming in my spare time as I make my way though college and I don't really have anything physical to show for all my hard work. So I finally pulled it together and took up the challenge of making a game engine. Part way though this question struck me (the bastard) and I though I would put it to the GameDev community to see what your expectations of the command line are. So here's the problem, you have a number of executables that make of the base of your game engine:
  • Runtime
  • Dedicated Server
  • Installer (Un-installer)
  • Editor
All of these executables can take command line arguments that can cause them to do any number of things from altering the way they deploy to getting them to perform a task in the background. The question is what command line arguments would you as developers, gamers and modders expect these apps to take. So I though I would give a format and if you happened to swing by this thread and have some spare time on your hands you could add to it :) [Applicaton] Title: Rank: <1..10> Description: CMD: Example: (optional) For Example: [Runtime] Title: Safe Mode Rank: 10 Description: Causes the runtime to start-up in its most basic state with all advanced features disabled, usually used to changed settings after a unexpected crash. CMD: -s Example: runtime.exe -s

Share this post


Link to post
Share on other sites
Advertisement
I'd expect some resolution and graphics settings, such as fixing the resolution to 640x48 and forcing to windowed and such.

Dave

Share this post


Link to post
Share on other sites
All this stuff is probably in configuration files anyway - so why not just a single command line parameter to set an arbitrary config value?

Share this post


Link to post
Share on other sites
If you have a config file I would make it so you can pass in any command line options to override the config file. If the parameters don't match a config option, simply ignore it.

A lot of the parameters are probably going to be related to the graphics device initialization.

Share this post


Link to post
Share on other sites
To be honest, command line configuration is rather annoying for pretty much everyone but the developer. That being said, I find it's fairly convenient to have a fullscreen flag (I use "-f") to toggle fullscreen on and off for development purposes. It's nice being able to see your game how it's meant to be seen, but fullscreen is a pain to debug.

Share this post


Link to post
Share on other sites
Hey guys, thanks for your replies.
@Deyja: Yeah, configuration files seem like the way to go, I'm thinking of using XML for mine I just hope it doesn't make them too messy to navigate in simple text editors.

I guess in most cases the app should be able to pull most of the information at runtime if there are no arguments or configuration file. e.g. Using current screen resolution and bit depth by default, and searching directories for media paths and such.

Share this post


Link to post
Share on other sites
I agree about configuration. On top of that, the runtime should have the ability to pass in a filename of a savegame (if you have them) which will load that save as quickly as possible. This lets you associate savegame files with your game, so that players can find them and open them from Explorer or whatever. An analogous option for the editor is pretty much a given as well.

The only other option that I personally find useful is some kind of "skip unnecessary crap" mode for development - cuts past intro movies, eliminates menus that aren't needed, etc. The usefulness of that depends highly on your game/tools, though.

All of the stuff you've listed sounds like GUI (or at least highly interactive) stuff, so the command line really isn't the most useful way to use those things. Convertor tools, log analyzers/scrubbers, etc. tend to have far more interesting command line support.


Aside from that... best I can suggest is to look hard at any capabilities you have in each program (or want to have), and if they don't make sense as config-file options, slap them onto the command line.

Share this post


Link to post
Share on other sites
Quote:
Original post by CorpseProject_Admin
using XML

Probably more trouble than it's worth. I made an XML based CMS and from that experience I have learned the following.

1) XML's only real advantage is portability, due to its popularitiy its guaranteed to be a "readable" format. That does not mean that it will make sense to the reader, but hey, you can view in internet explorer... Although I agree that XML editors are a good thing. Regardless, you probably don't need anything to read your config file other than your game and the software you make for it.
2) XML requires a complex parser and lots of support code. Regardless of how "self describing" it is claimed to be, it still will not have any use in your software until you program a meaning for it into every tool that needs it.
3) The alternatives to XML are almost always superior. In my case (for the CMS) MySQL would have been better, unfortunately I had no SQL options. For your case a simple text file is probably a superior choice. I've heard of using XML for a logger format but a simple text file can do all of the same things without the bulk.
4) If XML makes sense anywhere it is in internet communication. When you need communcation between two servers using different technology made by different companies then XML's portability is an advantage. Unfortuantely, even there you still need a standardized format (SOAP, WSDL, RSS, Atom) despite it's alleged "self describing" nature.

As a config file format in text you could have something as simple as, a variable name, a colon, a value (text/int/float), and an endl. That would be incredibly easy to parse, especially if you restrict variable names to not having spaces, tabs, or colons. That way you can ignore white space, and once you hit the colon you know that the value is the next thing that needs to be read.

I could write a parser for that in minutes, but that is only one suggestion. Using a text file of your design is likely to be easier and more efficient than using XML. Leave XML for internet traffic.

Share this post


Link to post
Share on other sites
Quote:
Original post by T1Oracle
1) XML's only real advantage is portability, due to its popularitiy its guaranteed to be a "readable" format. That does not mean that it will make sense to the reader, but hey, you can view in internet explorer... Although I agree that XML editors are a good thing. Regardless, you probably don't need anything to read your config file other than your game and the software you make for it.


I'd disagree, the XML files that are being used in my current project are far more descriptive. For example:

<configuration>
<profile name="profile1">
...
<videomode width="1024" height="768" redbits="8" greenbits="8" bluebits="8" alphabits="8"/>
</profile>
<profile name="profile2">
...
</profile>
</configuration>
<playlist name="myPlaylist">
<song name="Song Title" filename="song1.ogg"/>
<song name="Song2 Title" filename="song2.ogg"/>
</playlist>
...

Makes a whole lot more sense than:
profile1|...|1024|768|8|8|8|8|12|myPlaylist|Song Title|song1.ogg|Song2 Title|song2.ogg etc.

Not just to others who are using it, but me too. That said, XML isn't the greatest in all situations. But it does clarify what each value actually means [to someone who understands how the system basically works]. And it lets you arbitrarily add new stuff without needing to update the parser.

Quote:

2) XML requires a complex parser and lots of support code. Regardless of how "self describing" it is claimed to be, it still will not have any use in your software until you program a meaning for it into every tool that needs it.


Yes, but see TinyXml, throw on a function which can extract a result from the node <x><y><z a="result">, and a couple of other simple wrapper functions and you're more or less set.

Quote:

3) The alternatives to XML are almost always superior. In my case (for the CMS) MySQL would have been better, unfortunately I had no SQL options. For your case a simple text file is probably a superior choice. I've heard of using XML for a logger format but a simple text file can do all of the same things without the bulk.


But then you miss out on all of the goodness that you can get from XSLT or whatever it's called. Hell, there's an article here on gamedev about using XML for logging, and the advantages that it outlines are pretty comprehensive.

Quote:

4) If XML makes sense anywhere it is in internet communication. When you need communcation between two servers using different technology made by different companies then XML's portability is an advantage. Unfortuantely, even there you still need a standardized format (SOAP, WSDL, RSS, Atom) despite it's alleged "self describing" nature.


True that, but for an engine, you define your own format that's simple to use. And you document it. Exactly what you'd be doing otherwise, except you can set rules and validate the contents of an XML document easier.

Quote:

As a config file format in text you could have something as simple as, a variable name, a colon, a value (text/int/float), and an endl. That would be incredibly easy to parse, especially if you restrict variable names to not having spaces, tabs, or colons. That way you can ignore white space, and once you hit the colon you know that the value is the next thing that needs to be read.

I could write a parser for that in minutes, but that is only one suggestion. Using a text file of your design is likely to be easier and more efficient than using XML. Leave XML for internet traffic.


See TinyXml. XML means that you don't have to actually write a parser for every individual file format, it's structure is well defined [a heirachy of nodes ending with /node], and there are tools out there to display, edit, and extract data from them.

While I agree that sometimes XML isn't the solution, in 99% of non-realtime cases, it is. Any time that you want someone with only general understanding of your system to be able to edit your parameters, XML is the way to go.

At least, that's how I see things

--CJM

Share this post


Link to post
Share on other sites
XML is a sticky beast. Personally, I think there's a fairly easy rule you can use to decide when it's a good option: I call it the "stock ticker rule." Compare your data to a stock ticker; you can pull individual stock symbols and their price information out of the middle of the stream and nobody gets confused. You can just whack away at the list and pick arbitrary lists of stocks and it'll still be sensible. If your data fits this pattern, XML is not the right tool.

If no part of your data is more complex than single lines of text, don't use XML. This includes stuff like config files (use .INI format or something) and most logging. In these cases, you can more or less grab a single line out of context and it'll still contain a reasonable amount of information - you might lose some section info (for .INI style configs) or some incidental meta-info (like a sequence of events in a log) but you don't totally mangle the meaning of a line by yoinking it out of the middle of the file.


By contrast, any hierarchical, recursive, or just plain complex data is great for XML. As noted, parsing XML really honestly isn't hard if you use the right libraries (like you should). XML is also incredibly descriptive for any kind of complex data - especially nested or recursive data. And, with the use of XML schemas and XSLT, you have a data format which is both self-validating and self-displaying, which (when combined with decent XML editor tools - anyone editing XML in Notepad has missed the point) is a very potent combination.

Know your tools, and know when to apply them. I won't disagree that XML is overused sometimes, but it certainly has its place - and that place is significantly larger than shuffling backend data for SOAP systems [wink]

Share this post


Link to post
Share on other sites
CLI flags should always support some form of 'help' (/? -? -help --help /help), usually a version (--version /version). Beyond that, it depends on the app. Personally, I think any non-trivial app should have a config file parameter (often -f "path") which would then fiddle with most stuff.

I'm not a big fan of XML in general, and specifically for this. In game consoles are more useful, and it's generally trivial (and expected) to read in that config file and pass line by line into the in game console parser ala-quake.

Share this post


Link to post
Share on other sites
Quote:
Original post by CJM
it lets you arbitrarily add new stuff without needing to update the parser.

You can do the same with my demonstrated solution:

variableName: value

You can store a stl map of variable names and values, then whatever needs a specific variable can pull that value from the map. There are other ways to approach that, but in the end the parser need not change when the contents of the config file changes.

Regardless, you can never "arbitrarily add new stuff" in any file and get a result in the software unless, the meaning of that data has already been defined in that software.

Quote:
But then you miss out on all of the goodness that you can get from XSLT or whatever it's called.

Why would a config file need XSLT? The find function in notepad is likely more than enough. The need for XSLT is generated by the complexity of XML, if you don't use XML you don't need XSLT.

Quote:
TinyXml

2+ MB is not tiny, TinyXML is a complex parser with plenty more overhead than a simple config file needs. A config file is an ant, TinyXML is an obese hammer.

Quote:
While I agree that sometimes XML isn't the solution, in 99% of non-realtime cases, it is.

There was a time when I was steering at XML hard enough to believe that as well. Implementing it and then looking back on my previous solutions showed me the light. XML has more features, more restrictions - especially on what is and is not an invalid character [flaming] -, and more excessive syntax than most non-realtime cases are going to need or use.

Quote:

<configuration>
<profile name="profile1">
...
<videomode width="1024" height="768" redbits="8" greenbits="8" bluebits="8" alphabits="8"/>
</profile>
<profile name="profile2">
...
</profile>
</configuration>
<playlist name="myPlaylist">
<song name="Song Title" filename="song1.ogg"/>
<song name="Song2 Title" filename="song2.ogg"/>
</playlist>

I will agree that the heirarchal nature of your data makes the XML syntax and available tools an attractive option. However, XML is not the only text based means of storing heirachal text data. Regardless, in most cases a config file is simple and does not need an heirachy of data. Personally I would not put the data in your demo in one config file, I would keep that data with the resources that they relate to. Data should be organized according to how it is used and accessed.

Share this post


Link to post
Share on other sites
One thing I have always hated doing, is clicking through the same menus to accomplish the same initial tasks when connecting to a game server (e.g. connecting with a username/password, selecting a server, selecting a character, etc). Being able to "game.exe -connect myhost.com:8110 -username superdude -password mypass2000" from a commandline / bash script / Windows shortcut, I could save myself the aforementioned nuisance.

It seems that (and this is true both of games and command-line applications e.g. in Linux) command-line is the super-override alternative, whose fallback is config files, whose fallback is hard-coded application 'minimum configuration'. If your game allows for cmdline options to shorten the amount of time the user must spend kludging through GUIs, then all the more power to you.

Share this post


Link to post
Share on other sites
Like Telastyn, I expect at least -h or --help.

And I think XML configuration files are often overkill.

Share this post


Link to post
Share on other sites
for my last .NET project I used both INI and XML. The situation was simple, being as how I program C# .NET at work and the XML libraries are even more easily available than any INI wrapper library I initially set out to just use XML. Then things came up where I wanted more people to be able to open up and edit some core settings, and XML is quite simply NOT in any way usable by non-computer people - and I didn't have time to write a custom editor. So I made an INI file for the user-level settings and used XML for the program data files. Over time the user settings file grew to include more and more debug and config choices as well. So now there are 3 XML formats and 2 INI files. And I'm happy that I'm not wasting time and energy forcing myself to adapt everything to one or the other, cause this solution is working great for me.

Share this post


Link to post
Share on other sites
Hey guys, thanks for your comments again you've really given me something to think about.

As for the reason I was thinking about using XML as opposed to the usual INI file was that after taking a look though the DirectX SDK I saw a project that used as mini-database to store different hardware configurations and specs, the program would query these on loading and then configure itself for the most optimal settings for that hardware.

It's been a big toss up between XML (tinyXML) and SQL (SQL lite) but I recently made the decision to use SQL and provide a nice GUI for storing and changing the configuration. This was mainly because I was already using SQL for storing user profiles and settings so the infrastructure was already there, XML still sounds good for storing maps and save games though.

I know this probably sounds a little 'over the top' but it's a good leaning experience and that's all I really wanted, well and a kick ass game but it's a little to early for hopes that high :)

Thanks again.
Carlos

Share this post


Link to post
Share on other sites
I was already using XML for data files, so it was pretty trivial to use it for the config file too. Admitably, it's a bit of a waste, as the config file is just 'flat data'. But changing it would require writing more code. :) As such, I only have three command line options: [-]c[onfig] "filename", [-]v[ersion], and [-]s[et] "attribute name" "value". The usage of each should be pretty obvious. :) [] denotes optional parts.

Share this post


Link to post
Share on other sites
Quote:
Original post by Deyja
I was already using XML for data files

I shudder at the thought. Unless your data is transfered bewteen servers from different companies using different technology.

Have you ever tried binary?

Share this post


Link to post
Share on other sites
For configuration I always use Lua. Actually everything I do is bound to lua anyway.

Lua's clean, lightweight and can directly map to data objects in your code. It's as simple to read and edit as a little text file, but handles all the parsing for you. Plus you get the added benefit that you're running a scripting language so you can do far more interesting things than in XML.

Personally I hate XML. It's a tangled mess of brackets that confuses the eye and makes editing difficult.

Share this post


Link to post
Share on other sites
Quote:
Have you ever tried binary?
Can't edit binary in notepad.

And, XML is perfect for heirarchial data; which is what I have.

Share this post


Link to post
Share on other sites
XML to save app state -- well, compressed-on-the-fly XML to keep file size down.

Back to command line, how about:
1> Help options.
2> A "regenerate default config files" flag.
3> The ability to replace any config file option on the command line.
4> The ability to replace a set of config file options, as defined by pre-generated config file, as a command line option.
5> A command-line "macro" file that defines things like "-safe means 'load safe.ini'" or "-autostart -file=file means 'load autostart.ini, and set engine:setup:startupfile=%file%'".

Then your game startup looks like:
1> Look for help/regenerate flags on the command line. If so, do it.
2> Load your config file data.
3> Check the command line for changes to your config. Apply them.
4> Error out if you are given a command line option that you don't understand.
5> Log every step above heavily. :)

Edit:
NOTE: doing the above will take some time. I would advise against it, unless you would find writing it fun, if you are doing a solo project of any kind.

For a solo project, just keep it encapsulated, and write what you need _right now_ to get your project working and on the screen. If it is encapsulated, you can replace it later if you need more fanciness. ;)

End NOTE.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By NDraskovic
      Hey guys,
      I have a really weird problem. I'm trying to get some data from a REST service. I'm using the following code:
       
      private void GetTheScores() { UnityWebRequest GetCommand = UnityWebRequest.Get(url); UnityWebRequestAsyncOperation operation = GetCommand.SendWebRequest(); if (!operation.webRequest.isNetworkError) { ResultsContainer rez = JsonUtility.FromJson<ResultsContainer>(operation.webRequest.downloadHandler.text); Debug.Log("Text: " + operation.webRequest.downloadHandler.text); } } The problem is that when I'm in Unity's editor, the request doesn't return anything (operation.webRequest.downloadHandler.text is empty, the Debug.Log command just prints "Text: "), but when I enter the debug mode and insert a breakpoint on that line, then it returns the text properly. Does anyone have an idea why is this happening?
      The real problem I'm trying to solve is that when I receive the text, I can't get the data from the JSON. The markup is really simple:
      [{"id":1,"name":"Player1"},{"id":2,"name":"Player2"}] and I have an object that should accept that data:
      [System.Serializable] public class ResultScript { public int id; public string name; } There is also a class that should accept the array of these objects (which the JSON is returning):
      [System.Serializable] public class ResultsContainer { public ResultScript[] results; } But when I run the code (in the debug mode, to get any result) I get an error: ArgumentException: JSON must represent an object type. I've googled it but none of the proposed solutions work for me.
      Also (regardless if I'm in the debug mode or not) when I try to do some string operations like removing or adding characters to the GET result, the functions return an empty string as a result
      Can you help me with any of these problems?
      Thank you
    • By nihitori
      The Emotional Music Vol. I pack focuses on beautiful and esoteric orchestral music, capable of creating truly emotive and intimate moods. It features detailed chamber strings, cello and piano as the main instruments, resulting in a subtle and elegant sound never before heard in video game royalty-free music assets.

      The pack includes 5 original tracks, as well as a total of 47 loops based on these tracks (long loops for simple use and short loops for custom / complex music layering).

      Unity Asset Store link: https://www.assetstore.unity3d.com/en/#!/content/107032
      Unreal Engine Marketplace link: https://www.unrealengine.com/marketplace/emotional-music-vol-i

      A 15 seconds preview of each main track is available on Soundcloud:
       
    • By RoKabium Games
      Another one of our new UI for #screenshotsaturday. This is the inventory screen for showing what animal fossils you have collected so far. #gamedev #indiedev #sama
    • By eldwin11929
      We're looking for programmers for our project.
      Our project is being made in Unity
      Requirements:
      -Skills in Unity
      -C#
      -Javascript
      -Node.js
      We're looking for programmers who can perform a variety of functions on our project.
      Project is a top-down hack-and-slash pvp dungeon-crawler like game. Game is entirely multiplayer based, using randomized dungeons, and a unique combat system with emphasis on gameplay.
      We have a GDD to work off of, and a Lead Programmer you would work under.
      Assignments may include:
      -Creating new scripts of varying degrees specific to the project (mostly server-side, but sometimes client-side)
      -Assembling already created monsters/characters with existing or non-existing code.
      -Creating VFX
      -Assembling already created environment models
      If interested, please contact: eldwin11929@yahoo.com
      This project is unpaid, but with royalties.
       
      ---
      Additional Project Info:
      Summary:
      Bassetune Reapers is a Player-verus-Player, competitive dungeon crawler. This basically takes on aspects of dungeon crawling, but with a more aggressive setting. Players will have the option to play as the "dungeon-crawlers" (called the 'Knights', or "Knight Class", in-game) or as the "dungeon" itself (literally called the 'Bosses', or "Boss Class", in-game). What this means is that players can choose to play as the people invading the dungeon, or as the dungeon-holders themselves.
      Key Features:
      -Intense, fast-paced combat
      -Multiple skills, weapons, and ways to play the game
      -Tons of different Bosses, Minibosses, creatures and traps to utilize throughout the dungeon
      -Multiple unique environments
      -Interesting, detailed lore behind both the game and world
      -Intricate RPG system
      -Ladder and ranking system
      -Lots of customization for both classes s of customization for both classes
    • By RoKabium Games
      Custom coffee mugs have arrived... More caffeine!
      Have a great weekend everyone! 
      #gamedev #indiedev #sama #caffeine
  • Advertisement