This is more of a design question than a programming one, but it''s not a game design question as such either, so I didn''t put it in that forum. I''m designing a Quake like console type of thing. However, instead of all commands being in one long list, I''m considering placing related commands into groups. Like this :

Console // Handles commands for clearing the console buffer and moving from group to group, and what not
Graphics // For graphics related commands
JokeOfTheDayGenerator // etc.
 

Groups can contain subgroups too. This is a bit like a directory tree structure, where there are commands instead of files, and groups instead of directories. Like directories, there can only ever be one current one. e.g. Console.SomeSubgroup> My questions is this: What commands should be accessible from the current group? At the moment, my group structure looks like this:

Console
    |
    Graphics
    |     |
    |     Textures
    |
    Sound
        |
        Sounds
    |
    etc.
 

In other words, Console is like the root. When you''re in Console.Graphics, the availability options could be: Commands in... a) Console.Graphics only b) Console, and Console.Graphics c) Console.Graphics, and Console.Graphics.Textures d) Console.Graphics, and also Console because Console is always available, no matter where you are Guidance, anyone? Thanks, Ro_Akira

quote:
Just my .02, but I think something like that would work great for engine settings (Engine.Graphics.Resolution=800x600), but for commands I think you''re better keeping the hierarchy flat. It would be annoying to have to pay attention to where you were in order to send a chat message, for example.

Agreed. Similarly, if you want to do something like clear the console, it''d be inconvenient.

What prompted me to think along these lines was:
a) Quake''s long list of commands isn''t very handy to scroll. Through. QIII addressed some of these problems with the ability to list commands that matched the partial command name you gave (QII doesn''t appear to have it). QIII also doesn''t list the cmds in alphabetic order, but the prefixing of cvars with r_ and s_, and the like helps. Anyway, better organisation is one reason.
b) You can get a list of related commands easily.
c) Fewer name conficts. Using fully qualified names, Console.Graphics.restart is different from Console.Sound.restart. And not because it has an r_, instead of an s_ prefixed.

The way I have it designed, there aren''t any cvars as such. Each module has it''s own ''command interpreter'' which can be loaded from a .dll. Each module ''has a'' command interpreter object.

For example, my Graphics class loads up a ''graphics'' command interpreter. The command interpreter has access to the Graphics class. The command interpreter might implement any commands it wants. "setresolution" might take 2 parameters, and call the Graphics::SetResolution (...) method of the Graphics object with which the command interpreter is associated with.

Is ''command interpreter'' too long? My fingers seem to think so...! :\

quote:
The fact is, you won''t have enough commands for some group system to be worth it. You also have to think that the players want console options to be easy to use, people would hate constantly changing "groups" to access other things, it would make your console unattractive.

Agreed. I hate changing directories at a DOS prompt. Why would I think users of a console think any different?!

Ro_Akira

quote:
...a question about it yesterday...

I saw that question alright, but then I spotted the word ''pattern'' amongst the posts. I didn''t run and hide immediately, just soon after, when I followed the link to what they were talking about. Curiously, this type of thing is what I''ve ended up with in my code also:

class CoinInsertedEvent : public TEvent 

That''s from the link ''typed message pattern'' provided by antareus in one post. I didn''t/doesn''t look ''right'', but it works. I''ll have another look at that thread, since you discribed what you are working on as ''very similar''.

quote:
I''m planning on trying to implement an auto-type feature in mine. As you type, it would start trying to guess which command you want. So if you typed /s it would show a dimmed ''ay'' after the cursor. If you hit tab, it would auto complete the command for you, add a space, and move the cursor to the end of the line. You could even implement a pop-down list of matched commands (similar to the way IE autofills URL''s in the address field). This would give you a functionality similar to what you were going for I think.

A combination of what you''re suggesting would be cool. A listbox would be really necessary I think. If you type just ''s'' for example, it could match a good number of commmands. Rather than the I.E. approach of the listbox appearing separate from the line you''re typing in, one could combine it with the ''greyed out rest of command'' approach. I''ll try some illustration:

salad   --  <-greysalad       |salamander  | <-listboxsalute      | 

Just imagine that without the gap with the ''--'', and ''ad'' in grey. I''m unsure whether salad should be repeated in the listbox as shown?

Regardless, this is the type of thing that might make my obtuse hierarchical system quite useable. I already have a ''history'' system, like that provided by a Win2k console, or DOSKey.

Oh, and one can scroll to the very top of the console buffer by using ''Ctrl-Pgup'', and to the very bottom by using ''Ctrl-Pgdn''. The latter is something that drove me mad using the Quake console. Scolling all the way up to see something, and then having to scroll all the way down again. I''m sure I''ve just missed the key to do it?!

Ro_Akira

Hmmm. Looks like I might have to use d) instead of a) (see above). The console command interpreter implements such feats as clearing the console buffer, and moving from group to group. However, if I go from Console> to Console.Graphics>, suddenly I''m not able to go from group to group, because I no longer have access to the command!

I''ve just had a thought though (while typing this), since any commands can be referenced from any group by using a full path, I can still get around by using Console.cd ...

...and another thing. This console system seems to be really a half-baked scripting system. Especially when you can put a group of commands into a file, and execute them using ''exec'' in QIII for example. If I implement ''if'' statements, and return values, I''m half way there. Oh, and I''d need to treat commands more like functions. i.e. >Console.Graphics.SetResolution(800,600) instead of >Console.Graphics.SetResolution 800 600

Ro_Akira

wild_pointer,
In that case, I think it''s more asinine, than what bf1942 does. I don''t like things being asinine, what does bf1942 do exactly? To be fair, it''s still up in the air as to what''s accessible from where. Which is why I''m still talking here!

Extrarius,
That''s the type of thing I was thinking about.

quote:
...Also, maybe you could have a menu up top with the choices spelled out fully, like "Console" (which inserts "Con." and pops up the list of choices)...

You mean, if you want to type it out, you only need Con.Log.Enable, i.e. shorthand, but the menu will display the long version that can easily be understood. That''s good.

An complete alternative/useful addition would be to use a mouse driven listbox for changing variables. A bit like Unreal (the original, anyway. I haven''t played any since then) come to think of it. I think that might make a useful addition rather than an alternative. The command line based approach makes to easy for variables to be read from a text file and what not. More work of course.

Ro_Akira