• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By davemacdo
      I'm a formally trained composer (doctorate from Michigan State) who writes what most people would call avant-garde concert music. I love weird abstract projects, and I would like to work with somebody making a weird, abstract, artsy game. 
      You can find more about me and my music on my site. I have worked with acoustic and electronic sounds, including some algorithmic and interactive computer music. 
      In particular, I would like to work on a project that lets me use Fmod to prepare an adaptive score for a game built on Unity or Unreal. I've been a music professor and would like to get experience working in this medium so that I can be a better mentor for my students. Send me a DM or email <davidjohnmacdonald@gmail.com> if you would like to discuss working on a project together. 
    • By Tuner_z

      Name: One Level: Stickman Jailbreak
      Price: Free
      Developer: RTU Studio
      Platform: Android
      Language: C# (Unity3D)
      Google Play: https://play.google.com/store/apps/details?id=com.RTU.OneLevel
       
      Hello!
      I want to show you my game! "One level: Stickman Jailbreak" is a puzzle game with unusual gameplay where you must help the character to escape from prison. You just need to take the key and get out alive. The game has only one level, and there are many ways to complete it. Not everything is as simple as it might seem at first glance, so there are clues in the game.
       
      Short description:
      Nobody escapes from here!
       
      Description:
      Tommy got into trouble again! Our hero is behind bars. But he's not going to stay in jail for a long time and he decides to escape. Tommy steals a key and gets out of the jail cell. But our friend doesn't go free: Tommy suddenly finds himself in the same room from which he just escaped! The conditions for escaping change every time. In order to go free Tommy will have to solve logical puzzles and you can help him in this!
      At first it will be easy, but the tension will increase, and the tasks will become more complicated with each level. You should use your brain for all 100%, but if your skill is not enough, you can use a hint or ask for help from friends!
      You can solve the puzzles alone or with your friends and spend time well!
       
      Features: 
      Features:
      - 48 unique levels;
      - the game is translated into 10 languages: English, French, German, Spanish, Italian, Portuguese, Russian, Japanese, Chinese, Korean;
      - the function of "help from friend";
      - hints;
      - instructions.
       
      Trailer:
       
      Screenshots:





       
    • By Brandon Marx
      Hello forum,
      I have some decent amount of experience in Unity making games for Software Engineering projects in college, these were very specific projects however and I still am fairly new to building games. I wanted to make a game that uses the shadows of objects for collision detecting (i.e. shooting a gun at a characters shadow causes that character damage. What is the best engine to do this in (game will be 3D), and does anyone have any advice on how to approach this concept? I consider myself fairly experienced in programming, but game dev is just an entirely different beast.
    • By juicyz
      Hey all,
      I've been slowly working on my game called AotW for a while now.  I have come to the conclusions that it would be nice to cooperate with 1 or 2 others to help finish it.  Ive been trying to keep my GDD up to date with my ideas and development so that would give a better overview of the game when the time comes.  Currently I have a basic skeleton of the RPG elements needed but everything can still be discussed and talked about and we can transform my idea to something the group likes.
      The premise of the game is a Diablo-like procedurally generated map with RPG elements that include sockets, inventory, classes, abilities, crafting, loot, items, sockets, and enchanting.  This will be done in a 2D iso view as I can't do 3D art and I enjoy 2D games a lot.
       
      I don't plan on releasing this as this is more of a hobby project for me and I have a full-time job.  Though I'd like to start putting more hours into development and having others definitely will be motivation.  I also want to be able to say I have finally "finished" a game idea to some degree.  If the time comes and we want to release it, then we can go ahead and do so but that's not my purpose or plan. 
       
      Discord:
      Juicyz#3683
       
       
      Thanks,
      Juicyz
    • By Arnold // Golden Donkey Productions
      Hi, I've been working on this issue for a while and haven't yet found an answer.
      Does anyone know the best way to convert unity's LAT & LONG into a vector 3 position that I could use in a virtual world (if it's even possible). 
      Thankyou in advance
  • Advertisement
  • Advertisement
Sign in to follow this  

Unity Silent Expectations : The Command Line

This topic is 4308 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
Sign in to follow this  

  • Advertisement